Re: Проблемы со связностью по ipv6 сайта nginx.org

[Maxim Dounin]

Hello!

On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote:

> чт, 24 сент. 2020 г. в 18:27, Maxim Dounin <mdounin at mdounin.ru>:
> 
> > Hello!
> >
> > On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote:
> >
> > > > Продемонстрированная проблема ровно одна: пакетный менеджер не
> > > > может получить
> > > > http://nginx.org/packages/debian/dists/buster/InRelease с
> > > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения.
> > > >
> > > >
> > > > Первый запрос дождался таймаута (непонятно почему).
> > > > Второй запрос выполнился мгновенно.
> > > > https://pastebin.com/dWbffATH
> > >
> > > Смотрите:
> > > a) вы продемонстрировали проблему с первым подключением к nginx.org
> > > b) вы утверждаете что бывает проблема с резолвером, когда используется
> > ipv6
> > > c) вы используете  Hurricane Electric tunnel brocker для ipv6
> > >
> > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или
> > на какие-то проблемы в he.
> > >
> > > nginx.org доступен по ipv6 c нескольких точек с которых я мог
> > проверить, и судя по логам подключаются
> > > по ipv6 к nginx.org как обычно.
> >
> > Насколько я вижу, соединение нормально устанавливается, запрос
> > отправляется, а ответ не приходит и ждёт таймаута.  После чего на
> > некоторое время всё исправляется.
> >
> > Если используется тоннель, то это выглядит и пахнет как
> > классическая проблема с MTU, которая лечится за счёт PMTU black
> > hole detection.
> >
> > Я со своей стороны давно разочаровался в идее работоспособности
> > PMTU discovery в современном интернете, и жить с тоннелями без
> > правки MSS никому не рекомендую.
> >
> > Но с нашей стороны явно имеет смысл проверить, что ICMP
> > fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
> > ответственности ходят нормально и не зафильтрованы.  С учётом
> > того, что пинги не ходят - у меня вот лично в этом сомнения.
> >
> 
> 
> есть распространенное ожидание, что якобы ICMP Frag needed может как-то
> помочь.
> на самом деле - скорее нет.
> 
> 
> допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно
> увидите ICMP Frag required.
> если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric,
> whatever), то ICMP Frag required придет не вам, а туда, где терминируется
> туннель.
> благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,
> которая идет снаружи туннеля ?

Если ICMP fragmentation needed придёт для пакета, отправленного 
тоннелем - то он придёт, дествительно, туда, где терминируется 
тоннель, и задачей тоннеля будет как-то это обработать (например, 
уменьшить своё MTU и начать слать ICMP frag needed уже самому; 
впрочем, никогда не смотрел подробно, возможно типичные тоннели 
просто не ставят DF на своих пакетах, и кто неправильно выбрал MTU 
- тот просто попал на фрагментацию).  

Если же пакет не влезет в тоннель - то мы возвращаемся к той же 
ситуации, что и без тоннеля: где-то на участке сети мелкий MTU (и 
участок этот - тоннель, что, впрочем, не важно).  И работающий ICMP 
тут проблему замечательно решает.

Другой вопрос, что "работающий ICMP" - это сказочный персонаж.  В 
современном интернете наверняка найдётся место, где его 
зафильтровали, и тоннель без правки MSS будет работать далеко не 
со всеми адресами.

> что действительно работает, это манипуляции (в разумных пределах) с MSS,
> например --clamp-mss-to-pmtu
> очень интересно в этом плане жить в мире Windows (в нем принято ставить DF
> на https), и очень забавно наблюдать
> за MSS, например, от фейсбука (и прочих игроков такого масштаба)

Ну вот пониманию, что ICMP frag needed не работает и этот интернет 
не починить - уже лет 20, если не больше.  Присутствующий тут 
Руслан Ермилов свой tcpmssd сделал 20 лет назад.

-- 
Maxim Dounin
http://mdounin.ru/