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

[Sergey Budnevitch]

> On 16 Oct 2020, at 00:06, sergio  wrote:
> 
> Уважаемые администраторы, проверьте пожалуйста, что на вашей стороне не 
> фильтруется ICMPv6, в частности packet-too-big.

Не фильтруется.

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

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

[sergio]

Уважаемые администраторы, проверьте пожалуйста, что на вашей стороне не 
фильтруется ICMPv6, в частности packet-too-big.


On 13/10/2020 09:46, sergio wrote:

On 24/09/2020 16:26, Maxim Dounin wrote:


Но с нашей стороны явно имеет смысл проверить, что ICMP
fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
ответственности ходят нормально и не зафильтрованы.  С учётом
того, что пинги не ходят - у меня вот лично в этом сомнения.



Есть подозрение, что действительно зафильтрованы. Проверьте пожалуйста.



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

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

[sergio]

On 24/09/2020 16:26, Maxim Dounin wrote:


Но с нашей стороны явно имеет смысл проверить, что ICMP
fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
ответственности ходят нормально и не зафильтрованы.  С учётом
того, что пинги не ходят - у меня вот лично в этом сомнения.



Есть подозрение, что действительно зафильтрованы. Проверьте пожалуйста.


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

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

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

пт, 9 окт. 2020 г. в 15:50, Vladislav V. Prodan :

>
>
> пт, 9 окт. 2020 г. в 13:34, Илья Шипицин :
>
>>
>>
>> пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan :
>>
>>>
>>>
>>> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин :
>>>


 пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
> >   Насчёт "самая распостранённая" -- статистика есть? Как её
> вообще
> >  собирать?
> >
> >по нашей оценке 1 пользователь на 10 тысяч пользователей
> сталкивается с
> >поломанным MTU
>
>  Какое значение MSS анонсируют ваши серверы?
>

 1416

>>>
>>> Здравствуйте.
>>> И как вы на сервере (с nginx) это изменили?
>>>
>>
>> iptables
>>
>>
>
> А можно более подробно это правило показать?
>

NDA.

можно подсмотреть вот тут https://www.opennet.ru/docs/RUS/LARTC/x2657.html


>
> ___
> 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

[Vladislav V. Prodan]

пт, 9 окт. 2020 г. в 13:34, Илья Шипицин :

>
>
> пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan :
>
>>
>>
>> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин :
>>
>>>
>>>
>>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>>>
 On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
 >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
 >  собирать?
 >
 >по нашей оценке 1 пользователь на 10 тысяч пользователей
 сталкивается с
 >поломанным MTU

  Какое значение MSS анонсируют ваши серверы?

>>>
>>> 1416
>>>
>>
>> Здравствуйте.
>> И как вы на сервере (с nginx) это изменили?
>>
>
> iptables
>
>

А можно более подробно это правило показать?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

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

пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan :

>
>
> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин :
>
>>
>>
>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>>
>>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>>> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>>> >  собирать?
>>> >
>>> >по нашей оценке 1 пользователь на 10 тысяч пользователей
>>> сталкивается с
>>> >поломанным MTU
>>>
>>>  Какое значение MSS анонсируют ваши серверы?
>>>
>>
>> 1416
>>
>
> Здравствуйте.
> И как вы на сервере (с nginx) это изменили?
>

iptables


>
> ___
> 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

[Vladislav V. Prodan]

пт, 25 сент. 2020 г. в 19:53, Илья Шипицин :

>
>
> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>
>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>> >  собирать?
>> >
>> >по нашей оценке 1 пользователь на 10 тысяч пользователей
>> сталкивается с
>> >поломанным MTU
>>
>>  Какое значение MSS анонсируют ваши серверы?
>>
>
> 1416
>

Здравствуйте.
И как вы на сервере (с nginx) это изменили?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Eugene Grosbein]

26.09.2020 18:31, Evgeniy Berdnikov пишет:

>  Я просил конкретный пример. Что здесь в icmp, какой ip "внешний"?

Внешний = публично маршрутизируемый. IP-адрес назначения в любом ответном 
входящем ICMP-пакете,
пришедшем на NAT-box снаружи, будет внешним.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Sat, Sep 26, 2020 at 04:07:10AM +0700, Eugene Grosbein wrote:
> 26.09.2020 0:45, Evgeniy Berdnikov пишет:
> 
> > On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote:
> >>>  Есть только одна нормальная политика: доставить icmp по назначению.
> >> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP.
> > 
> >  Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать.
> 
> Да почему же невалидные. NAT ведь разный бывает, например может быть
> "клиент" с выделенной ему сеткой 100.64.0.0/24 и выделенным же одним внешним 
> IP,
> весь исходящий трафик из сетки транслируется в такой "персональный" внешний 
> IP,
> весь входящий трафик на этот IP, не являющийся ответным, транслируется 1:1
> на 100.64.0.1, что позволяет клиенту "публиковать сервисы".

 Я просил конкретный пример. Что здесь в icmp, какой ip "внешний"?
 
