VPN do móbil á casa: faga do cortafogos a súa saída a internet
Chegar á LAN da casa non é o mesmo que saír polo enlace ascendente da casa. Decida o reenvío, o resolutor, IPv6 e o estado desconectado no móbil.
Conectar un móbil ao túnel da casa e abrir un recurso compartido da LAN demostra que o túnel funciona. Non demostra que as peticións de internet do móbil saian pola casa. A diferenza entre ambos os resultados é unha política de reenvío máis unha ruta, non outra caixa de verificación no móbil. É tamén a diferenza que a maioría supón que xa configurou.
Tres decisións producen a ruta de saída: que envía o móbil ao túnel, onde o reenvía a pasarela da casa e que ocorre cando o túnel non está. Cada unha ten un modo de fallo que, desde a pantalla do móbil, parece o das demais.
Dous saltos, dúas políticas
A conexión exterior remata no receptor VPN da casa. O paquete interior é un obxecto aparte que debe reenviarse a algún sitio, e reenviar é unha decisión de cortafogos distinta de aceptar o túnel en primeiro lugar.
phone app -> encrypted tunnel -> home listener
-> decrypted packet -> forward policy -> home uplink -> destination
Nun router doméstico típico, estas viven en conxuntos de regras distintos. Aceptar o túnel é política de entrada na interface VPN; enviar o tráfico do móbil a internet é política de reenvío máis a tradución de orixe que necesite o enlace ascendente. Un router que acepta o túnel e non reenvía nada produce un móbil que se mostra conectado e non carga ningunha páxina.
Se o servizo VPN se executa nunha máquina separada dentro da casa, engada un salto. Agora o router ve tráfico que chega desa máquina, así que as súas regras se aplican ao enderezo do servidor e non ao enderezo do túnel do móbil, e a tradución de orixe pode facer que cada móbil pareza un só host.
O receptor non é o filtro
Decida onde ocorre a aplicación mentres a información que necesita aínda existe. No router, o enderezo do túnel do móbil é visible e pódese comparar directamente. Tras unha segunda tradución xa non está, e as regras escritas para o enderezo do móbil non coinciden con nada, en silencio.
Esta é a razón habitual de que unha política funcione para o portátil e non para o móbil. O portátil conecta directamente ao router, o móbil conecta a un servidor que reenvía a través do router, e só o primeiro camiño conserva o enderezo que a regra espera. A regra non é incorrecta; está comparando un valor que xa non existe nese punto.
Escriba a ruta co enderezo de orixe tal como aparece en cada punto de aplicación. Ese único diagrama resolve a maioría destes casos antes de editar calquera regra.
Que debe enviar realmente o móbil
Un móbil que só recibe unha ruta á subrede da casa só envía o tráfico desa subrede ao túnel. Todo o demais sae pola rede móbil, e por iso o recurso compartido funciona e as peticións de internet nunca chegan á casa.
A cobertura de túnel completo é unha decisión de enrutamento do lado do cliente, e debe establecerse co mecanismo que admite a plataforma, non supoñerse a partir do perfil que se instala. Unha vez establecida, a ruta de volta ao propio servidor VPN debe quedar fóra do túnel, ou o cliente non poderá manter o seu propio transporte.
O DNS merece unha decisión propia, porque é a parte máis propensa a divergir do resto do tráfico. Un enderezo de resolutor no perfil é unha suxestión que os clientes tratan de forma distinta, e unha aplicación co seu propio resolutor cifrado pode seguir un camiño completamente separado. Se a política da casa depende de que as consultas cheguen a un resolutor concreto, aplíquea onde o tráfico pasa realmente, ou acepte que algunhas consultas non o farán. Unha consulta que evita o seu resolutor nunca chega a unha regra escrita para ela.
IPv6 pertence ao mesmo parágrafo que o DNS, non a un apéndice. Un túnel completo IPv4 non di nada sobre o tráfico AAAA, e un móbil nunha rede móbil de dobre pila usará de bo grado a ruta nativa para iso. Escolla transporte ou bloqueo explicitamente.
Que pode ver o cortafogos e que non
A pasarela pode actuar sobre o que expón o seu punto de aplicación: enderezos, portos, protocolo, interface e os metadatos da conexión. Unha petición HTTPS reenviada non entrega o corpo da páxina nin o contrasinal só porque cruza o túnel da casa.
Vale a pena enunciar ese límite porque a frase «pása o polo cortafogos» implica máis inspección da que fai un router doméstico. Unha regra de destino, unha política de DNS e un proxy de capa de aplicación son tres controis distintos con tres custos de despregamento distintos.
Non supoña que unha función configurada para clientes da LAN da casa se aplica á interface VPN. A pertenza a unha zona é unha elección de configuración, e unha interface VPN que non está na zona correcta non herda ningunha das regras que probou desde o sofá.
Decida o estado desconectado
Cando o túnel non está dispoñible, o móbil ou volve á rede móbil ou négase a enviar o tráfico. Ambas son razoables, e só unha coincide co que a maioría cre que configurou.
A volta atrás é cómoda e filtra por definición: o momento en que cae o túnel é o momento en que as peticións saen pola ruta do operador. O bloqueo é máis forte e fai que o móbil dependa de que a casa sexa accesible, o que supón un custo real de dispoñibilidade para quen viaxa. Ningún dos dous comportamentos é un erro; ambos son produtos, e vostede escolle entre eles o diga ou non.
Probe a elección en lugar de supoñela. Deteña o servizo da casa e despois probe unha petición desde o navegador do móbil e outra desde unha aplicación que se execute en segundo plano. Volver conectarse máis tarde non desfai as peticións que xa saíron.
Remate con dúas comprobacións controladas desde o propio móbil: unha operación permitida que debe atravesar a casa e unha denegación que a política da casa debe aplicar. Confirme que a pasarela rexistrou o fluxo que esperaba, na familia de enderezos que esperaba, tras reconectarse. Un móbil que mostra Conectado é o comezo desa verificación, nunca o final.