Hairpin NAT с динамическим WAN IP?

@rotten777 Ты уже решил свою проблему? Мне тоже нужно настроить hairpin NAT, но у меня динамический публичный IP-адрес.

dst-address — это WAN IP, а src-address — локальный NAT IP...

Извиняюсь, что воскрешаю тему, но хочу убедиться, что правильно всё понял — add action=masquerade chain=srcnat dst-address=192.168.77.20 src-address=192.168.77.0/24 Эта правило, по сути, берёт весь трафик, направленный на 192.168.77.20 и идущий из 77.0/24, и применяет к нему действие masquerade, правильно? То есть роутер считает трафик исходящим из внешнего мира и применяет к нему уже настроенные правила переадресации (например, проброс портов 80 и/или 443 на этот IP)? Я всё верно понял? Ещё раз извиняюсь, что поднимаю старую тему, но подумал, что так будет лучше, чем начинать новую. Похоже на простое и элегантное решение, интересно, не упускаю ли я чего, и может ли это создать проблемы с безопасностью (передача трафика наружу, когда это не нужно). Спасибо!

Нет, как уже отметил Джарда, это правило скрывает исходный (SOURCE) адрес от сервера. (Кстати, «Некромант тредов» заставил меня улыбнуться.) Особенность hairpin NAT в том, что нужно делать NAT не только для целевого адреса/портов, переводя их на внутренний адрес, но и для исходного адреса — так, чтобы внутренний хост отправлял ответы обратно роутеру. В части DSTNAT в случае hairpin нет ничего особенного — обычное правило DSTNAT подходит как для входящих подключений, так и для hairpin, дополнительных правил для этого не нужно.

А вот часть с SRCNAT обязательна, но применять её нужно только тогда, когда источник находится в той же сети, что и внутренний IP хоста. Проще всего использовать действие MASQUERADE.

Если не сделать srcnat, hairpin ломается по такой причине: внутренний хост 192.168.77.19 делает запрос TCP:80 к публичному IP a.b.c.d — источником этого запроса остаётся 192.168.77.19. Роутер аккуратно меняет адрес назначения на внутренний адрес и порт (например, 192.168.77.80:80). Если роутер не замаскирует исходный адрес на «внешний» относительно внутреннего сервера, сервер увидит, что источник — 192.168.77.19, а это локальный адрес. Тогда внутренний хост отправит ответ напрямую другому хосту (не через роутер). Проблема в том, что внутренний хост не знает, что он за NAT, поэтому ответ пойдёт на 192.168.77.19, а источник в ответе будет 192.168.77.80 — когда этот пакет придёт на исходный хост, тот не распознает его как ответ, ведь ожидал ответ с a.b.c.d:80, и просто отбросит этот пакет.

С правилом hairpin внутренний веб-сервер увидит, что запрос пришёл от роутера, и отправит ответ обратно роутеру. Роутер продолжит «врать», как и раньше, и отправит ответ реальному хосту, сделав dst=192.168.77.19, а source — A.B.C.D:80.