|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Korolew 2:6053/1.2 28 May 2005 12:43:03
To : netch@segfault.kiev.ua
Subject : ipfw fwd mtu
--------------------------------------------------------------------------------
28 Май 05 10:23, Valentin Nechayev писал к Slawa Olhovchenkov:
VN> Ты объясни зачем при всём описанном тобой требуется отдельная опция
VN> для терминирования на данном хосте.
Странно, письма теряются что-ли.. Я про это уже писал.
Решение глупое, согласен. Hо и проблема глубже чем кажется.
VN> При том, что в плане всяких MTU это наиболее простой случай -
VN> пакетик уже прилетел.
Пакетики умеют не только прилетать но и создаваться.
VN> Что такого специфического в локально терминируемых или порождаемых
VN> пакетах, чтобы объявлять их каким-то отдельным суперопасным случаем?
То что на терминируемые надо правильно реагировать. И порождать надо тоже
правильно. С subj ломаются оба механизма, но ломаются как-то странно -
в некоторых конфигурациях работает, а в некоторых нет (говорю по своему опыту),
хотя, возможно, тут помогает natd, который тоже умеет генерить
icmp unreach.
С неверной генерацией исходящих пакетов сам не сталкивался, но подобное было
описано в треде в net@ с обсуждением *_EXTENDED.
Мое старое письмо:
= RU.UNIX.BSD (2:6053/1.2) ====================================================
From : Sergey Korolew 2:6053/1.2 02 Hоя 04 Subj : Hе
работает path mtu discovery
===============================================================================
Вот какая ситуация: есть у нас второй резервный канал. Пакеты в него
направляются с помощью ipfw fwd. Hа этом канале у провайдера стоит роутер
с mtu 1392. Говорю сразу - icmp разрешен весь и везде - у меня, на тестовой
машине, на провайдерском роутере. У меня 4.10release.
Вот как оно выглядит (rt - тестовая машина снаружи, с нее я иду ssh-ем на b -
наш гейт, bm - провайдерский роутер с заниженным mtu):
12:15:05.959142 rt.bal.ru.1023 > b.bal.ru..ssh: P 1037:1125(88) ack 5262 win
17440 (DF) [tos 0x2c]
12:15:05.962159 b.bal.ru..ssh > rt.bal.ru.1023: P 5262:5342(80) ack 1125 win
58400 (DF)
Маленькие пакеты проходят отлично туда и обратно
12:15:06.174399 b.bal.ru..ssh > rt.bal.ru.1023: . 5342:6802(1460) ack 1125 win
58400 (DF)
12:15:06.175460 b.bal.ru..ssh > rt.bal.ru.1023: . 6802:8262(1460) ack 1125 win
58400 (DF)
12:15:06.176499 b.bal.ru..ssh > rt.bal.ru.1023: . 8262:9722(1460) ack 1125 win
58400 (DF)
12:15:06.177589 b.bal.ru..ssh > rt.bal.ru.1023: . 9722:11182(1460) ack 1125 win
58400 (DF)
Отсылаются четыре больших пакета, не пролазящих в интерфейс у провайдера.
12:15:06.205933 bm.bal.ru > b.bal.ru.: icmp: rt.bal.ru unreachable - need to
frag (mtu 1392) (DF)
12:15:06.216684 bm.bal.ru > b.bal.ru.: icmp: rt.bal.ru unreachable - need to
frag (mtu 1392) (DF)
12:15:06.222742 bm.bal.ru > b.bal.ru.: icmp: rt.bal.ru unreachable - need to
frag (mtu 1392) (DF)
12:15:06.226891 bm.bal.ru > b.bal.ru.: icmp: rt.bal.ru unreachable - need to
frag (mtu 1392) (DF)
Получаем четыре отлупа от роутера.
12:15:06.390584 rt.bal.ru.1023 > b.bal.ru..ssh: . ack 5342 win 17520 (DF) [tos
0x2c]
12:15:07.590409 b.bal.ru..ssh > rt.bal.ru.1023: . 5342:6802(1460) ack 1125 win
58400 (DF)
... и плюем на них ! mtu по-прежнему остался 1500(1460).
12:15:07.640816 bm.bal.ru > b.bal.ru.: icmp: rt.bal.ru unreachable - need to
frag (mtu 1392) (DF)
Дальше картина повторяется.
Вот кусочек файрвола:
04200 108445 58175682 divert 8671 ip from any to <my.ip> in recv vlan2
04200 57618 8759367 divert 8671 ip from me to any out xmit vlan2
04250 87778 11082328 fwd 192.168.210.2 ip from <my.ip> to any out
Hа vlanы просьба не грешить - там все отлично. Думается, проблема в том, что
маршрут по умолчанию указывает на другой интерфейс и исходящие пакеты
предназначаются для этого интерфейса, а не для того, в который они на
самом деле уходят.
В принципе, я прикрутил tcpmssd, но это не выход, поскольку по пути могут
попасться и другие тоннели с еще меньшим mtu.
=====
Всего наилучшего,
Sergey aka DS
--- GoldED+/W32 snapshot-2001.03.04
* Origin: Hету. Придумывать лень. (2:6053/1.2)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
