Cal aplicar SNAT a una redirecció de port cap a una subxarxa VPN?

Redirigir un port cap a un amfitrió que és darrere del propi client VPN del router falla d'una manera que sembla un problema de tallafocs, perquè la petició arriba clarament. El servei registra una connexió, el client espera i no torna res. La traducció de destinació va fer la seva feina; el paquet de tornada és la part que va desaparèixer. Una regla selectiva de NAT d'origen al router ho arregla, i la part interessant és decidir com d'estreta pot ser aquesta regla.

Per què la resposta agafa un altre camí

Una redirecció de port reescriu on va un paquet, mai d'on ve. L'adreça del client d'internet es queda al camp d'origen durant tot el túnel, així que el servei remot veu un desconegut i respon de l'única manera que sap: a través de la seva pròpia passarel·la per defecte. Aquesta passarel·la és el concentrador VPN de l'altre costat, que no té cap ruta de tornada a una adreça pública arbitrària.

Mireu una captura a la interfície del túnel i l'asimetria és òbvia: paquets de petició sortint, res entrant. La cadena de redirecció va permetre el flux i el túnel el va portar, així que la caiguda passa després que l'amfitrió remot ja hagi triat un camí de tornada.

Una regla d'origen prou estreta per confiar-hi

Feu que el router sigui l'origen al qual respon l'amfitrió remot. En aquesta disposició l'adreça WAN és 203.0.113.24, la LAN és 192.168.88.0/24, l'adreça del túnel del router és 172.20.5.1, i el servei respon a 172.20.5.40:8443. La regla de sota coincideix amb el paquet després de la traducció de destinació, i per això nomena l'adreça traduïda i no la pública. Res no hi depèn de l'adreça del client, i aquest és exactament el punt.

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 coincidència d'aquella línia existeix per mantenir la reescriptura local a un servei en un túnel. Traieu la interfície o el port i reescriviu més trànsit del que el problema requereix, i així és com una correcció dirigida es converteix en un misteri per a la següent persona.

Quan una màscara global és l'opció honesta

Si el router redirigeix molts serveis a la mateixa subxarxa VPN, una regla per servei es converteix en una llista que ningú manté. Emmascarar tot el que surt de la interfície del túnel és més simple i predictible, a costa d'amagar el client original de cada amfitrió de l'altre costat. Trieu-ho quan els registres d'allà no s'usen per a atribució; manteniu la regla estreta quan sí que s'usen.

Les dues opcions també fallen de maneres diferents. Una regla estreta absent trenca un servei; una màscara àmplia que coincideix amb massa coses pot reescriure en silenci trànsit que ja funcionava, incloent-hi les connexions sortints del propi router.

Comproveu els comptadors abans de publicar

Les regles que no coincideixen mai semblen idèntiques a les que funcionen fins que compteu paquets. Torneu a llegir la taula amb comptadors de bytes abans que cap client es connecti, després connecteu-vos des d'una xarxa que no sigui la LAN i torneu-la a llegir. Dues lectures són el que converteix una suposició en un fet. Publiqueu la redirecció només després que la segona es mogui.

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

Un comptador a zero a la regla d'origen després d'una connexió real vol dir que la coincidència és incorrecta, normalment perquè la destinació o el port no coincideixen amb el paquet després de la traducció. Si el comptador puja però el client encara fa temps d'espera, el camí de tornada està arreglat i una altra cosa descarta la resposta, així que mireu després la política de redirecció de l'altre costat. L'accés en forquilla des de dins de la LAN és un problema a part i necessita la seva pròpia regla, no una versió més àmplia d'aquesta.