On Thu, Sep 24, 2020 at 09:18:40PM +0500, Илья Шипицин wrote:
> чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov <bgx@protva.ru>:
>
>  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