Debes aplicar SNAT a unha redirección de port cara a unha subrede VPN?

Redirixir un port a un host que está detrás do propio cliente VPN do router falla dun xeito que parece un problema de firewall, porque a petición chega claramente. O servizo rexistra unha conexión, o cliente espera e non volve nada. A tradución de destino fixo o seu traballo; o paquete de volta é a parte que desapareceu. Unha regra selectiva de NAT de orixe no router arranxa isto, e a parte interesante é decidir canto pode ser de estreita esa regra.

Por que a resposta toma outro camiño

Unha redirección de port reescribe a onde vai un paquete, nunca de onde veu. O enderezo do cliente de internet queda no campo de orixe durante todo o túnel, así que o servizo remoto ve un descoñecido e responde do único xeito que sabe: pola súa propia pasarela predeterminada. Esa pasarela é o concentrador VPN do outro lado, que non ten ruta de volta a un enderezo público arbitrario.

Mira unha captura na interface do túnel e a asimetría é obvia: paquetes de petición cara a fóra, nada cara a dentro. A cadea de redirección permitiu o fluxo e o túnel transportouno, así que o descarte ocorre despois de que o host remoto xa elixise un camiño de volta.

Unha regra de orixe bastante estreita para confiar nela

Fai que o router sexa a orixe á que responde o host remoto. Nesta disposición o enderezo WAN é 203.0.113.24, a LAN é 192.168.88.0/24, o enderezo do túnel do router é 172.20.5.1, e o servizo responde en 172.20.5.40:8443. A regra de abaixo coincide co paquete despois da tradución de destino, por iso nomea o enderezo traducido e non o público. Nada nela depende do enderezo do cliente, e ese é exactamente o punto.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Cada coincidencia desa liña existe para manter a reescritura local a un servizo nun túnel. Quita a interface ou o port e reescribirás máis tráfico do que o problema require, e así é como unha corrección dirixida se converte nun misterio para a seguinte persoa.

Cando unha máscara global é a opción honesta

Se o router redirixe moitos servizos á mesma subrede VPN, unha regra por servizo convértese nunha lista que ninguén mantén. Mascarar todo o que sae da interface do túnel é máis simple e previsible, a costa de ocultar o cliente orixinal a cada host do outro lado. Escólleo cando os rexistros de alí non se usen para atribución; mantén a regra estreita cando si se usen.

As dúas opcións tamén fallan de xeito distinto. Unha regra estreita ausente rompe un servizo; unha máscara ampla que coincide con demasiado pode reescribir en silencio tráfico que xa funcionaba, incluídas as conexións saíntes do propio router.

Comproba os contadores antes de publicar

As regras que nunca coinciden vense idénticas ás que funcionan ata que contas paquetes. Volve ler a táboa con contadores de bytes antes de que se conecte calquera cliente, despois conéctate desde unha rede que non sexa a LAN e volve lela. Dúas lecturas son o que converte unha suposición nun feito. Publica a redirección só despois de que se mova a segunda.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Un contador a cero na regra de orixe tras unha conexión real significa que a coincidencia é incorrecta, normalmente porque o destino ou o port non coinciden co paquete despois da tradución. Se o contador sobe pero o cliente aínda esgota o tempo, o camiño de volta está arranxado e outra cousa descarta a resposta, así que mira despois a política de redirección do outro lado. O acceso en forcada desde dentro da LAN é un problema aparte e necesita a súa propia regra, non unha versión máis ampla desta.