VPN no router ou redirección de porto: cal gaña?

O router remata o VPN por si mesmo, e unha regra de redirección antiga segue enviando o mesmo porto UDP a unha máquina da LAN. Só unha das dúas pode ser o punto final real, e o núcleo non arbitra. A tradución de destino reescribe o paquete antes de consultar o servizo local, así que o proceso VPN espera tráfico que xa se enviou a outro sitio. A tarefa é decidir quen posúe o porto e despois facer que as regras coincidan.

Un porto, dous propietarios reclamados

Un servidor VPN que se executa dentro do router necesita un permiso de entrada que leve ao seu propio socket. Unha entrada de NAT de destino para o mesmo porto leva a un sitio completamente distinto: un enderezo da LAN e unha decisión de redirección. Son puntos finais diferentes con rexistros diferentes e modos de fallo diferentes. A pista habitual é que unha familia de enderezos funciona e a outra non, porque a entrada sobrante escribiuse para unha soa familia e nunca se revisou.

Anota a reclamación antes de editar: familia, enderezo externo, transporte, porto e o obxectivo traducido.

A tradución vai antes da comprobación local

O NAT de destino cambia o obxectivo do paquete na etapa de prerouting, antes de que o núcleo elixa entre entrega local e redirección. Cando o obxectivo é un host da LAN, o paquete toma a ruta de redirección. As regras de entrada para o socket propio do router nunca se consultan, por iso o rexistro do VPN queda baleiro mentres o cliente esgota o tempo.

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

Esa orde é todo o mecanismo, e as interfaces dos aparellos escóndena detrás de caixas de verificación sen cambiala. O propietario do destino segue decidindo que ruta toma un paquete.

Se o host da LAN é o punto final previsto, a redirección é correcta e o router non debería escoitar tamén nese porto.

Conserva unha asignación e elimina a outra

Enumera as entradas NAT para ese porto e familia e escolle o supervivente:

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

Unha entrada TCP co mesmo número é irrelevante para un fallo de UDP, e tratalas como un só obxecto leva a borrar a regra equivocada. Cando o socket local debe gañar, o propietario da asignación conflitante elimina ou reescribe esa única entrada, e o permiso de entrada para o porto propio do router queda no seu sitio. As redireccións non relacionadas, a ruta de xestión e unha copia do conxunto de regras deberían sobrevivir ao cambio.

Se o VPN vive nun host separado, a redirección é o obxecto correcto. Un servizo nun contedor ou máquina virtual pode necesitar un porto publicado mesmo cando a caixa se chama router, así que segue o socket e o seu espazo de nomes, non a etiqueta da caixa.

Confirma o propietario desde fóra

Proba cada familia por separado, porque unha conexión IPv6 que remata no router non di nada dunha conexión IPv4 que unha regra obsoleta redirixe. Le o rexistro do servizo receptor para ver que punto final respondeu, e trata a mensaxe de éxito do cliente como unha proba feble. Cómpre un fluxo novo para unha proba significativa. Envía unha sonda desde un host externo con nc -zvu 203.0.113.7 1194 e le o rexistro do gañador con journalctl -u openvpn@server -n 20. O oínte do router rexistra a conexión el mesmo, mentres que un host da LAN a rexistra no seu propio servizo.

O seguimento de conexións mantén os fluxos existentes na súa asignación orixinal, así que unha sesión establecida pode sobrevivir á regra que acabas de corrixir.

Cando o punto final previsto responda coas súas comprobacións de identidade habituais, proba un recurso privado detrás do túnel. Chegar ao oínte exterior é só o primeiro salto; o encamiñamento interno e a autorización da aplicación son resultados separados.