Arribar a un dispositiu de casa amb una VPN d’accés remot: cinc portes

Una VPN comercial de sortida a internet amaga la vostra adreça; no us connecta amb la vostra pròpia casa. Arribar al NAS o a la impressora d’una xarxa domèstica necessita una passarel·la en aquesta xarxa i un client que hi construeixi un túnel. Després el paquet ha de passar cinc comprovacions, i qualsevol que falli es veu igual des de fora.

Porta 1: el client ha de seleccionar el túnel

Comproveu que el prefix de destinació realment s’encamini cap al túnel al client. Un perfil de túnel dividit que només empeny la subxarxa pròpia de la VPN enviarà 192.168.x.x directament per la interfície local, on no va enlloc. Mireu la taula d’encaminament del client, no el nom del perfil.

Aquesta és la fallada més habitual amb clients de telèfon, que sovint per defecte només envien DNS o només un prefix. Si falta la ruta, l’handshake pot ser perfecte i el dispositiu continuar sent inabastable.

Confirmeu que l’adreça del pool del client i la subxarxa de casa no se solapen abans de continuar.

Porta 2: la passarel·la ha de reenviar

La VPN acaba en un host que ha de reenviar el paquet desxifrat a la LAN. Cal tenir el reenviament IP activat i una política de tallafocs que permeti el flux de la interfície VPN a la interfície LAN. En un aparell encaminador això sol venir incorporat; en una màquina Linux amb strongSwan o WireGuard són dos paràmetres que la gent oblida. Comproveu tots dos abans de provar el servei, perquè qualsevol dels dos sol produeix el mateix temps d’espera.

Proveu amb una captura a la interfície LAN, perquè un paquet que no hi apareix mai s’ha descartat o no s’ha reenviat mai.

Aquesta és una fallada diferent de la d’un servei que rebutja la connexió, i la distinció estalvia molt de temps. Mantingueu el permís estret, limitat al servei i al pool de la VPN en lloc de tota la subxarxa.

Porta 3: el camí de retorn ho decideix tot

L’objectiu respon a l’adreça d’origen que ha vist, que és o bé l’adreça del pool del client o bé la passarel·la, segons si traduïu. Si la passarel·la per defecte de l’objectiu és l’encaminador de casa i aquest encaminador no té cap ruta cap al pool de la VPN, la resposta surt per internet i mor. Aquesta és la clàssica connexió unidireccional.

Hi ha dues solucions legítimes: afegir una ruta per al pool a la passarel·la LAN, o fer source-NAT a la passarel·la VPN perquè l’objectiu només vegi mai l’adreça de la passarel·la. La segona és més fàcil i perd la identitat original de l’origen.

Trieu-ne una deliberadament i anoteu quina, perquè les regles del tallafocs i els registres en depenen. La guia de reenviament de strongSwan recorre el costat Linux d’aquesta decisió.

Porta 4: noms i solapament de prefixos

Els noms de descobriment locals no travessen una frontera encaminada, així que un dispositiu que a casa apareix amb un nom amistós pot ser invisible pel túnel. Proporcioneu DNS per a la zona privada o documenteu l’adreça. El nom que useu ha de resoldre’s a alguna cosa que el client remot pugui encaminar. Per això un dispositiu pot ser abastable per adreça i invisible per nom alhora.

Els prefixos solapats són l’altra trampa: si el pool del client és 192.168.1.0/24 i la xarxa de casa també, el client tracta la destinació com a local i no l’envia mai pel túnel.

Renombreu un costat, o useu un pool d’un rang que no trobareu mai a casa.

Porta 5: proveu des de fora de casa

Una prova des de la cuina no demostra res, perquè el trànsit pot no sortir mai de la LAN. Connecteu-vos des d’un punt d’accés mòbil o una altra xarxa, i després passeu les portes per ordre: ruta al client, captura a la interfície LAN, resposta del servei, captura de la resposta i resolució de noms. La primera porta que no produeix cap prova és on hi ha la feina.

Si el servei respon però el nom no, teniu un problema de DNS i no un problema de túnel.

Guardeu la configuració que funciona en una nota amb el pool, la ruta i l’elecció de NAT, perquè la propera substitució de l’encaminador reiniciarà les tres coses.