VPN del mòbil a casa: feu del tallafoc la vostra sortida a internet

Connectar un mòbil al túnel de casa i obrir un recurs compartit de la LAN demostra que el túnel funciona. No demostra que les peticions d'internet del mòbil surtin per la casa. La diferència entre aquestes dues coses és una política de reenviament més una ruta, no una altra casella al mòbil. És també la diferència que la majoria de la gent suposa que ja ha configurat.

Tres decisions produeixen el camí de sortida: què envia el mòbil al túnel, on ho reenvia la passarel·la de casa i què passa quan el túnel no hi és. Cadascuna té una manera de fallar que, des de la pantalla del mòbil, sembla la de les altres.

Dos salts, dues polítiques

La connexió exterior acaba al receptor VPN de casa. El paquet interior és un objecte a part que s'ha de reenviar en algun lloc, i reenviar és una decisió de tallafoc diferent d'acceptar el túnel d'entrada.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

En un encaminador domèstic típic, aquestes viuen en conjunts de regles diferents. Acceptar el túnel és política d'entrada a la interfície VPN; enviar el trànsit del mòbil a internet és política de reenviament més la traducció d'origen que necessiti l'enllaç ascendent. Un encaminador que accepta el túnel i no reenvia res produeix un mòbil que es mostra connectat i no carrega cap pàgina.

Si el servei VPN s'executa en una màquina separada dins de casa, afegiu un salt. Ara l'encaminador veu el trànsit que arriba d'aquella màquina, així que les seves regles s'apliquen a l'adreça del servidor i no a l'adreça del túnel del mòbil, i la traducció d'origen pot fer que cada mòbil sembli un sol equip.

El receptor no és el filtre

Decidiu on es fa l'aplicació mentre la informació que necessiteu encara existeix. A l'encaminador, l'adreça del túnel del mòbil és visible i es pot fer coincidir directament. Darrere d'una segona traducció ja no hi és, i les regles escrites per a l'adreça del mòbil no coincideixen amb res, en silenci.

Aquesta és la raó habitual perquè una política funcioni amb el portàtil i no amb el mòbil. El portàtil es connecta directament a l'encaminador, el mòbil es connecta a un servidor que reenvia a través de l'encaminador, i només el primer camí conserva l'adreça que la regla espera. La regla no és incorrecta; coincideix amb un valor que en aquell punt ja no existeix.

Escriviu el camí amb l'adreça d'origen tal com apareix a cada punt d'aplicació. Aquest únic diagrama resol la majoria d'aquests casos abans que s'editi cap regla.

Què ha d'enviar realment el mòbil

Un mòbil que només rep una ruta cap a la subxarxa de casa només envia el trànsit d'aquesta subxarxa al túnel. La resta surt per la xarxa mòbil, i per això el recurs compartit funciona i les peticions d'internet no arriben mai a casa.

La cobertura de túnel complet és una decisió d'encaminament del costat client, i s'ha d'establir amb el mecanisme que admet la plataforma, no suposar-la a partir del perfil que s'instal·la. Un cop establerta, la ruta de tornada al mateix servidor VPN ha de quedar fora del túnel, o el client no podrà mantenir el seu propi transport.

El DNS mereix una decisió pròpia, perquè és la part més propensa a divergir de la resta del trànsit. Una adreça de resolutor al perfil és un suggeriment que els clients tracten de manera diferent, i una aplicació amb el seu propi resolutor xifrat pot seguir un camí completament separat. Si la política de casa depèn que les consultes arribin a un resolutor concret, apliqueu-la on el trànsit passa realment, o accepteu que algunes consultes no ho faran. Una consulta que evita el vostre resolutor no arriba mai a una regla escrita per a ella.

IPv6 pertany al mateix paràgraf que el DNS, no a un apèndix. Un túnel complet IPv4 no diu res sobre el trànsit AAAA, i un mòbil en una xarxa mòbil de doble pila farà servir de bon grat el camí natiu per a això. Trieu transport o bloqueig explícitament.

Què pot veure el tallafoc i què no

La passarel·la pot actuar sobre el que exposa el seu punt d'aplicació: adreces, ports, protocol, interfície i les metadades de la connexió. Una petició HTTPS reenviada no lliura el cos de la pàgina ni la contrasenya només perquè travessa el túnel de casa.

Val la pena enunciar aquest límit perquè la frase «feu-ho passar pel tallafoc» implica més inspecció de la que fa un encaminador domèstic. Una regla de destí, una política de DNS i un proxy de capa d'aplicació són tres controls diferents amb tres costos de desplegament diferents.

No suposeu que una funció configurada per als clients de la LAN de casa s'aplica a la interfície VPN. La pertinença a una zona és una elecció de configuració, i una interfície VPN que no és a la zona correcta no hereta cap de les regles que heu provat des del sofà.

Decidiu l'estat desconnectat

Quan el túnel no està disponible, el mòbil o torna a la xarxa mòbil o es nega a enviar el trànsit. Totes dues són raonables, i només una coincideix amb el que la majoria de la gent creu que ha configurat.

La tornada és còmoda i filtra per definició: el moment que el túnel cau és el moment en què les peticions surten pel camí de l'operador. El bloqueig és més fort i fa que el mòbil depengui que la casa sigui accessible, cosa que és un cost real de disponibilitat per a algú que viatja. Cap dels dos comportaments no és un error; tots dos són productes, i trieu entre ells tant si ho dieu com si no.

Proveu l'elecció en lloc de suposar-la. Atureu el servei de casa, i després proveu una petició des del navegador del mòbil i una altra des d'una aplicació que s'executi en segon pla. Tornar-se a connectar més tard no desfà les peticions que ja han sortit.

Acabeu amb dues comprovacions controlades des del mateix mòbil: una operació permesa que ha de travessar la casa, i una denegació que la política de casa ha d'aplicar. Confirmeu que la passarel·la ha registrat el flux que esperàveu, en la família d'adreces que esperàveu, després de tornar-vos a connectar. Un mòbil que mostra Connectat és el començament d'aquesta verificació, mai el final.