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

[Evgeniy Berdnikov]

On Fri, Sep 25, 2020 at 05:49:40AM +0700, Eugene Grosbein wrote:
> 25.09.2020 0:01, Evgeniy Berdnikov пишет:
> 
> >  Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
> >  наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).
> 
> О, сколько вам открытий чудных готовит просвященья дух!
> Даже операторы связи бывают такие, что у них MTU трассы во внешний мир меньше 
> 1500,
> я встречал, что уж говорить о корпоративных и домашних сетях.

 Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак.
 Поэтому бывает лишь на крайних хопах.

> А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT,
> за которой в одном или несколькими хопами (а не непосредственно на ней)
> стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше 
> клиенты.

 Эта "магия" для tcp и udp ничего сложного не представляет, она уже лет 20
 работает и в линуксах, и в бсд, и в цисках. Магию не осилили зиксели и
 прочие китайцы, да, но не потому что там что-то сверхсложное. У неасиливших
 вообще всё плохо, там даже icmp[source-quench] можно встретить. :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Eugene Grosbein]

24.09.2020 23:28, Maxim Dounin пишет:

> Если ICMP fragmentation needed придёт для пакета, отправленного 
> тоннелем - то он придёт, дествительно, туда, где терминируется 
> тоннель,

Или не придёт. Его кто угодно может не пропустить (NAT box) или даже изначально 
не сгенерить,
дропнув пакет за превышение MTU молча, без отправки ICMP.

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

А нынче даже и tcpmssd не надо, функция adjust mss встроена в сетевые стеки или 
пакетные фильтры.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Eugene Grosbein]

25.09.2020 0:01, Evgeniy Berdnikov пишет:

>  Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
>  наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).

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

А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT,
за которой в одном или несколькими хопами (а не непосредственно на ней)
стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше клиенты.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Илья Шипицин]

чт, 24 сент. 2020 г. в 22:02, Evgeniy Berdnikov :

> On Thu, Sep 24, 2020 at 09:18:40PM +0500, Илья Шипицин wrote:
> >чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov :
> >
> >   PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не
> может.
> >
> >я примерно тыщу раз сталкивался с ситуацией
> >"у нас не устанавливается SSL от браузера" --> "запускаем трейсроут"
> --> в
> >транзите вижу узел с днс именем, содержащим pppoe.
> >примерно в 100% случаях снижение MTU на клиенте или аналогичная
> >манипуляция на сервере чинили
> >при этом ни у меня, ни у клиента icmp не блокировано. просто
> сигнализация
> >идет, вероятно, с pppoe узлами в транзите.
>
>  Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
>  наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).
>  "Снаружи" на pppoe icmp никогда не прилетают, хотя бы потому, что
>  pppoe это не ip и вследствие этого он по интернету в принципе ходить
>  не может.
>

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


поверьте, если вы не рядом с Яндексом, вы таких чудес в транзите
насмотритесь ...



>
>  Здесь же наверняка причина в том, что терминирующий pppoе шлюз не
>  посылает клиенту icmp на пакет с максимальным для изернета mtu,
>  хотя приделать к нему pppoe-шные хедеры тоже не может: места нет.
>  Таких кривых шлюзов немало, с этим я согласен.
>
> >   Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
> >   умолчанию и ваша голова не болит, как он там пакеты дробит и куда
> >   свои служебные заголоки фасует.
> >
> >это ровно такая же ситуация, про которую я говорил. если вы являетесь
> той
> >точкой, которая терминирует OpenVPN - вы видите
> >icmp dest unreach и обрабатываете. если OpenVPN  где-то в транзите,
> леший
> >знает, как смаршрутизируется icmp dest unreach
>
>  Никакой магии: icmp посылается на src_ip исходного пакета, и если пакет
>  был от openvpn, то icmp придёт обратно к узлу-отправителю с openvpn.
>  Тут всё детерминировано и однозначно. А тип icmp будет "frag-need".
> --
>  Eugene Berdnikov
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Thu, Sep 24, 2020 at 09:18:40PM +0500, Илья Шипицин wrote:
>чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov :
> 
>   PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может.
> 
>я примерно тыщу раз сталкивался с ситуацией
>"у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" --> в
>транзите вижу узел с днс именем, содержащим pppoe.
>примерно в 100% случаях снижение MTU на клиенте или аналогичная
>манипуляция на сервере чинили
>при этом ни у меня, ни у клиента icmp не блокировано. просто сигнализация
>идет, вероятно, с pppoe узлами в транзите.

 Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
 наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).
 "Снаружи" на pppoe icmp никогда не прилетают, хотя бы потому, что
 pppoe это не ip и вследствие этого он по интернету в принципе ходить
 не может.

 Здесь же наверняка причина в том, что терминирующий pppoе шлюз не
 посылает клиенту icmp на пакет с максимальным для изернета mtu,
 хотя приделать к нему pppoe-шные хедеры тоже не может: места нет.
 Таких кривых шлюзов немало, с этим я согласен.