> Пропускать ли снаружи внутрь ICMP echo-request, которые могут быть с 
> заниженным TTL
> (traceroute probes) и хотя бы частично покажут внутренную часть сети за NAT
> между самим NAT и 100.64.0.1 ? Там может быть более одного хопа.
> Кто-то не пропускает. А пропускать ли такие же ICMP need-fragment?
> Кто-то не пропускает и ломает PMTUD.

 ICMP[frag-need] валиден лишь если он относится к открытому соединению,
 точнее, к существующей записи в контраке. Иначе icmp[frag-need] невалиден.
 
 В принципе пропускать же icmp[frag-need] можно любые, потому что ядро
 пользовательской системы точно так же должно проверять привязку icmp
 к установленному соединению, и по rfc обязано игнорировать невалидные.
 Но лучше мусор за nat не пропускать.

 Политика фильтрации может применяться только к тем типам icmp, которые
 к существованию записи в контраке не привязаны, скажем, для echo-request.
 Но не для echo-reply! Если кто-то делает иначе, в том числе тупо запрещает
 icmp внутрь, то он просто не понимает, что ломает базовые алгоримы ip.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[alicesafr]

Покажешь свою фотографию?

Saturday, 26.09.2020 0:30:45 от eu...@grosbein.net:___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[alicesafr]

Покажешь свою фотографию?

Friday, 25.09.2020 20:25:40 от s...@zxy.spb.ru:___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[alicesafr]

Покажешь свою фотографию?

Friday, 25.09.2020 19:34:17 от b...@protva.ru:___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Slawa Olhovchenkov]

On Fri, Sep 25, 2020 at 08:51:53PM +0300, Evgeniy Berdnikov wrote:

> On Fri, Sep 25, 2020 at 08:37:22PM +0300, Slawa Olhovchenkov wrote:
> > > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но 
> > > отказались
> > 
> > побитно тогда уж!
> > как он не кратный четерем может быть-то?
> 
>  Анонсированный MSS -- запросто. :)) Вписал нечётный в правило, и вуаля.
>  Iptables пропустит и ядро линикса поставит. Насчёт фрюх и цисок не знаю.

ну и зачем дураков копировать?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Eugene Grosbein]

26.09.2020 0:45, Evgeniy Berdnikov пишет:

> On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote:
>>>  Есть только одна нормальная политика: доставить icmp по назначению.
>> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP.
> 
>  Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать.

Да почему же невалидные. NAT ведь разный бывает, например может быть
"клиент" с выделенной ему сеткой 100.64.0.0/24 и выделенным же одним внешним IP,
весь исходящий трафик из сетки транслируется в такой "персональный" внешний IP,
весь входящий трафик на этот IP, не являющийся ответным, транслируется 1:1
на 100.64.0.1, что позволяет клиенту "публиковать сервисы".

Пропускать ли снаружи внутрь ICMP echo-request, которые могут быть с заниженным 
TTL
(traceroute probes) и хотя бы частично покажут внутренную часть сети за NAT
между самим NAT и 100.64.0.1 ? Там может быть более одного хопа.
Кто-то не пропускает. А пропускать ли такие же ICMP need-fragment?
Кто-то не пропускает и ломает PMTUD.


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

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

[Evgeniy Berdnikov]

On Fri, Sep 25, 2020 at 08:37:22PM +0300, Slawa Olhovchenkov wrote:
> > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались
> 
> побитно тогда уж!
> как он не кратный четерем может быть-то?

 Анонсированный MSS -- запросто. :)) Вписал нечётный в правило, и вуаля.
 Iptables пропустит и ядро линикса поставит. Насчёт фрюх и цисок не знаю.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Evgeniy Berdnikov]

On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote:
> >  Есть только одна нормальная политика: доставить icmp по назначению.
> 
> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP.

 Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать.

> >  Все остальные политики ущербны, IMHO. Я лично никогда не встречал
> >  разумных "соображний безопасности", которые могли бы оправдать поломку
> >  одного из из базовых механизмов ip-стэка.
> 
> А вот некоторые считают, что пропускать ICMP внутрь NAT вообще не следует :-)

 Есть внятные аргументы кроме "хихи-хаха" и смайликов?

> >  Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?
> 
> По количеству инсталляций стека.

 Ну и как посчитать количество инсталяций? И где эта статистика по сломанным
 инсталлированным стэкам? Мне кажется это пустой трёп, но покажите.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Slawa Olhovchenkov]

On Fri, Sep 25, 2020 at 10:30:01PM +0500, Илья Шипицин wrote:

> > > мы итерационно подошли к этой цифре.
> > > я попросил техподдержку эскалировать на меня кейсы, когда они
> > подкручивали
> > > MTU на клиенте.
> > >
> > > и на очередном клиенты мы по одному байту крутили
> >
> > а чего по байту-то?
> >
> 
> делением пополам, конечно.
> 
> я к сожалению не документировал шаги. самому было бы интересно посмотреть.
> из того, что вспоминается, было две итерации, когда подгоняли под клиента.
> 
> за первую мы снизились до 1456 кажется. и потом был еще один клиент, мы
> упали до 1416
> 
> теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались

побитно тогда уж!
как он не кратный четерем может быть-то?
___
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 23:34, Evgeniy Berdnikov пишет:

> On Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote:
>> 25.09.2020 11:32, Evgeniy Berdnikov wrote:
>>>  Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак.
>>
>> Да.
>>
>>>  Поэтому бывает лишь на крайних хопах.
>>
>> Нет. Это утверждение никак не связано с предыдущим и из него не вытекает,
>> слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по 
>> PPPoE,
>> а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ другой 
>> сети.
> 
>  Из "технически возможно" не следует "разумно и оправдано". Нужно иногда
>  включать здравый смысл. PPPoE сделано для подключения для подключения
>  множества клиентов к одному хабу, главная его цель -- авторизация клиента.

