Такой вопрос...
Есть три офиса одной компании в разных местах(A,B,C). Во всех внутренняя сеть и по контроллеру домена с ексчейнджем внутри. Все сети имеют выход в интернет: сеть А - радио (РМТ), сеть - Б - радио (РМТ), сеть С - ADSL (точка). В сетях стоят шлюзы на FreeBSD. Задача у них - раздача интернета внутри сетей, подсчет трафика, ограничение юзеров разными лимитами и, кроме этого всего, поддержание туннелей между офисами. Организовано все как три домена - три подсети. Реализовано все через IPFW, туннели IPSEC. Стоит squid с обработчиком логов. Стоит portsentry. Стоит Samba (в сети A).
Проблема в следующем после запуска туннеля все работает некоторое время. Но... Где-то через полчаса - час (может быть и меньше) машины сети C перестают пинговать машины сети A, не пингуется и внутренний интерфейс шлюза сети А. При этом если пингануть сеть С из сети A, то все начинает снова работать. Вопрос - куда копать?

Провайдер ли это, фаервол, squid? Что? Интересуют все варианты.

То есть грубо говоря падает тунель и падает в одну сторону. При этом восстанавливается одним пакетом брошеным в другую. При этом падает только тунель между A и С. Тунели между A и B и B и С живут вполне нормально. Отсюда могу сделать вывод, что провайдер не причем. Настройки везде примерно идентичные. По крайней мере на сервере сети A. Следовательно и таймауты тоже не причем.

• FreeBSD и туннели,A Clockwork Orange, 13:10 , 11-Авг-03
  • FreeBSD и туннели,ABS, 15:20 , 11-Авг-03
    • FreeBSD и туннели,ABS, 10:23 , 12-Авг-03
      • FreeBSD и туннели,andrew, 11:04 , 12-Авг-03
        • FreeBSD и туннели,ABS, 11:20 , 12-Авг-03
          • FreeBSD и туннели,ABS, 11:03 , 13-Авг-03
            • FreeBSD и туннели,tadmin, 13:06 , 13-Авг-03
              • FreeBSD и туннели,ABS, 13:21 , 13-Авг-03
                • FreeBSD и туннели,andrew, 13:58 , 13-Авг-03
                  • FreeBSD и туннели,andrew, 13:58 , 13-Авг-03
                    • FreeBSD и туннели,ABS, 16:04 , 13-Авг-03
                • FreeBSD и туннели,tadmin, 18:28 , 13-Авг-03
                  • FreeBSD и туннели,ABS, 19:09 , 13-Авг-03
                    • FreeBSD и туннели,tadmin, 12:07 , 14-Авг-03

А раньше работало? если работало что сделал?

Еще лично мне не очень ясна работа portsentry совместно с ipfw, мне кажется что фаерволл закрывает прежде чем пакет дойдет до portsentry. Если конечно порт сентри не слушает порт который открыт.

А касфтельно вопроса может быть у тебя сеть в портсентри не указана пакет откуда игнорировать, может так  

>А раньше работало? если работало что сделал?

Скажем так до меня еще не работало - сам нечего не делал.

>Еще лично мне не очень ясна работа portsentry совместно с ipfw, мне
>кажется что фаерволл закрывает прежде чем пакет дойдет до portsentry. Если конечно порт сентри не слушает порт который открыт.

Портсентри исключительно для запорки сканирования используется. Он собственно не особо нужен, как я считаю...

>
>А касфтельно вопроса может быть у тебя сеть в портсентри не указана
>пакет откуда игнорировать, может так

см выше...

Кароче, на сервере достаточно сложная структура правил IPFW. На первый взгляд ошибок нет. Тем более, что дуругие то туннели работают нормально. Но, если вести перед всеми allow ip from any to any, то все работает отлично. В чем фишка?

allow esp from any to any не спасает?

>allow esp from any to any не спасает?

нет... не спасает...

Так, методом научного тыка было выяснено... Если в самое начало списка правил IPFW вводить полное разрешение с IP сервера С - все работает на ура. Также если правила описывающие туннель перенести в самое начало - то все тоже отлично. Но, если правила стоят сразу после диверта - работать перестает. При этом в конфигурации ната все абсолютно правильно. И дело в том что второй туннель висящий на этом сервере работает вполне нормально. Где грабли?

правильно ли понимаю, что все три сети видят друг друга?
Я бы посмотрел на netstat -nr и подумал, кто у тебя маршрутизацией занимается.....

1)если в сети есть кольцо, то есть возможность из А в С и из А в С через В,
то стоит подумать об интеллектуальном роутинге.

2) если иногда линки ложатся, то падают GRE интерфейсы (или что там у тебя), тогда и соотвествующие маршруты удаляются.

Да, все три видят друг друга...

С роутингом ничего не происходит... Разницы, что в рабочем, что в нерабочем состоянии никакой.
gifы оба стоят и никуда не деваются...

Походу дела, намешано фаерволом что-то... Хотя на первый, второй и третий взгляды все правильно... ИМХО, такое переодическое зарезание пакетов не воможно. Хотя, опять же сейчас правила пропускающие нужные мне пакеты впереди и все нормально работает вот уже 4 часа. Опять же правила по второму тунелю остались на месте - и там все тоже работает.

Ничего не понимаю :-)

А через gif все разрешено?

500 порт открыт?

>500 порт открыт?

Нет, правилами все открыто... Скажем так для тунелей открыто все. И специально не закрывается.

>Да, все три видят друг друга...
>
Ты не ответил, эти VPN образуют треугольник, или только "галочку"?

>>Да, все три видят друг друга...
>>
>Ты не ответил, эти VPN образуют треугольник, или только "галочку"?

Треугольник - и все стороны кроме одной работают полноценно... Собственно решение проблемы через смену организации тоже не особо интересует - можно и пинг по крону пустить, и правила в начале оставить. ИМХО это не совсем верно.

>Треугольник - и все стороны кроме одной работают полноценно...

кто у тебя роутит в таком случае?
Для треугольника нужен как минимум OSPF.
на статических роутах треугольник, IMHO, и не должен работать нормально.
Либо нужно на каждой вершине треугольника держать по две сети.

Например на ноде B
192.168.1.0 -> net C
192.168.2.0 -> net A

Например на ноде A
192.168.3.0 -> net C
192.168.2.0 -> net B

и т.д. ....