Есть локалка 192.168.0.0/24 со шлюзом в интернеты 192.168.0.231
На шлюзе хостится корпоративный сайтец для частных нужд с мануалами, ФАКами, некоторым файлом и прочим хламом.
Соответственно, внутри сети сайтец доступен по IP http(s)://192.168.0.231, либо по локальному доменному имени http(s)://myrouter.local, а снаружи по mydomain.com (ну либо по внешнему IP 111.222.333.444/32, естественно).
Дабы упростить себе жизнь, и сделать его доступным в локалке по тому же mydomain.com, на шлюзе прописаны следующие правила iptables:
-A OUTPUT -d 111.222.333.444/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.231:80
-A OUTPUT -d 111.222.333.444/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.0.231:443
Что заставляет локальные запросы на внешний интерфейс перенаправлять прозрачно для клиентов в локалку, и в случае с http(s) оно работает.
Недавно потребовалось в этой же локалке приподнять OpenVPN (192.168.0.2), и чтобы так же упростить себе жизнь, имея общий конфиг для локалки и внешних клиентов, где в качестве сервера был бы указан mydomain.com 1194, было нарисовано такое правило:
-A OUTPUT -d 111.222.333.444/32 -p udp -m udp --dport 1194 -j DNAT --to-destination 192.168.0.2:1194
В результате доходит до hadshake, ответ не приходит и openvpn начинает попытку переподключения, считая, что сервак недоступен. Догадываюсь, что не хватает какого-то обратного правила, но какого?
P.S. последнее правило в цепочке nat
-A POSTROUTING -o eth0 -j MASQUERADE
Но влияет ли оно на что то?