Это никак не противоречит тому, что у "клиента" может быть сегментированная 
сеть,
и даже распределенная сегментированная сеть.

>  Никто в здравом рассудке ТАК подключать аплинки на магистральном
>  маршрутизаторе не будет.

PPPoE в данном случае лишь один вариант, когда MTU трассы оказывается меньше 
чем 1500,
и да, я не оправдываю оператора связи, который даунлинкам-операторам даёт такую 
трассу,
но И ТАКОЕ тоже бывало.

>> Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со входящим 
>> "снаружи"
>> ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) 
>> IP-пакет,
>> изначально отправленного "изнутри"? Подсказка: существуют как минимум две 
>> разные
>> политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И она же
>> самая распространенная.
> 
>  Есть только одна нормальная политика: доставить icmp по назначению.

В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP.

>  Все остальные политики ущербны, IMHO. Я лично никогда не встречал
>  разумных "соображний безопасности", которые могли бы оправдать поломку
>  одного из из базовых механизмов ip-стэка.

А вот некоторые считают, что пропускать ICMP внутрь NAT вообще не следует :-)

>  Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?

По количеству инсталляций стека.

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

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

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

пт, 25 сент. 2020 г. в 22:25, Slawa Olhovchenkov :

> On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:
>
> > >> >   Насчёт "самая распостранённая" -- статистика есть? Как её
> вообще
> > >> >  собирать?
> > >> >
> > >> >по нашей оценке 1 пользователь на 10 тысяч пользователей
> > >> сталкивается с
> > >> >поломанным MTU
> > >>
> > >>  Какое значение MSS анонсируют ваши серверы?
> > >>
> > >
> > > 1416
> > >
> > >
> >
> > мы итерационно подошли к этой цифре.
> > я попросил техподдержку эскалировать на меня кейсы, когда они
> подкручивали
> > MTU на клиенте.
> >
> > и на очередном клиенты мы по одному байту крутили
>
> а чего по байту-то?
>

делением пополам, конечно.

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

за первую мы снизились до 1456 кажется. и потом был еще один клиент, мы
упали до 1416

теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались



> ___
> 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

[Slawa Olhovchenkov]

On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:

> >> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
> >> >  собирать?
> >> >
> >> >по нашей оценке 1 пользователь на 10 тысяч пользователей
> >> сталкивается с
> >> >поломанным MTU
> >>
> >>  Какое значение MSS анонсируют ваши серверы?
> >>
> >
> > 1416
> >
> >
> 
> мы итерационно подошли к этой цифре.
> я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали
> MTU на клиенте.
> 
> и на очередном клиенты мы по одному байту крутили

а чего по байту-то?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

пт, 25 сент. 2020 г. в 19:54, Илья Шипицин :

>
>
> пт, 25 сент. 2020 г. в 21:52, Илья Шипицин :
>
>>
>>
>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>>
>>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>>> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>>> >  собирать?
>>> >
>>> >по нашей оценке 1 пользователь на 10 тысяч пользователей
>>> сталкивается с
>>> >поломанным MTU
>>>
>>>  Какое значение MSS анонсируют ваши серверы?
>>>
>>
>> 1416
>>
>>
>
> мы итерационно подошли к этой цифре.
> я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали
> MTU на клиенте.
>
> и на очередном клиенты мы по одному байту крутили
> ну и получилось очень близко к фейсбуку (у них 1410)
>
> Есть ли еще статистика по использованию MSS у крупных сервисов?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

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

пт, 25 сент. 2020 г. в 22:00, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:
> > Какое значение MSS анонсируют ваши серверы?
> >
> >  1416
> >
> >
> >мы итерационно подошли к этой цифре.
> >я попросил техподдержку эскалировать на меня кейсы, когда они
> подкручивали
> >MTU на клиенте.
> >и на очередном клиенты мы по одному байту крутили
> >ну и получилось очень близко к фейсбуку (у них 1410)
>
>  Спасибо.
>
>  Хотелось бы ещё уточнить: 1/10,000 -- это после подкручивания или до?
>

количество обращений в поддержку, завершившихся подкручиванием MTU.
до подкручивания.

после подкручивания практически в ноль упало. было одно обращение, когда
крутили MTU до 1300.
мы решили больше не трогать MSS

потому что это уменьшает объем полезной нагрузки per packet


> --
>  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 Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:
> Какое значение MSS анонсируют ваши серверы?
> 
>  1416
>   
> 
>мы итерационно подошли к этой цифре.
>я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали
>MTU на клиенте.
>и на очередном клиенты мы по одному байту крутили
>ну и получилось очень близко к фейсбуку (у них 1410)

 Спасибо.

 Хотелось бы ещё уточнить: 1/10,000 -- это после подкручивания или до?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

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

пт, 25 сент. 2020 г. в 21:52, Илья Шипицин :

>
>
> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :
>
>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>> >  собирать?
>> >
>> >по нашей оценке 1 пользователь на 10 тысяч пользователей
>> сталкивается с
>> >поломанным MTU
>>
>>  Какое значение MSS анонсируют ваши серверы?
>>
>
> 1416
>
>

мы итерационно подошли к этой цифре.
я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали
MTU на клиенте.

и на очередном клиенты мы по одному байту крутили
ну и получилось очень близко к фейсбуку (у них 1410)


> --
>>  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

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

пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
> >  собирать?
> >
> >по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается
> с
> >поломанным MTU
>
>  Какое значение MSS анонсируют ваши серверы?
>

1416


> --
>  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 Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>  собирать?
> 
>по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается с
>поломанным MTU

 Какое значение MSS анонсируют ваши серверы?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

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

пт, 25 сент. 2020 г. в 21:34, Evgeniy Berdnikov :

> On Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote:
> > 25.09.2020 11:32, Evgeniy Berdnikov wrote:
> > >  Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может.
> Никак.
> >
> > Да.
> >
> > >  Поэтому бывает лишь на крайних хопах.
> >
> > Нет. Это утверждение никак не связано с предыдущим и из него не вытекает,
> > слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по
> PPPoE,
> > а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ
> другой сети.
>
>  Из "технически возможно" не следует "разумно и оправдано". Нужно иногда
>  включать здравый смысл. PPPoE сделано для подключения для подключения
>  множества клиентов к одному хабу, главная его цель -- авторизация клиента.
>  Никто в здравом рассудке ТАК подключать аплинки на магистральном
>  маршрутизаторе не будет.
>
> > Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со
> входящим "снаружи"
> > ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки)
> IP-пакет,
> > изначально отправленного "изнутри"? Подсказка: существуют как минимум
> две разные
> > политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И
> она же
> > самая распространенная.
>
>  Есть только одна нормальная политика: доставить icmp по назначению.
>  Все остальные политики ущербны, IMHO. Я лично никогда не встречал
>  разумных "соображний безопасности", которые могли бы оправдать поломку
>  одного из из базовых механизмов ip-стэка.
>
>  Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?
>

по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается с
поломанным MTU


> --
>  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 Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote:
> 25.09.2020 11:32, Evgeniy Berdnikov wrote:
> >  Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак.
> 
> Да.
> 
> >  Поэтому бывает лишь на крайних хопах.
> 
> Нет. Это утверждение никак не связано с предыдущим и из него не вытекает,
> слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по 
> PPPoE,
> а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ другой 
> сети.

 Из "технически возможно" не следует "разумно и оправдано". Нужно иногда
 включать здравый смысл. PPPoE сделано для подключения для подключения
 множества клиентов к одному хабу, главная его цель -- авторизация клиента.
 Никто в здравом рассудке ТАК подключать аплинки на магистральном
 маршрутизаторе не будет.

> Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со входящим 
> "снаружи"
> ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) 
> IP-пакет,
> изначально отправленного "изнутри"? Подсказка: существуют как минимум две 
> разные
> политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И она же
> самая распространенная.

 Есть только одна нормальная политика: доставить icmp по назначению.
 Все остальные политики ущербны, IMHO. Я лично никогда не встречал
 разумных "соображний безопасности", которые могли бы оправдать поломку
 одного из из базовых механизмов ip-стэка.

 Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать?
-- 
 Eugene Berdnikov
___
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 11:32, Evgeniy Berdnikov wrote:

>>>  Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите"
>>>  наверняка нет (они могут быть лишь на 2м и предпоследнем хопе).
>> О, сколько вам открытий чудных готовит просвященья дух!
>> Даже операторы связи бывают такие, что у них MTU трассы во внешний мир 
>> меньше 1500,
>> я встречал, что уж говорить о корпоративных и домашних сетях.
> 
>  Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак.

Да.

>  Поэтому бывает лишь на крайних хопах.

Нет. Это утверждение никак не связано с предыдущим и из него не вытекает,
слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по PPPoE,
а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ другой 
сети.

>> А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT,
>> за которой в одном или несколькими хопами (а не непосредственно на ней)
>> стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше 
>> клиенты.
> 
>  Эта "магия" для tcp и udp ничего сложного не представляет, она уже лет 20
>  работает и в линуксах, и в бсд, и в цисках. Магию не осилили зиксели и
>  прочие китайцы, да, но не потому что там что-то сверхсложное. У неасиливших
>  вообще всё плохо, там даже icmp[source-quench] можно встретить. :)
 
Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со входящим 
"снаружи"
ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) IP-пакет,
изначально отправленного "изнутри"? Подсказка: существуют как минимум две разные
политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И она же
самая распространенная.


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

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: Проблемы со связностью по 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

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

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

[AsderManas]

Stop send emil gay

Sergey Budnevitch  ezt írta (időpont: 2020. szept. 23., Sze
17:05):

>
> On 23 Sep 2020, at 16:59, Vladislav V. Prodan  wrote:
>
> Ну, и заодно "помешайте" NS  сервера для доменов nginx.com nginx.net
> nginx.org.
>
>
> Это бессмысленное занятие, если добавлены glue records,
> для зон nginx.com & nginx.org glue records они существуют.
>
>
> Например,
>  nginx.com
> nginx.com name server ns.nginx.net.
> nginx.com name server ns2.nginx.com.
> nginx.com name server ns3.nginx.org.
>
>
> ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan :
>
>>
>>
>> ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch :
>>
>>> Добрый день
>>>
>>> Резолвер клиенты какой используют?
>>>
>>
>> Здравствуйте.
>> Клиент получает и Ipv6 и Ipv4 ресолвер.
>> Первым, получается, используется ipv6 ресолвер.
>>
>>
>>
>>>
>>> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov  wrote:
>>> >
>>> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
>>> >>   Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
>>> >>   ресолвится первый раз, второй и последующие - ресолвится, потом
>>> через два
>>> >>   часа по новой.
>>> >
>>> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером,
>>> чем
>>> > nginx-то в этом провинился?
>>> >
>>> >>   Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
>>> >>   (подключение).
>>> >
>>> > Каким образом это может исправить ситуацию? Изложите механизм чуда.
>>> >
>>> >>   А пока вынуждены таким костылем пользоваться:
>>> >>
>>> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null
>>> >
>>> > Это скорее не костыль, а шаманство.
>>> > --
>>> > 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
>>
>> ___
> 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

