SNAT, DNAT i Masquerade: què fa cada regla NAT de VPN

Poseu una captura als dos costats d’una passarel·la VPN i un sol flux pot mostrar quatre adreces diferents. El NAT d’origen reescriu d’on diu el paquet que ve; el NAT de destinació reescriu on va. Masquerade no és una tercera direcció, és una regla de NAT d’origen que pren l’adreça de la interfície de sortida en lloc d’un valor fix. Concreteu quina de les tres necessiteu de veritat i la majoria de tiquets de «la VPN no funciona» es redueixen a una pregunta sobre el camí de tornada.

Què reescriu cada regla

El NAT d’origen, normalment escrit SNAT, canvia l’adreça d’origen d’un flux quan surt d’un encaminador o d’una passarel·la. El servei receptor respon a l’adreça traduïda, i la caixa que tradueix desfà el canvi amb l’estat que ha guardat per a aquella connexió. A Linux aquest estat viu a conntrack, i per això conntrack -L imprimeix les tuples original i de resposta una al costat de l’altra.

El NAT de destinació, DNAT, canvia la destinació en lloc de l’origen. Un paquet adreçat a una adreça pública a UDP 51820 es pot reescriure cap a un servidor WireGuard intern a 10.8.0.2:51820. Així és com un encaminador domèstic o un balancejador al núvol publica un escoltador VPN, i això no diu res sobre què pot transportar el túnel després.

Masquerade pertany a la família SNAT. La regla no anomena cap adreça; fa servir la que tingui la interfície de sortida quan el paquet surt. Linux li dona un objectiu propi, i és l’opció habitual en una interfície WAN que obté l’adreça per DHCP o PPPoE.

On viu el mapatge decideix la fallada

Anoteu la tupla a cada frontera: abans del túnel, dins seu i a la interfície pública. Una captura dins del túnel difereix legítimament d’una de fora, i qui compara les dues sense saber on passa la traducció perseguirà l’amfitrió equivocat.

El trànsit de tornada ha de passar pel dispositiu que guarda el mapatge. Si la resposta pren una altra ruta, un segon enllaç ascendent, una ruta de política o un proveïdor que mai no ha sentit parlar del vostre rang privat, la traducció inversa amb estat no passa mai i el client veu trànsit en un sol sentit. Afegir més NAT d’origen poques vegades arregla una ruta de tornada absent; pot amagar el símptoma en un flux mentre trenca la política basada en adreces a tota la resta.

L’altre error habitual és esperar que un túnel creï encaminabilitat. Un client privat els paquets del qual surten a internet necessita un arranjament de sortida vàlid: una ruta per defecte, una passarel·la que reenvia i, normalment, traducció d’origen a una adreça pública. El xifratge per si sol no fa arribable una adreça privada.

Masquerade o SNAT explícit

Compareu-les pel que prometen. Masquerade tria l’adreça de sortida, el SNAT explícit la fixa. En una passarel·la amb una adreça pública estable, fixar-la dona als registres i a les llistes de permesos dels socis un valor predictible. En un enllaç WAN dinàmic, una adreça SNAT fixada esdevé incorrecta en el moment que canvia la concessió, i és exactament el cas per al qual es va crear Masquerade.

L’abast importa tant com l’elecció. Una regla Masquerade que coincideix amb cada paquet que surt de la passarel·la, sense límit d’origen ni de destinació, també tradueix trànsit que volíeu mantenir intacte, inclòs el trànsit cap a altres xarxes privades. Limiteu la regla al rang de clients, a la destinació prevista i a la interfície.

L’IPsec basat en polítiques és on això mossega més fort. La guia de reenviament de strongSwan explica com habilitar el reenviament IP i afegir una regla de SNAT per als clients, i la mateixa documentació cobreix com excloure el trànsit que ha de conservar la seva adreça original. Traduïu una font abans que la política de seguretat hi coincideixi i el túnel pot aixecar-se mentre el trànsit encara cau, perquè el paquet ja no s’assembla al selector que es va negociar.

Decidiu també què ha de veure l’extrem llunyà. Després de la traducció un servei veu la passarel·la, no el client individual. Això simplifica l’encaminament de tornada i alhora aplana els registres i inutilitza les llistes de permesos per client. Si conservar les adreces dels clients importa, planifiqueu un camí de tornada encaminat en lloc d’amagar-les per fer passar una prova.

Llegir les regles en una passarel·la Linux

Una passarel·la d’accés remot amb clients a 10.8.0.0/24 i una interfície WAN anomenada eth0 necessita el reenviament habilitat i una política de filtratge que permeti el flux abans que cap regla NAT pugui ajudar. La versió d’iptables manté totes dues direccions a la taula nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

La forma d’nftables fa servir els mateixos dos ganxos amb una interfície nomenada i una cadena explícita:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Tots dos fragments assumeixen que la cadena de filtratge ja accepta el flux reenviat. NAT no és una regla de permís, i un paquet traduït correctament encara es pot descartar una taula més enllà. Confirmeu el mapatge viu amb conntrack -L, confirmeu què està carregat amb nft list ruleset o iptables-save -t nat, i després captureu a les dues interfícies per veure que l’adreça canvia de debò.

Maneres de fallar que semblen una regla dolenta

El trànsit de forquilla és el clàssic. Un client intern que arriba a un servidor intern per l’adreça pública del servidor necessita el DNAT a l’entrada i una traducció d’origen a la sortida de tornada, o el servidor respon directament al client i la resposta es rebutja. La correcció és una segona regla, més estreta, per a aquest cas d’intern a públic, no una regla Masquerade més àmplia per a tot.

La traducció doble és la silenciosa. Un client que ja és darrere d’un NAT d’operador arriba a la vostra passarel·la amb una adreça que no podeu encaminar de tornada, així que torneu a traduir. Funciona, però els registres ara porten dos salts d’adreçament privat i qualsevol investigació necessita tots dos mapatges. L’IPsec basat en polítiques afegeix un tercer gir: traduïu abans que coincideixi la política i obteniu una SA aixecada sense trànsit que passi, cosa que es llegeix com un error del tallafoc i no del NAT.

Després hi ha la prova que passa i el desplegament que falla. Executar la comanda NAT a mà demostra el mecanisme, no la configuració. Una regla afegida en temps d’execució desapareix en reiniciar o en el següent esdeveniment d’interfície, i una regla Masquerade lligada a una interfície que canvia de número pot canviar en silenci l’adreça que veu l’extrem llunyà. Posa la regla a la configuració del tallafoc que la posseeix i torna a provar després d’una reconnexió.

Llista de comprovació abans de desar la regla

Primer nomeu la direcció: origen, destinació o totes dues. Després identifiqueu qui ha de guardar l’estat — la passarel·la, l’encaminador de dalt o el parell IPsec — i confirmeu que el camí de tornada hi torna. Limiteu la regla al rang de clients, la destinació i la interfície que realment voleu, i decidiu per endavant si l’extrem llunyà ha de veure la passarel·la o l’adreça original del client.

Proveu des d’un client, no des de la passarel·la. Un navegador a la mateixa passarel·la pot saltar-se del tot la regla de traducció de clients, així que una pàgina que hi funcioni no demostra res sobre el túnel. Envieu una petició originada pel client, observeu els comptadors i la taula de conntrack, i repetiu-ho després d’una reconnexió del túnel i d’un canvi d’adreça WAN si alguna de les dues coses és possible on treballeu.