NAT de horquilla: por que o extremo VPN falla desde dentro

Un servidor VPN que responde desde unha rede móbil e falla desde o sofá normalmente non é un problema de certificado. O cliente dentro da LAN pide ao router que traduza un paquete cuxo destino é o propio enderezo público do router, o que significa que o paquete debe saír e volver entrar de inmediato. Esa manobra é o hairpinning, e moitos routers ou non a implementan ou só o fan cando se activa unha caixa. Que a proba desde fóra pase é o que confunde, porque demostra que o listener e a regra de reenvío están ben.

O paquete sae e volve entrar

Siga o paquete. O cliente resolve o nome público, conéctase ao enderezo público e o NAT de destino do router reescribe o destino cara ao servidor interno. A resposta do servidor diríxese ao enderezo LAN do cliente, así que volve pola interface LAN do router sen atravesar nunca a regra NAT que tería destraduído a orixe.

Agora o cliente recibe un paquete dun enderezo ao que nunca enviou nada e descártao. Esa asimetría é toda a avaría.

A RFC 4787 describe o comportamento que se espera dun NAT neste caso, e a versión curta é que na práctica é opcional mesmo onde está especificado en teoría. Algúns routers chaman ao axuste NAT loopback, outros chámano hairpin NAT ou NAT reflection, e algúns non expoñen nada. Un router que carece diso non está mal configurado; fai o normal, e a solución corresponde a outro sitio. Non conclúa dunha proba local fallida que a regra de reenvío pública é incorrecta.

Comprobación 1: probe os dous camiños por separado

Desde fóra da LAN, conéctese co mesmo perfil que usaría un usuario real e confirme que a sesión se establece. Desde dentro, conéctese ao enderezo público co mesmo perfil e anote o erro exacto e a hora.

Unha proba local precisa conserva o nome de host e só substitúe o enderezo: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ envía a petición ao enderezo público presentando á vez o nome de servidor correcto. Iso separa un problema de resolución de nomes dun problema de tradución, que se confunden con facilidade cando o mesmo nome funciona desde unha cafetería. Anote se o cliente falla na conexión TCP ou máis tarde en TLS, porque o primeiro apunta á tradución e o segundo á identidade.

Comprobación 2: lea o que ve o servidor

A observación máis útil é a visión do servidor. Executa unha captura no host VPN filtrada polo enderezo LAN do cliente e polo enderezo LAN do router, e despois repite o intento local. Se non chega nada, o paquete non sobreviviu á tradución.

Se unha conexión chega desde o enderezo LAN do router en lugar do do cliente, está a ocorrer hairpinning e a orixe reescribiuse. Esa é unha configuración que funciona, non unha avaría.

Comprobación 3: arránxao sen tocar o camiño externo

Existen tres formas admitidas, en orde crecente de radio de impacto. A máis estreita é o DNS dividido: publique un rexistro interno para que o mesmo nome de servidor resolva no enderezo interno para os clientes da LAN, o que evita por completo o camiño público. A seguinte é habilitar a opción documentada de loopback ou reflection do router, se a ten, e aplicala só a este servizo. A máis ampla é unha regra source-NAT no router que reescribe o tráfico procedente da LAN cara ao servidor para que a resposta volva polo router; nun router Linux é unha regra MASQUERADE en POSTROUTING que coincide co enderezo e o porto do servidor. As tres deixan intacto o camiño externo, e esa é a propiedade que hai que preservar.

Non amplíe o reenvío de portos non relacionado para que o camiño local se pareza ao externo, nin mova o servizo a outro porto para eludir o problema. Ambos os cambios alteran a que pode chegar o mundo exterior para arranxar algo que só ve o mundo interior.

O DNS dividido ten unha trampa que merece mencionarse. Substituír un nome de host por unha IP arbitraria cambia o que valida o cliente, así que o rexistro interno debe seguir coincidindo co nome do certificado.

Comprobación 4: verifique ambos os camiños despois

Repita o intento externo desde fóra da LAN, repita o intento interno co mesmo perfil e confirme que o rexistro do servidor mostra dúas sesións exitosas distintas en lugar dun éxito e un silencio. Despois comprobe que outros clientes seguen chegando ao listener e que as rutas aos recursos privados non cambiaron.

Manteña o rexistro curto: que enderezo usou cada cliente, que viu o servidor e cal das tres solucións se aplicou. Os requisitos de hairpinning da RFC 4787 son a referencia do que se espera dun NAT aquí, e explican por que un router sen a función se comporta con normalidade. Un fallo local que o mundo exterior non pode reproducir é unha cuestión de tradución ata que se demostre o contrario, así que proba como tal.