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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
