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