>   Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
>   умолчанию и ваша голова не болит, как он там пакеты дробит и куда
>   свои служебные заголоки фасует.
> 
>это ровно такая же ситуация, про которую я говорил. если вы являетесь той
>точкой, которая терминирует OpenVPN - вы видите
>icmp dest unreach и обрабатываете. если OpenVPN  где-то в транзите, леший
>знает, как смаршрутизируется icmp dest unreach

 Никакой магии: icmp посылается на src_ip исходного пакета, и если пакет
 был от openvpn, то icmp придёт обратно к узлу-отправителю с openvpn.
 Тут всё детерминировано и однозначно. А тип icmp будет "frag-need".
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Maxim Dounin]

Hello!

On Thu, Sep 24, 2020 at 07:31:23PM +0300, Maxim Konovalov wrote:

> On 24.09.2020 19:28, Maxim Dounin wrote:
> [...]
> > Ну вот пониманию, что ICMP frag needed не работает и этот интернет 
> > не починить - уже лет 20, если не больше.  Присутствующий тут 
> > Руслан Ермилов свой tcpmssd сделал 20 лет назад.
> 
> Так это он интернет сломал?

Нет же, он зафиксировал невозможность починки.  Ну и хак с правкой 
MSS отправил в массы.

С тех пор так и живём: интернет не работает, но где-то рядом 
незримо стоит Руслан и правит MSS, чтобы большие пакетики были не 
такие большие и хотя бы иногда пролезали.  И всем кажется, что 
интернет работает.

:))

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Maxim Konovalov]

On 24.09.2020 19:28, Maxim Dounin wrote:
[...]
> Ну вот пониманию, что ICMP frag needed не работает и этот интернет 
> не починить - уже лет 20, если не больше.  Присутствующий тут 
> Руслан Ермилов свой tcpmssd сделал 20 лет назад.

Так это он интернет сломал?

-- 
Maxim Konovalov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Maxim Dounin]

Hello!

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

> чт, 24 сент. 2020 г. в 18:27, Maxim Dounin :
> 
> > 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/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Илья Шипицин]

чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov :

> On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote:
> >есть распространенное ожидание, что якобы ICMP Frag needed может
> как-то
> >помочь.
> >на самом деле - скорее нет.
> >допустим, у вас на участке сети мелкий MTU. в этом случае вы
> действительно
> >увидите ICMP Frag required.
>
>  Ч.Т.Д.
>
> >если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric,
> >whatever), то ICMP Frag required придет не вам, а туда, где
> терминируется
> >туннель.
> >благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,
> >которая идет снаружи туннеля ?
>
>
>  PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может.
>


я примерно тыщу раз сталкивался с ситуацией

"у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" --> в
транзите вижу узел с днс именем, содержащим pppoe.
примерно в 100% случаях снижение MTU на клиенте или аналогичная манипуляция
на сервере чинили

при этом ни у меня, ни у клиента icmp не блокировано. просто сигнализация
идет, вероятно, с pppoe узлами в транзите.


>
>  А обработка сигналов это задача тунеллятора. У него может быть несколько
>  стратегий:
>
>  1. ставить df=0 и не париться, шлюзы сами всю работу сделают;
>  2. ставить df=1, ловить icmp[frag-need] и дробить-собирать пакеты самому;
>  3. ставить df=1, ловить icmp и ретранслировать его на нижний уровень.
>
>  На самом деле лишь первые 2 стратегии можно нормально реализовать
>  с классическим api сокетов.
>
>  Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
>  умолчанию и ваша голова не болит, как он там пакеты дробит и куда
>  свои служебные заголоки фасует.
>


это ровно такая же ситуация, про которую я говорил. если вы являетесь той
точкой, которая терминирует OpenVPN - вы видите
icmp dest unreach и обрабатываете. если OpenVPN  где-то в транзите, леший
знает, как смаршрутизируется icmp dest unreach



>
>  Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и
>  шлют ли они нужные клиенту icmp.
>
> >очень интересно в этом плане жить в мире Windows (в нем принято
> ставить DF
> >на https),
>
>  Чем интересно? Браузерный трафик всегда идёт внутри туннеля.
>

ну смотрите. фейсбук сталкивается примерно с несколькими миллиардами
клиентов. в каких-то случаях настроенных вопреки
здравому смыслу.

и фейсбук выставляет MSS=1410. что-то в этом есть :) кажется, я понимаю,
зачем.


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

pmtud это какая-то вундервафля, которую умеют готовить в CloudFlare. я
боюсь, что это технологии, открывающие портал и призывающие
потусторонние силы. их работа за пределами понимания приматов


> --
>  Eugene Berdnikov
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote:
>есть распространенное ожидание, что якобы ICMP Frag needed может как-то
>помочь.
>на самом деле - скорее нет.
>допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно
>увидите ICMP Frag required.

 Ч.Т.Д.

>если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric,
>whatever), то ICMP Frag required придет не вам, а туда, где терминируется
>туннель.
>благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,
>которая идет снаружи туннеля ?


 PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может.

 А обработка сигналов это задача тунеллятора. У него может быть несколько
 стратегий:
 
 1. ставить df=0 и не париться, шлюзы сами всю работу сделают;
 2. ставить df=1, ловить icmp[frag-need] и дробить-собирать пакеты самому;
 3. ставить df=1, ловить icmp и ретранслировать его на нижний уровень.

 На самом деле лишь первые 2 стратегии можно нормально реализовать
 с классическим api сокетов.

 Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по
 умолчанию и ваша голова не болит, как он там пакеты дробит и куда
 свои служебные заголоки фасует.

 Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и
 шлют ли они нужные клиенту icmp.

>очень интересно в этом плане жить в мире Windows (в нем принято ставить DF
>на https),

 Чем интересно? Браузерный трафик всегда идёт внутри туннеля.
 А если туннелятор не умеет PMTUD снаружи, то какое бы DF ни было внутри,
 результат будет одинаково печальным.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Илья Шипицин]

чт, 24 сент. 2020 г. в 18:27, Maxim Dounin :

> 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 придет не вам, а туда, где терминируется
туннель.
благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,
которая идет снаружи туннеля ?


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


>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Eugene Grosbein]

24.09.2020 20:54, Vladislav V. Prodan пишет:
> 
> 
> чт, 24 сент. 2020 г. в 16:27, Maxim Dounin  >:
> 
> 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 никому не рекомендую.

+100500

> Но с нашей стороны явно имеет смысл проверить, что ICMP
> fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
> ответственности ходят нормально и не зафильтрованы.  С учётом
> того, что пинги не ходят - у меня вот лично в этом сомнения.
> 
> 
> Благодарю.
> Похоже таки проблема в MTU/PMTU.
> Выставил в туннеле MTU 1480 при MTU 1500 физическом интерфейсе и заработало.
> Подозреваю опцию
> net.ipv4.tcp_mtu_probing = 0
> на маршрутизаторе.

IPv4 PMTUD в современном (и уже лет 20 как, а то и больше) интернете сломан 
бесповоротно
и время, которое тратится на восстановление его работы в публичном интернете,
лучше потратить на что-нибудь другое.

Это не касается контролируемых сетей и до определенной степени сетей
с вменяемыми партнёрскими отношениями с их администрацией. Но для публичного 
интернета
только занижение размера пакета любыми способами; в порядке уменшения 
предпочтительности:
TCP MSS adjust, или занижение MTU на туннеле (иногда это лекарство хуже 
болезни),
или принудительное снятие флага DF.


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

чт, 24 сент. 2020 г. в 16:27, Maxim Dounin :

