VPN al router o reenviament de port: quin guanya?

El router acaba el VPN ell mateix, i una regla de reenviament antiga encara envia el mateix port UDP a una màquina de la LAN. Només una de les dues pot ser el punt final real, i el nucli no arbitra. La traducció de destinació reescriu el paquet abans que es consulti el servei local, així que el procés VPN espera trànsit que ja s’ha enviat a una altra banda. La tasca és decidir qui posseeix el port i després fer que les regles coincideixin.

Un port, dos propietaris reclamats

Un servidor VPN que s’executa dins del router necessita un permís d’entrada que porti al seu propi sòcol. Una entrada de NAT de destinació per al mateix port porta a un lloc completament diferent: una adreça de la LAN i una decisió de reenviament. Són punts finals diferents amb registres diferents i maneres de fallar diferents. La pista habitual és que una família d’adreces funciona i l’altra no, perquè l’entrada sobrant es va escriure per a una sola família i mai es va revisar.

Anota la reclamació abans d’editar: família, adreça externa, transport, port i l’objectiu traduït.

La traducció va abans de la comprovació local

El NAT de destinació canvia l’objectiu del paquet a l’etapa de prerouting, abans que el nucli triï entre el lliurament local i el reenviament. Quan l’objectiu és un amfitrió de la LAN, el paquet pren el camí de reenviament. Les regles d’entrada per al sòcol propi del router no es consulten mai, i per això el registre del VPN queda buit mentre el client venç.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Aquest ordre és tot el mecanisme, i les interfícies dels aparells l’amaguen darrere de caselles sense canviar-lo. El propietari de la destinació continua decidint quin camí pren un paquet.

Si l’amfitrió de la LAN és el punt final previst, el reenviament és correcte i el router no hauria d’escoltar també en aquest port.

Conserva una assignació i elimina l’altra

Llista les entrades NAT per a aquest port i família i tria el supervivent:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Una entrada TCP amb el mateix número és irrellevant per a una fallada UDP, i tractar-les com un sol objecte porta a esborrar la regla equivocada. Quan el sòcol local ha de guanyar, el propietari de l’assignació conflictiva elimina o reescriu aquesta entrada, i el permís d’entrada per al port propi del router es queda al lloc. Els reenviaments no relacionats, el camí de gestió i una còpia del conjunt de regles haurien de sobreviure al canvi.

Si el VPN viu en un amfitrió separat, el reenviament és l’objecte correcte. Un servei en un contenidor o màquina virtual pot necessitar un port publicat fins i tot quan la caixa es diu router, així que segueix el sòcol i el seu espai de noms, no l’etiqueta de la caixa.

Confirma el propietari des de fora

Prova cada família per separat, perquè una connexió IPv6 que acaba al router no diu res d’una connexió IPv4 que una regla antiga redirigeix. Llegeix el registre del servei receptor per veure quin punt final ha respost, i tracta el missatge d’èxit del client com una prova feble. Cal un flux nou per a una prova significativa. Envia una sonda des d’un amfitrió extern amb nc -zvu 203.0.113.7 1194 i llegeix el registre del guanyador amb journalctl -u openvpn@server -n 20. El receptor del router registra la connexió ell mateix, mentre que un amfitrió de la LAN la registra al seu propi servei.

El seguiment de connexions manté els fluxos existents a la seva assignació original, així que una sessió establerta pot sobreviure a la regla que acabes de corregir.

Quan el punt final previst respongui amb les seves comprovacions d’identitat habituals, prova un recurs privat darrere del túnel. Arribar al receptor exterior només és el primer salt; l’encaminament interior i l’autorització de l’aplicació són resultats separats.