Chegar a un dispositivo da casa mediante unha VPN de acceso remoto: cinco portas

Unha VPN comercial de saída a internet oculta o seu enderezo; non o conecta coa súa propia casa. Chegar ao NAS ou á impresora dunha rede doméstica precisa unha pasarela situada nesa rede e un cliente que constrúa un túnel cara a ela. Despois o paquete debe pasar cinco comprobacións, e calquera delas que falle vese igual desde fóra.

Porta 1: o cliente debe seleccionar o túnel

Comprobe que o prefixo de destino realmente se encamiña cara ao túnel no cliente. Un perfil de túnel dividido que só empuxa a subrede propia da VPN enviará 192.168.x.x directamente pola interface local, onde non vai a ningures. Mire a táboa de encamiñamento do cliente, non o nome do perfil.

É o fallo máis habitual con clientes de teléfono, que a miúdo por defecto só envía DNS ou só un prefixo. Se falta a ruta, o handshake pode ser perfecto e o dispositivo seguir sendo inalcanzable.

Confirme que o enderezo do pool do cliente e a subrede da casa non se solapan antes de continuar.

Porta 2: a pasarela debe reenviar

A VPN termina nun host que debe reenviar o paquete descifrado á LAN. Iso require o reenvío IP activado e unha política de cortafuegos que permita o fluxo da interface VPN á interface LAN. Nun aparello encamiñador adoita vir integrado; nunha máquina Linux con strongSwan ou WireGuard son dous axustes que a xente esquece. Comprobe ambos antes de probar o servizo, porque calquera dos dous por si só produce o mesmo tempo de espera.

Probe cunha captura na interface LAN, porque un paquete que nunca aparece alí descartouse ou nunca se reenviou.

É un fallo distinto do dun servizo que rexeita a conexión, e a distinción aforra moito tempo. Manteña o permiso estreito, limitado ao servizo e ao pool da VPN en lugar de toda a subrede.

Porta 3: a ruta de resposta decide todo

O destino responde ao enderezo de orixe que viu, que é ou ben o enderezo do pool do cliente ou ben a pasarela, segundo se traduce. Se a pasarela predeterminada do destino é o encamiñador da casa e ese encamiñador non ten ruta cara ao pool da VPN, a resposta sae por internet e morre. É a clásica conexión unidireccional.

Existen dúas solucións lexítimas: engadir unha ruta para o pool na pasarela LAN, ou facer source-NAT na pasarela VPN para que o destino só vexa nunca o enderezo da pasarela. A segunda é máis fácil e perde a identidade orixinal da orixe.

Escolla unha deliberadamente e anote cal, porque as regras do cortafuegos e os rexistros dependen diso. A guía de reenvío de strongSwan percorre o lado Linux desa decisión.

Porta 4: nomes e solapamento de prefixos

Os nomes de descuberta locais non cruzan unha fronteira encamiñada, así que un dispositivo que dentro da casa aparece cun nome amigable pode ser invisible polo túnel. Proporcione DNS para a zona privada ou documente o enderezo. Calquera nome que use debe resolverse a algo que o cliente remoto poida encamiñar. Por iso un dispositivo pode ser accesible por enderezo e invisible por nome ao mesmo tempo.

Os prefixos solapados son a outra trampa: se o pool do cliente é 192.168.1.0/24 e a rede da casa tamén, o cliente trata o destino como local e nunca o envía polo túnel.

Renombere un lado, ou use un pool dun rango que nunca atopará na casa.

Porta 5: probe desde fóra da casa

Unha proba desde a cociña non demostra nada, porque o tráfico pode non saír nunca da LAN. Conéctese desde un punto de acceso móbil ou outra rede e despois percorra as portas en orde: ruta no cliente, captura na interface LAN, resposta do servizo, captura da resposta e resolución de nomes. A primeira porta que non produza probas é onde está o traballo.

Se o servizo responde pero o nome non, ten un problema de DNS e non un problema de túnel.

Garde a configuración que funciona nunha nota co pool, a ruta e a elección de NAT, porque o próximo cambio de encamiñador restablecerá as tres cousas.