ср, 23 сент. 2020 г. в 22:24, Maxim Dounin :

> Hello!
>
> On Wed, Sep 23, 2020 at 08:43:08PM +0300, Vladislav V. Prodan wrote:
>
> > ср, 23 сент. 2020 г. в 19:14, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote:
> > >
> > > > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch :
> > > >
> > > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan 
> > > wrote:
> > > > >
> > > > >
> > > > > Попытался воспроизвести проблему.
> > > > >
> > > > > Server: 8.8.8.8
> > > > > Address:8.8.8.8#53
> > > > >
> > > > > Non-authoritative answer:
> > > > > Name:   nginx.org
> > > > > Address: 3.125.197.172
> > > > > Name:   nginx.org
> > > > > Address: 52.58.199.22
> > > > > Name:   nginx.org
> > > > > Address: 2a05:d014:edb:5702::6
> > > > > Name:   nginx.org
> > > > > Address: 2a05:d014:edb:5704::6
> > > > >
> > > > > Сущ:1 http://security.debian.org/debian-security buster/updates
> > > InRelease
> > > > > Сущ:2 http://deb.debian.org/debian buster InRelease
> > > > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease
> > > > > Сущ:4 https://packages.sury.org/php buster InRelease
> > > > > Ошб:5 http://nginx.org/packages/debian buster InRelease
> > > > >   Соединение разорвано [IP: 2a05:d014:edb:5704::6 80]
> > > > > Чтение списков пакетов… Готово
> > > > > W: Не удалось получить
> > > > > http://nginx.org/packages/debian/dists/buster/InRelease
> Соединение
> > > > > разорвано [IP: 2a05:d014:edb:5704::6 80]
> > > > > W: Некоторые индексные файлы скачать не удалось. Они были
> > > проигнорированы,
> > > > > или вместо них были использованы старые версии.
> > > > > Чтение списков пакетов… Готово
> > > > >
> > > > >
> > > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит
> с
> > > > > соединением.
> > > > >
> > > >
> > > > Спасибо.
> > > > Я подожду, когда вы разберетесь с настройками ipv6 в AWS.
> > >
> > > Модель поведения - публично облажаться, после чего нахамить и
> > > слиться - понятная, но не конструктивная.
> >
> > Здравствуйте, Максим.
> > Имеет место три проблемы, связанные с DNS, Ipv6 и вашим хостингом на AWS.
>
> Продемонстрированная проблема ровно одна: пакетный менеджер не
> может получить
> http://nginx.org/packages/debian/dists/buster/InRelease с
> IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения.
>
> Почему не может - вопрос для дополнительного разбирательства.
> Которое вы, почему-то, проводить не хотите даже на минимальном
> уровне.
>
> Какие-либо проблемы с DNS - не продемонстрированы.  Наоброт,
> продемострировано, что если и есть какие-то теоретические
> претензии к DNS, как то отсутствие IPv6 NS-серверов, то они не
> относятся к наблюдаемой проблеме.
>
> > > Явно имеет место
> > > какая-то проблема, и возможно она на нашей стороне.  Поскольку в
> > > настоящий момент вы единственный, у кого она проявляется - только
> > > вы можете разобраться, что происходит.
> > >
> >
> > Да, я вижу. На обоих трассах с he.net потери 3-10% на хопах внутри
> Амазона.
> > Кроме вас ну никто не может обратиться в ТП Амазона с указанными
> потерями.
> > И при условии, что вы внутри не намудрили с списками доступами и
> firewall.
>
> Потери в современном интернете, к сожалению, довольно трудно
> оценивать, ибо ICMP, даже если и не зафильтрован, обрабатывается
> по остаточном принципу.  Но так или иначе потери не объясняют
> наблюдаемое вами поведение.
>
> > > Я бы начал с простого: проверил, получается ли запросить
> > > упомянутый URL с проблемного IP-адреса руками, например:
> > >
> >
> > Еще раз прочтите первое сообщение.
> > НЕ работает первый запрос, второй и последующие - работают.
> > И перестают работать где-то через час-два.
>
> Ну вот и попробуйте запросить руками через час-два.  Лучше - с
> tcpdump'ом, чтобы видеть, что при этом происходит на уровне сети.
> И ещё можно Сергею скинуть IP-адрес, чтобы он посмотрел на
> происходящее со стороны сервера.
>
> (И да, в первом сообщении написано про "домен не ресолвится первый
> раз", что, как мы уже выяснили, не соответствует действительности.
> Не надо, пожалуйста, продолжать хамить, это гарантировано не
> приведёт ни к чему хорошему.  Спасибо.)
>

Чтобы воспроизвести нересолвинг мне нужно подольше время, чтоб у "внешних"
ресолверов протухли TTL записи.



>
> --
> 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

[Vladislav V. Prodan]

