Архив форумов ЦИТФорума

[Alexandra]

Добрый день. Обращаюсь за помощью мирового разума, может хоть намекнете, где копать

Итак. Есть центральный офис, есть филиалы. Связываются филиалы с центр. офисом посредством нешифрованных gif-туннелей, поднимаемых между серваками, на которых стоят: в центр. офисе FreeBSD 5.4R, в филиалах - на первом FreeBSD 5.2.1R, а на втором - тоже FreeBSD 5.4R.

Итак, теперь оставим только то, что нам нужно - один сервер с 5.4 в центре и два филиала. Туннели от центра на оба филиала подняты абсолютно одинаково, стандартно: gif-интерфейсы: (выдержка из rc.conf одного филиала) :
gif_interfaces="gif0 gif1"
gifconfig_gif0="real-ip-филиала real-ip-центра"
ifconfig_gif0="inet 10.55.3.34 10.55.3.33 netmask 255.255.255.252 mtu 1500 up"
и еще поднят аналогичный туннель на питерский сервак. Во втором филиале абсолютно аналогичная ситуация - те же два туннеля.
На обоих филиалах используется ipfw (на всякий случай).
И вот проблема - некоторое время назад туннель с первым филиалом стал падать. Работает-работает и через какое-то время отваливается. Если при этом запустить пинг с центр сервака, то он опять поднимается сам и все прекрасно работает (у нас теперь бесконечные пинги целыми днями включены), т.е. ему нужна какая-то активность с нашей стороны. На их серваке ничего в последнее время не делали и не переделывали.

Далее, со вторым филиалом тоже наблюдалась проблема, но сначала другого характера - там туннель периодически "отключался" на пару секунд, потом снова "включался". Я ставила на ИХ серваке пинг на наш сервак и смотрела tcpdump по gif-концам туннеля на обоих серваках. Моменты "отключения" выглядели так - с ИХ конца пакеты в туннель уходят, а с центр конца - даже не появляются...(в туннеле пакетожуйка сидит ).. так было до недавнего времени. А буквально пару дней назад (и опять же мы уже месяц там ничего не делали) туннель стал отваливаться полностью точно так же, как и в ситуации с первым филиалом. При этом на обоих филиалах такие же туннели с питером работают нормально.

Сразу приходит в голову мысль - ну так проблема тогда, наверное в центр. серваке! Логично, согласна, но и с этим серваком мы давно ничего не делали в конструктивном или деструктивном плане. Такое впечатление, что все произошло ВДРУГ.

В общем, совещания с коллегами ничего не дали, ломаем голову, не знаем, куда смотреть и кого увольнять. Посоветуйте что-нибудь, а? пожаааааааалусто. Может еще чего сообщить надо?

[bsDrake]

я бы сначала смотрел сети через которые эти туннели проброшены, наверняка проблема не в серверах (мне сложно представить что-то более железное, чем gif). ну а вместо того, что бы кого-то увольнять , я бы пробросил pptp и/или ipsec туннели и посмотрел как они себя ведут

[and3008]

Ну в общем-то все тривиально.

1. Смотрим доки на по организации туннеля. Ищем упоминания о пакетах keepalive и/или установлении туннеля по требованию.

2. Смотрим на сетевую инфраструктуру. Особое внимание пограничным роутерам. Смотрим на настроку MTU.

3. В качестве теста пробуем уменьшить MTU на одной стороне. Все равно на какой, но только на одной.

4. Проведите эксперимент. Дождитесь падения канала. После этого проведите трассировку (traceroute) по обычному, не туннельному маршруту. Обратите внимание на места, где появляются наибольшие задержки.

[Alexandra]

Спасибо за советы, возьму на вооружение.

А с основной проблемой полного отваливания туннелей все оказалось до безобразия просто, даже стыдно как-то конечно же дело оказалось в ipfw на центр. серваке. У нас практически все на keep-state заделано, ну и вот как-то насчет внутренних адресов концов туннеля мы это учли (ну чтобы инициировать соединение с той стороны тоже могли), а вот про реальники-то забыли!! ну и понятное дело при отсутствии активности с нашей стороны туннель падал, потому что никакие пакеты с ТОЙ стороны (с реальника) не пускались
Вот

Ну теперь надо попробовать посмотреть, откуда потери, хотя в хандбуке писали, что потери будут по-любому, но немного. А еще надо IPSEC настроить....

В общем, всем спасибо, не судите строго