Publiqueu un port de client VPN darrere de CGNAT: llista de verificació

Poseu un servei en un portàtil darrere d’un NAT de nivell d’operador, dirigiu aquest portàtil a un VPS per una VPN i ningú de fora no hi podrà arribar. Afegiu una regla de NAT de destinació al VPS i obteniu una cosa pitjor que el silenci: les connexions s’obren i després s’encallen. La resposta no falta, surt per la ruta predeterminada del propi client, cosa que vol dir que el servidor no la veu mai. Feu aquestes cinc comprovacions en ordre i atureu-vos a la primera que no es compleixi.

Confirmeu que el servidor reenviarà com a mínim

Marqueu aquesta casella abans d’escriure una sola traducció. El parser de regles accepta una regla DNAT per a un paquet que el nucli es nega a reenviar i després el descarta la via de reenviament, cosa que produeix un temps d’espera que sembla un problema de tallafocs.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Establir-ho en un nucli en execució no és el mateix que establir-ho entre reinicis. Escriviu net.ipv4.ip_forward=1 en un fitxer dins de /etc/sysctl.d/, executeu sysctl --system i després torneu a llegir el valor en lloc de confiar que el fitxer s’hagi recollit. Un contenidor que gestiona el seu propi espai de noms de xarxa necessita el mateix valor dins d’aquest espai, no només a l’amfitrió.

Si la lectura encara és zero, atureu-vos aquí. Res més avall no funcionarà.

Fixeu l’adreça del túnel abans que cap regla hi faci referència

El pool reparteix adreces en ordre de connexió, així que una regla escrita per al lloguer d’avui pot apuntar en silenci a un altre client la setmana que ve. Lligueu l’adreça a la identitat del certificat en lloc de a l’ordre d’arribada.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Aquest parell és l’extrem del client i l’extrem del par d’un túnel punt a punt, amb el servidor vinculat al nom comú del certificat. En una topologia de subxarxa, el segon valor es llegeix com a màscara de xarxa, així que escriviu la forma que coincideixi amb la topologia en ús. Després reconnecteu el client i llegiu l’adreça al mateix client, perquè la visió del servidor sobre el pool no és prova del que ha configurat el client.

Si l’adreça canvia després d’una reconnexió, atureu-vos. Una regla de NAT que segueix un objectiu mòbil fallarà de manera intermitent i no us ensenyarà res.

Traduïu en les dues direccions

La traducció de destinació envia el paquet entrant al client. La traducció d’origen és el que fa que el client respongui al servidor i no al remitent original, i és la regla que la gent s’oblida.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Sense la segona regla, el client respon per la seva connexió ISP ascendent, de manera que el par remot veu una adreça d’origen amb qui mai ha parlat, mentre el servidor no té cap entrada de seguiment per a la resposta. L’observador extern veu un handshake que es completa a mitges, i aquest és exactament el símptoma que porta la gent a buscar un error de tallafocs que no existeix.

Torneu a llegir les dues regles amb iptables -t nat -S i confirmeu que el nom de la interfície és el que porta l’adreça pública. En un amfitrió que ja filtra amb nftables, escriviu la traducció en una cadena NAT de nftables de la mateixa família d’adreces en lloc de barrejar eines.

Deixeu passar la taula de filtres

Les taules de NAT reescriuen capçaleres; no donen permís. Amb una política DROP predeterminada, el flux reenviat necessita la seva pròpia acceptació, més la direcció de retorn que la majoria de polítiques ja cobreixen amb una regla established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Comproveu la política de la cadena FORWARD abans d’afegir res, perquè l’ordre d’un DROP primerenc decideix si la vostra regla s’arriba a consultar. En un amfitrió el filtratge del qual viu a nftables, afegiu la regla equivalent al hook forward de la taula inet i confirmeu que la cadena base veu realment el trànsit reenviat i no només l’entrada local. Si un comptador de paquets de la regla nova es queda a zero mentre els comptadors de NAT pugen, el paquet s’està descartant abans de la vostra regla. Aquest és el senyal per llegir l’ordre de les cadenes, no per afegir una segona còpia de la mateixa regla.

Demostreu-ho des d’una xarxa externa

Proveu-ho des d’una xarxa no relacionada. Una sonda des d’una altra màquina a la mateixa LAN pot passar pel suport de NAT de forquilla i no exercitar mai el camí que fa servir un client remot, així que un resultat verd allà demostra la cosa equivocada.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Executeu la captura al servidor i al client al mateix temps. La captura del servidor mostra si el paquet traduït surt cap al túnel; la captura del client mostra si la sol·licitud arriba i on s’adreça la resposta. Una entrada de traducció a conntrack -L demostra que la regla ha coincidit, i la seva absència demostra que el paquet no va arribar mai a la cadena NAT.

Els escàners de ports són proves febles. Informen del port com a tancat fins que l’aplicació està vinculada i escoltant, així que feu servir una connexió real al servei real. Quan finalment funcioni, manteniu l’exposició en aquest únic port: reenviar SSH o un panell d’administració perquè la primera regla resultava incòmoda és una decisió molt més gran que publicar un servei.