ср, 23 сент. 2020 г. в 19:14, Maxim Dounin :

> Hello!
>
> On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote:
>
> > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch :
> >
> > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan 
> wrote:
> > >
> > >
> > > Попытался воспроизвести проблему.
> > >
> > > Server: 8.8.8.8
> > > Address:8.8.8.8#53
> > >
> > > Non-authoritative answer:
> > > Name:   nginx.org
> > > Address: 3.125.197.172
> > > Name:   nginx.org
> > > Address: 52.58.199.22
> > > Name:   nginx.org
> > > Address: 2a05:d014:edb:5702::6
> > > Name:   nginx.org
> > > Address: 2a05:d014:edb:5704::6
> > >
> > > Сущ:1 http://security.debian.org/debian-security buster/updates
> InRelease
> > > Сущ:2 http://deb.debian.org/debian buster InRelease
> > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease
> > > Сущ:4 https://packages.sury.org/php buster InRelease
> > > Ошб:5 http://nginx.org/packages/debian buster InRelease
> > >   Соединение разорвано [IP: 2a05:d014:edb:5704::6 80]
> > > Чтение списков пакетов… Готово
> > > W: Не удалось получить
> > > http://nginx.org/packages/debian/dists/buster/InRelease  Соединение
> > > разорвано [IP: 2a05:d014:edb:5704::6 80]
> > > W: Некоторые индексные файлы скачать не удалось. Они были
> проигнорированы,
> > > или вместо них были использованы старые версии.
> > > Чтение списков пакетов… Готово
> > >
> > >
> > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с
> > > соединением.
> > >
> >
> > Спасибо.
> > Я подожду, когда вы разберетесь с настройками ipv6 в AWS.
>
> Модель поведения - публично облажаться, после чего нахамить и
> слиться - понятная, но не конструктивная.


Здравствуйте, Максим.
Имеет место три проблемы, связанные с DNS, Ipv6 и вашим хостингом на AWS.


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

Да, я вижу. На обоих трассах с he.net потери 3-10% на хопах внутри Амазона.
Кроме вас ну никто не может обратиться в ТП Амазона с указанными потерями.
И при условии, что вы внутри не намудрили с списками доступами и firewall.


>
> Я бы начал с простого: проверил, получается ли запросить
> упомянутый URL с проблемного IP-адреса руками, например:
>

Еще раз прочтите первое сообщение.
НЕ работает первый запрос, второй и последующие - работают.
И перестают работать где-то через час-два.


P.S. И не судите о других по своим заключениям/измышлениям.


