<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov <<a href="mailto:bgx@protva.ru">bgx@protva.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote:<br>
>    есть распространенное ожидание, что якобы ICMP Frag needed может как-то<br>
>    помочь.<br>
>    на самом деле - скорее нет.<br>
>    допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно<br>
>    увидите ICMP Frag required.<br>
<br>
 Ч.Т.Д.<br>
<br>
>    если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric,<br>
>    whatever), то ICMP Frag required придет не вам, а туда, где терминируется<br>
>    туннель.<br>
>    благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию,<br>
>    которая идет снаружи туннеля ?<br>
<br>
<br>
 PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может.<br></blockquote><div><br></div><div><br></div><div>я примерно тыщу раз сталкивался с ситуацией <br></div><div><br></div><div>"у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" --> в транзите вижу узел с днс именем, содержащим pppoe.</div><div>примерно в 100% случаях снижение MTU на клиенте или аналогичная манипуляция на сервере чинили</div><div><br></div><div>при этом ни у меня, ни у клиента icmp не блокировано. просто сигнализация идет, вероятно, с pppoe узлами в транзите.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 А обработка сигналов это задача тунеллятора. У него может быть несколько<br>
 стратегий:<br>
<br>
 1. ставить df=0 и не париться, шлюзы сами всю работу сделают;<br>
 2. ставить df=1, ловить icmp[frag-need] и дробить-собирать пакеты самому;<br>
 3. ставить df=1, ловить icmp и ретранслировать его на нижний уровень.<br>
<br>
 На самом деле лишь первые 2 стратегии можно нормально реализовать<br>
 с классическим api сокетов.<br>
<br>
 Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по<br>
 умолчанию и ваша голова не болит, как он там пакеты дробит и куда<br>
 свои служебные заголоки фасует.<br></blockquote><div><br></div><div><br></div><div>это ровно такая же ситуация, про которую я говорил. если вы являетесь той точкой, которая терминирует OpenVPN - вы видите</div><div>icmp dest unreach и обрабатываете. если OpenVPN  где-то в транзите, леший знает, как смаршрутизируется icmp dest unreach<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и<br>
 шлют ли они нужные клиенту icmp.<br>
<br>
>    очень интересно в этом плане жить в мире Windows (в нем принято ставить DF<br>
>    на https),<br>
<br>
 Чем интересно? Браузерный трафик всегда идёт внутри туннеля.<br></blockquote><div><br></div><div>ну смотрите. фейсбук сталкивается примерно с несколькими миллиардами клиентов. в каких-то случаях настроенных вопреки</div><div>здравому смыслу.</div><div><br></div><div>и фейсбук выставляет MSS=1410. что-то в этом есть :) кажется, я понимаю, зачем.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 А если туннелятор не умеет PMTUD снаружи, то какое бы DF ни было внутри,<br>
 результат будет одинаково печальным.<br></blockquote><div><br></div><div>pmtud это какая-то вундервафля, которую умеют готовить в CloudFlare. я боюсь, что это технологии, открывающие портал и призывающие</div><div>потусторонние силы. их работа за пределами понимания приматов<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
 Eugene Berdnikov<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>