On va el NAT de VPN a before.rules d'UFW i com provar-ho

Una regla NAT que funciona en escriure-la en un shell falla en enganxar-la a before.rules, perquè aquest fitxer no és un script. És un document en format de restauració amb seccions de taula, declaracions de cadena i una marca COMMIT per a cada taula. Una línia al lloc equivocat o avorta tota la restauració o descarta silenciosament regles que crèieu que hi eren. El manual següent posa el fragment on l'entorn l'espera i demostra el resultat abans de la propera recàrrega.

Una ordre de shell no és un fitxer de restauració

Una línia que comença amb iptables -t nat és una instrucció per al binari iptables, mentre que el fitxer que llegeix UFW és una descripció d'un conjunt de regles complet. La diferència no és cosmètica: el format de restauració ha de saber en quina taula es troba, quines cadenes existeixen i on acaba la taula. Una ordre enganxada en aquest document és o bé un error de sintaxi o, pitjor, una regla enganxada a la taula equivocada. L'entorn carrega aquests fitxers mitjançant eines de restauració precisament perquè són declaratius i no seqüencials.

El document també es carrega sencer, així que una secció mal formada pot aturar l'aplicació de la resta del fitxer. Per tant, un petit error en un fragment NAT arrossega també les regles de filtratge, i així és com un canvi de tallafoc es converteix en una caiguda.

Poseu el fragment dins la secció de taula existent

Un fragment NAT té una forma, i la forma importa més que el text de la regla que conté. La capçalera de taula obre la secció, les declaracions de cadena estableixen els comptadors, les regles segueixen i un COMMIT tanca la secció.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

El pool i la interfície de dalt són marcadors de posició per als vostres; l'estructura és la part que val la pena copiar. Si el fitxer ja conté una secció *nat, afegiu la regla dins d'aquesta secció en lloc d'obrir-ne una segona, perquè el format espera un COMMIT per taula i dues seccions per a la mateixa taula són una reparació esperant a passar. Manteniu intactes les definicions de cadena de la distribució, incloent-hi les que el proveïdor hi va afegir per a la seva pròpia integració. El manual de l'entorn UFW documenta els fitxers before, user i after juntament amb el requisit d'un COMMIT coincident.

Si el fitxer resulta estar buit, no el ompliu amb un tutorial. Confirmeu quin paquet el posseeix i quina és la política real en viu, perquè un fitxer persistent buit no demostra que el nucli no tingui regles, i un conjunt de regles carregat no demostra que la propera recàrrega tingui un fitxer complet per llegir. Restaureu primer la línia base suportada i després torneu a aplicar-hi els canvis del lloc.

Proveu el candidat sense aplicar-lo

L'eina de restauració pot analitzar i construir un conjunt de regles sense aplicar-lo, que és la prova més barata disponible. Executeu-la sobre una còpia protegida en lloc del fitxer en viu, i llegiu el text de l'error, no només l'estat de sortida. Un error d'anàlisi anomena una línia i normalment una taula, cosa que és més del que us dirà una recàrrega fallida.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Passar aquesta comprovació demostra que el document s'analitza i res més. No demostra que el candidat encara contingui totes les cadenes de les quals depèn UFW, que només permeti les fonts que volíeu o que l'administració remota segueixi essent accessible. Aquestes són revisions separades, i l'última mereix una segona sessió oberta abans de començar.

Trieu l'eina que correspongui al backend instal·lat i a la família d'adreces. Un amfitrió que executa el backend nft a través de la capa de compatibilitat necessita l'ordre corresponent, i les regles IPv6 viuen en un fitxer completament diferent.

Manteniu el reenviament, el NAT i la política d'accés separats

La traducció d'origen resol un problema d'adreçament i no atorga res. El reenviament és un permís separat controlat per un sysctl i per la taula de filtratge, i és el que la gent oblida quan un túnel encamina però no passa cap trànsit. La política d'accés és una tercera decisió sobre quines fonts poden arribar a quins serveis, i cap regla NAT l'expressa. Mantenir les tres separades és el que fa que una fallada sigui diagnosticable en lloc d'un sol símptoma vague.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Llegiu aquestes tres sortides juntes, no una a una. Una regla masquerade amb el reenviament desactivat produeix un client que es connecta i no arriba enlloc, cosa que des del costat del client sembla exactament una fallada d'encaminament i envia la gent al fitxer equivocat. La taula de filtratge és també on s'amaga un accept massa ampli, així que comproveu-ne la política per defecte mentre hi sou.

Verifiqueu una recàrrega, una denegació i una pèrdua de VPN

Tres observacions fan una prova d'acceptació completa: la recàrrega té èxit, una operació de client permesa funciona i una petició que s'hauria de refusar es refusa de fet. La tercera és la que es passa per alt, i és l'única evidència que la política fa alguna cosa.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Després proveu la fallada per a la qual heu dissenyat. Deixeu caure el túnel i observeu què fa l'amfitrió, perquè una política que només funciona mentre la VPN està activa és una política amb una dependència no declarada. Recarregueu una vegada més després per demostrar que és el fitxer, i no un estat d'execució romanent, el que produeix el resultat funcional.

El NAT d'IPv4 no diu res sobre IPv6, així que indiqueu la cobertura prevista per a les dues famílies en la mateixa nota que la regla. L'objectiu és una política gestionada coherent, i un fragment que va resultar analitzable no n'és cap prova.