>
> $ curl -vso /dev/null --resolve nginx.org:80:[2a05:d014:edb:5704::6]
> http://nginx.org/packages/debian/dists/buster/InRelease
> * Added nginx.org:80:[2a05:d014:edb:5704::6] to DNS cache
> * Hostname nginx.org was found in DNS cache
> *   Trying 2a05:d014:edb:5704::6:80...
> * Connected to nginx.org (2a05:d014:edb:5704::6) port 80 (#0)
> > GET /packages/debian/dists/buster/InRelease HTTP/1.1
> > Host: nginx.org
> > User-Agent: curl/7.72.0
> > Accept: */*
> >
> * Mark bundle as not supporting multiuse
> < HTTP/1.1 200 OK
> < Server: nginx/1.19.0
> < Date: Wed, 23 Sep 2020 16:10:59 GMT
> < Content-Type: application/octet-stream
> < Content-Length: 2854
> < Last-Modified: Tue, 11 Aug 2020 17:08:59 GMT
> < Connection: keep-alive
> < Keep-Alive: timeout=15
> < ETag: "5f32d0ab-b26"
> < Accept-Ranges: bytes
> <
> { [2854 bytes data]
> * Connection #0 to host nginx.org left intact
>
>
> --
> 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

[Maxim Dounin]

Hello!

On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote:

> ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch :
> 
> > On 23 Sep 2020, at 17:58, Vladislav V. Prodan  wrote:
> >
> >
> > Попытался воспроизвести проблему.
> >
> > Server: 8.8.8.8
> > Address:8.8.8.8#53
> >
> > Non-authoritative answer:
> > Name:   nginx.org
> > Address: 3.125.197.172
> > Name:   nginx.org
> > Address: 52.58.199.22
> > Name:   nginx.org
> > Address: 2a05:d014:edb:5702::6
> > Name:   nginx.org
> > Address: 2a05:d014:edb:5704::6
> >
> > Сущ:1 http://security.debian.org/debian-security buster/updates InRelease
> > Сущ:2 http://deb.debian.org/debian buster InRelease
> > Сущ:3 http://deb.debian.org/debian buster-updates InRelease
> > Сущ:4 https://packages.sury.org/php buster InRelease
> > Ошб:5 http://nginx.org/packages/debian buster InRelease
> >   Соединение разорвано [IP: 2a05:d014:edb:5704::6 80]
> > Чтение списков пакетов… Готово
> > W: Не удалось получить
> > http://nginx.org/packages/debian/dists/buster/InRelease  Соединение
> > разорвано [IP: 2a05:d014:edb:5704::6 80]
> > W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы,
> > или вместо них были использованы старые версии.
> > Чтение списков пакетов… Готово
> >
> >
> > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с
> > соединением.
> >
> 
> Спасибо.
> Я подожду, когда вы разберетесь с настройками ipv6 в AWS.

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

Я бы начал с простого: проверил, получается ли запросить 
упомянутый URL с проблемного IP-адреса руками, например:

$ curl -vso /dev/null --resolve nginx.org:80:[2a05:d014:edb:5704::6] 
http://nginx.org/packages/debian/dists/buster/InRelease
* Added nginx.org:80:[2a05:d014:edb:5704::6] to DNS cache
* Hostname nginx.org was found in DNS cache
*   Trying 2a05:d014:edb:5704::6:80...
* Connected to nginx.org (2a05:d014:edb:5704::6) port 80 (#0)
> GET /packages/debian/dists/buster/InRelease HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.72.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.19.0
< Date: Wed, 23 Sep 2020 16:10:59 GMT
< Content-Type: application/octet-stream
< Content-Length: 2854
< Last-Modified: Tue, 11 Aug 2020 17:08:59 GMT
< Connection: keep-alive
< Keep-Alive: timeout=15
< ETag: "5f32d0ab-b26"
< Accept-Ranges: bytes
< 
{ [2854 bytes data]
* Connection #0 to host nginx.org left intact


-- 
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

[Vladislav V. Prodan]

ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch :

>
>
> On 23 Sep 2020, at 17:58, Vladislav V. Prodan  wrote:
>
>
> Попытался воспроизвести проблему.
>
> Server: 8.8.8.8
> Address:8.8.8.8#53
>
> Non-authoritative answer:
> Name:   nginx.org
> Address: 3.125.197.172
> Name:   nginx.org
> Address: 52.58.199.22
> Name:   nginx.org
> Address: 2a05:d014:edb:5702::6
> Name:   nginx.org
> Address: 2a05:d014:edb:5704::6
>
> Сущ:1 http://security.debian.org/debian-security buster/updates InRelease
> Сущ:2 http://deb.debian.org/debian buster InRelease
> Сущ:3 http://deb.debian.org/debian buster-updates InRelease
> Сущ:4 https://packages.sury.org/php buster InRelease
> Ошб:5 http://nginx.org/packages/debian buster InRelease
>   Соединение разорвано [IP: 2a05:d014:edb:5704::6 80]
> Чтение списков пакетов… Готово
> W: Не удалось получить
> http://nginx.org/packages/debian/dists/buster/InRelease  Соединение
> разорвано [IP: 2a05:d014:edb:5704::6 80]
> W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы,
> или вместо них были использованы старые версии.
> Чтение списков пакетов… Готово
>
>
> То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с
> соединением.
>

Спасибо.
Я подожду, когда вы разберетесь с настройками ipv6 в AWS.



>
> ___
> 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]

> On 23 Sep 2020, at 17:58, Vladislav V. Prodan  wrote:
> 
> 
> Попытался воспроизвести проблему.
> 
> Server: 8.8.8.8
> Address:8.8.8.8#53
> 
> Non-authoritative answer:
> Name:   nginx.org 
> Address: 3.125.197.172
> Name:   nginx.org 
> Address: 52.58.199.22
> Name:   nginx.org 
> Address: 2a05:d014:edb:5702::6
> Name:   nginx.org 
> Address: 2a05:d014:edb:5704::6
> 
> Сущ:1 http://security.debian.org/debian-security 
>  buster/updates InRelease
> Сущ:2 http://deb.debian.org/debian  buster 
> InRelease
> Сущ:3 http://deb.debian.org/debian  
> buster-updates InRelease
> Сущ:4 https://packages.sury.org/php  buster 
> InRelease
> Ошб:5 http://nginx.org/packages/debian  
> buster InRelease
>   Соединение разорвано [IP: 2a05:d014:edb:5704::6 80]
> Чтение списков пакетов… Готово
> W: Не удалось получить 
> http://nginx.org/packages/debian/dists/buster/InRelease 
>   Соединение 
> разорвано [IP: 2a05:d014:edb:5704::6 80]
> W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы, 
> или вместо них были использованы старые версии.
> Чтение списков пакетов… Готово

То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с 
соединением.

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

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

[Sergey Budnevitch]

> On 23 Sep 2020, at 16:59, Vladislav V. Prodan  wrote:
> 
> Ну, и заодно "помешайте" NS  сервера для доменов nginx.com 
>  nginx.net  nginx.org 
> .

Это бессмысленное занятие, если добавлены glue records,
для зон nginx.com & nginx.org glue records они существуют.

> 
> Например,
>  nginx.com 
> nginx.com  name server ns.nginx.net .
> nginx.com  name server ns2.nginx.com 
> .
> nginx.com  name server ns3.nginx.org 
> .
> 
> 
> ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan  >:
> 
> 
> ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch  >:
> Добрый день
> 
> Резолвер клиенты какой используют?
> 
> Здравствуйте.
> Клиент получает и Ipv6 и Ipv4 ресолвер.
> Первым, получается, используется ipv6 ресолвер.
> 
>  
> 
> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov  > > wrote:
> > 
> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
> >>   Если у клиента ipv6 адрес, то домен nginx.org  
> >> гарантированно не
> >>   ресолвится первый раз, второй и последующие - ресолвится, потом через два
> >>   часа по новой.  
> > 
> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем 
> > nginx-то в этом провинился?
> > 
> >>   Как решение проблемы, добавить NS для nginx.org , 
> >> имеющий ipv6 адрес
> >>   (подключение).
> > 
> > Каким образом это может исправить ситуацию? Изложите механизм чуда.
> > 
> >>   А пока вынуждены таким костылем пользоваться:
> >> 
> >> ping -4 -w 1 -c 1 -q nginx.org  >> /dev/null
> > 
> > Это скорее не костыль, а шаманство.
> > -- 
> > 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 
> ___
> 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

[Vladislav V. Prodan]

Попытался воспроизвести проблему.

Server: 8.8.8.8
Address:8.8.8.8#53

Non-authoritative answer:
Name:   nginx.org
Address: 3.125.197.172
Name:   nginx.org
Address: 52.58.199.22
Name:   nginx.org
Address: 2a05:d014:edb:5702::6
Name:   nginx.org
Address: 2a05:d014:edb:5704::6

Сущ:1 http://security.debian.org/debian-security buster/updates InRelease
Сущ:2 http://deb.debian.org/debian buster InRelease
Сущ:3 http://deb.debian.org/debian buster-updates InRelease
Сущ:4 https://packages.sury.org/php buster InRelease
Ошб:5 http://nginx.org/packages/debian buster InRelease
  Соединение разорвано [IP: 2a05:d014:edb:5704::6 80]
Чтение списков пакетов… Готово
W: Не удалось получить
http://nginx.org/packages/debian/dists/buster/InRelease  Соединение
разорвано [IP: 2a05:d014:edb:5704::6 80]
W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы,
или вместо них были использованы старые версии.
Чтение списков пакетов… Готово


ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch :

> Добрый день
>
> Резолвер клиенты какой используют?
>
> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov  wrote:
> >
> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
> >>   Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
> >>   ресолвится первый раз, второй и последующие - ресолвится, потом через
> два
> >>   часа по новой.
> >
> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем
> > nginx-то в этом провинился?
> >
> >>   Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
> >>   (подключение).
> >
> > Каким образом это может исправить ситуацию? Изложите механизм чуда.
> >
> >>   А пока вынуждены таким костылем пользоваться:
> >>
> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null
> >
> > Это скорее не костыль, а шаманство.
> > --
> > 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

Ну, и заодно "помешайте" NS  сервера для доменов nginx.com nginx.net
nginx.org.

Например,
 nginx.com
nginx.com name server ns.nginx.net.
nginx.com name server ns2.nginx.com.
nginx.com name server ns3.nginx.org.


ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan :

>
>
> ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch :
>
>> Добрый день
>>
>> Резолвер клиенты какой используют?
>>
>
> Здравствуйте.
> Клиент получает и Ipv6 и Ipv4 ресолвер.
> Первым, получается, используется ipv6 ресолвер.
>
>
>
>>
>> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov  wrote:
>> >
>> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
>> >>   Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
>> >>   ресолвится первый раз, второй и последующие - ресолвится, потом
>> через два
>> >>   часа по новой.
>> >
>> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем
>> > nginx-то в этом провинился?
>> >
>> >>   Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
>> >>   (подключение).
>> >
>> > Каким образом это может исправить ситуацию? Изложите механизм чуда.
>> >
>> >>   А пока вынуждены таким костылем пользоваться:
>> >>
>> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null
>> >
>> > Это скорее не костыль, а шаманство.
>> > --
>> > 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
>
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch :

> Добрый день
>
> Резолвер клиенты какой используют?
>

Здравствуйте.
Клиент получает и Ipv6 и Ipv4 ресолвер.
Первым, получается, используется ipv6 ресолвер.



>
> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov  wrote:
> >
> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
> >>   Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
> >>   ресолвится первый раз, второй и последующие - ресолвится, потом через
> два
> >>   часа по новой.
> >
> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем
> > nginx-то в этом провинился?
> >
> >>   Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
> >>   (подключение).
> >
> > Каким образом это может исправить ситуацию? Изложите механизм чуда.
> >
> >>   А пока вынуждены таким костылем пользоваться:
> >>
> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null
> >
> > Это скорее не костыль, а шаманство.
> > --
> > 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Sergey Budnevitch]

Добрый день

Резолвер клиенты какой используют?

> On 23 Sep 2020, at 09:19, Evgeniy Berdnikov  wrote:
> 
> On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
>>   Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
>>   ресолвится первый раз, второй и последующие - ресолвится, потом через два
>>   часа по новой.  
> 
> Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем 
> nginx-то в этом провинился?
> 
>>   Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
>>   (подключение).
> 
> Каким образом это может исправить ситуацию? Изложите механизм чуда.
> 
>>   А пока вынуждены таким костылем пользоваться:
>> 
>> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null
> 
> Это скорее не костыль, а шаманство.
> -- 
> 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 Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote:
>Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
>ресолвится первый раз, второй и последующие - ресолвится, потом через два
>часа по новой.  

 Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем 
 nginx-то в этом провинился?
 
>Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
>(подключение).

 Каким образом это может исправить ситуацию? Изложите механизм чуда.

>А пока вынуждены таким костылем пользоваться:
> 
>  ping -4 -w 1 -c 1 -q nginx.org >> /dev/null

 Это скорее не костыль, а шаманство.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

[Vladislav V. Prodan]

Здравствуйте.

Если у клиента ipv6 адрес, то домен nginx.org гарантированно не
ресолвится первый раз, второй и последующие - ресолвится, потом через два
часа по новой.

Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес
(подключение).

А пока вынуждены таким костылем пользоваться:

ping -4 -w 1 -c 1 -q nginx.org >> /dev/null

Спасибо.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru