ufw allow 443 no va fer res per un servei darrere la VPN

El ping funciona des d'un client VPN, el servei TCP expira i ufw allow 443/tcp no canvia absolutament res. Quan l'aplicació s'executa en un amfitrió darrere de la passarel·la i no a la passarel·la mateixa, aquest permís es va escriure per a un camí de trànsit equivocat. El paquet no va adreçat al tallafoc i no es lliura a cap procés local, així que les regles d'entrada no el veuen mai. La reparació és una regla de ruta adreçada al flux reenviat, i la prova ja és al registre.

Decideix si la destinació és local o reenviada

Llegeix el paquet tal com el veu el nucli. El trànsit lliurat a un servei de la passarel·la és entrada local. El trànsit que la passarel·la encamina cap a un altre amfitrió és reenviat, i UFW manté conjunts de regles separats per als dos camins. La distinció la decideixen l'adreça de destinació i la consulta d'encaminament, no la interfície per la qual va arribar el paquet.

Una línia de registre que mostra la mateixa interfície als camps IN i OUT pot descriure igualment un paquet encaminat, perquè un túnel que porta clients endins i enfora d'un sol dispositiu es veu exactament així. L'adreça de destinació resol la pregunta més de pressa que els noms de les interfícies. Veure el mateix nom dues vegades no demostra un lliurament local, i inventar una interfície de túnel que el desplegament mai va crear tampoc no ajuda.

Llegeix el bloc abans d'afegir cap regla

Reprodueix un intent de connexió autoritzat i captura'n l'origen, la destinació, el protocol i el port de destinació tal com els va registrar la passarel·la. Compara aquests quatre valors amb l'entrada del registre i amb la ubicació real del servei. Un ping correcte anterior només demostra que el seu propi intercanvi estava permès, i un tallafoc pot tractar un TCP SYN cap a una aplicació de manera molt diferent.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

La primera ordre retorna el veredicte amb les seves tuplas, i la segona mostra què ja està carregat i en quin ordre. Llegeix totes dues abans d'editar res, perquè una denegació anterior per sobre de la teva regla explica el mateix símptoma sense cap regla que falti.

Escriu la regla de ruta més estreta que encaixi

En aquest exemple, els clients arriben per tun0 des de 172.20.8.0/24, el servei escolta a 10.30.0.15 al port 8443, i la passarel·la surt per ens5. Aquests valors es van triar perquè no s'assemblin a un valor per defecte de VPC al núvol de 10.0.0.0/16 ni a una xarxa domèstica de 192.168.0.0/16, i 8443 manté l'exemple lluny del propi escoltador 443 de la passarel·la.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

L'execució en sec imprimeix el conjunt de regles que en resultaria, que és la manera més barata de veure si la teva regla cau abans o després d'una denegació existent. Confirma els noms d'interfície i les adreces internes contra el desplegament i no contra l'exemple, i recorda que quan la NAT de destinació s'executa primer, el filtre veu la destinació traduïda.

Mantén el camí de tornada amb estat

UFW fa seguiment de les connexions permeses, així que les respostes a un flux reenviat permès s'admeten sense una regla inversa explícita. Afegir una regla sense restriccions en la direcció oposada perquè les coses funcionin amplia la política molt més enllà del servei únic i no cal per a un intercanvi normal de petició i resposta. Mantén el camí de tornada implícit i el conjunt de regles llegible.

Aplica la regla només quan l'execució en sec coincideixi amb la teva intenció, i després confirma que la llista ordenada la mostra a la posició esperada. Conserva l'escoltador de la VPN i les regles de gestió com a assumptes separats; canviar-los és una decisió diferent d'admetre una aplicació. Anota el canvi allà on s'escriu la topologia, perquè el proper enginyer no l'hagi de redescobrir a partir d'una captura de paquets.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Comprova què no pot fer complir UFW per tu

Una regla correcta encara necessita el reenviament del nucli i una ruta que arribi al servei. Confirma-ho totes dues coses abans de culpar el tallafoc una segona vegada.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Després mira fora de l'amfitrió. En una instància al núvol, la política d'UFW del convidat no substitueix els grups de seguretat, les ACL de subxarxa ni la configuració de reenviament del proveïdor, així que un bloc local és una prova sobre una capa i no la prova que totes les altres capes permetin el servei.

Acaba provant una connexió nova amb el tallafoc activat, des d'una font permesa i des d'una altra de no relacionada. Desactivar UFW elimina el símptoma i destrueix la prova en la mateixa ordre, i per això hauria de ser l'últim experiment i no el primer.