> 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) в зоне нашей
> ответственности ходят нормально и не зафильтрованы.  С учётом
> того, что пинги не ходят - у меня вот лично в этом сомнения.
>
>
Благодарю.
Похоже таки проблема в MTU/PMTU.
Выставил в туннеле MTU 1480 при MTU 1500 физическом интерфейсе и заработало.
Подозреваю опцию
net.ipv4.tcp_mtu_probing = 0
на маршрутизаторе.


> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Пяти секундная задержка на отправку

[Evgeniy Berdnikov]

On Thu, Sep 24, 2020 at 09:00:34AM -0400, Sergey Smirnov wrote:
> Добрый день!
> 
> Использую NGINX в качестве Load balancer.
> Столкнулся с тем, что некоторые 200 приходят с задержкой в несколько
> секунд.
> 
> Изучил логи, вижу следующее:
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED96750
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ECDFA30
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED94200, unused:
> 8
> 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED4B380, unused:
> 400
> 2020/09/24 12:37:58 [debug] 18718#0: timer delta: 1
> 2020/09/24 12:37:58 [debug] 18718#0: worker cycle
> 2020/09/24 12:37:58 [debug] 18718#0: epoll timer: -1
> //6 секунд задержки
> 2020/09/24 12:38:04 [debug] 18718#0: epoll: fd:9 ev:0001 d:7F344DCE31F0
> 2020/09/24 12:38:04 [debug] 18718#0: accept on 0.0.0.0:443, ready: 0
> 2020/09/24 12:38:04 [debug] 18718#0: posix_memalign: 7F344EC7F450:512
> @16
> 2020/09/24 12:38:04 [debug] 18718#0: *2331 accept: 192.168.10.86:55013
> fd:11
> 
> Прошу помощи, как это можно поправить? Что случилось?

 А где здесь видна задержка на отправку? По-моему, здесь 5-6 секунд между
 завершением предыдущего запроса и открытием коннекции (accept) для
 следующего, который может придти в любое время. Нужно посмотреть время
 поступления SYN-ов на балансировщик и сравнить с тем, что в логе.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Maxim Dounin]

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) в зоне нашей 
ответственности ходят нормально и не зафильтрованы.  С учётом 
того, что пинги не ходят - у меня вот лично в этом сомнения.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Пяти секундная задержка на отправку

[Sergey Smirnov]

Добрый день!

Использую NGINX в качестве Load balancer.
Столкнулся с тем, что некоторые 200 приходят с задержкой в несколько
секунд.

Изучил логи, вижу следующее:
2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED96750
2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ECDFA30
2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED94200, unused:
8
2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 7F344ED4B380, unused:
400
2020/09/24 12:37:58 [debug] 18718#0: timer delta: 1
2020/09/24 12:37:58 [debug] 18718#0: worker cycle
2020/09/24 12:37:58 [debug] 18718#0: epoll timer: -1
//6 секунд задержки
2020/09/24 12:38:04 [debug] 18718#0: epoll: fd:9 ev:0001 d:7F344DCE31F0
2020/09/24 12:38:04 [debug] 18718#0: accept on 0.0.0.0:443, ready: 0
2020/09/24 12:38:04 [debug] 18718#0: posix_memalign: 7F344EC7F450:512
@16
2020/09/24 12:38:04 [debug] 18718#0: *2331 accept: 192.168.10.86:55013
fd:11

Прошу помощи, как это можно поправить? Что случилось?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,289495,289495#msg-289495

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Eugene Grosbein]

24.09.2020 18:29, Vladislav V. Prodan пишет:

> Решил проблему с принудительной записью нужных данных в hosts.

Это не называется "решил". Это называется "замёл проблему под ковёр".

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

чт, 24 сент. 2020 г. в 14:03, Sergey Budnevitch :

> >
> > Продемонстрированная проблема ровно одна: пакетный менеджер не
> > может получить
> > 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.
>

У вас пропущено ряд промежуточных выводов.
А так понятно, вы подключили Ipv6 для галочки.

Решил проблему с принудительной записью нужных данных в hosts.




>
> nginx.org доступен по ipv6 c нескольких точек с которых я мог проверить,
> и судя по логам подключаются
> по ipv6 к nginx.org как обычно.
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Sergey Budnevitch]

> 
> Продемонстрированная проблема ровно одна: пакетный менеджер не 
> может получить 
> 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 как обычно.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru