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