Wi-Fi público e VPN: o que o túnel non cobre

Insignia verde, portal satisfeito, navegador que funciona: esa é toda a historia visible. O que a insignia omite é que a conexión cifrada a transporta precisamente a ligazón sen fíos da que debería protexerte. Ese enlace segue entregando cada paquete, segue vendo o enderezo de destino e segue decidindo se chega algo. Percorrer o lado do portátil dunha conexión de hotel mostra que partes cobre o túnel e cales deixa para ti.

A ligazón de acceso transporta todo

Un túnel IPsec ESP envolve un paquete interior protexido dentro dunha cabeceira exterior que a rede pode encamiñar, e RFC 4303 sección 3.1.2 expón esa división. O paquete interior é o que protexe o túnel. A cabeceira exterior é o que le o punto de acceso para reenviarlo. Outros deseños encapsulan doutro xeito, pero a pregunta de planificación é idéntica: que camiño de acceso transporta esta conexión?

Un fallo da pasarela ou unha ligazón que descarta paquetes detén a entrega sen revelar o contido. Cambiar a un cifrado máis forte non axuda para iso, porque a peza que falta é o transporte, non a criptografía. Unha entrega correcta demostra igual de pouco na outra dirección, xa que un camiño que funciona non di nada sobre o estado de ningunha das dúas máquinas.

O teu portátil aínda ten as súas propias portas

Unirse a un segmento non fiable cambia quen pode alcanzar os portos nos que escoita a túa máquina. Un servizo de compartición de ficheiros, un axente de administración remota ou un servidor de desenvolvemento ligado a todas as interfaces é alcanzable por calquera dese segmento a non ser que algo o deteña. O tráfico que nunca entra no túnel non queda protexido por el. Un oínte que responde antes de que o túnel estea activo queda exposto exactamente durante esa xanela.

O requisito é estreito e merece enunciarse con precisión: o portátil debe alcanzar o extremo da VPN, e os dispositivos non relacionados do punto de acceso non deben alcanzar os servizos locais. As regras do devasa do equipo expresan esa fronteira, e a propia configuración de compartición da plataforma tamén expresa parte dela. Unha impresora ou un paso do portal é unha excepción acoutada que engades deliberadamente, non unha proba de que todo o punto de acceso mereza a confianza dunha LAN de oficina.

Algunhas organizacións tamén restrinxen o acceso local mentres hai unha conexión de traballo activa, o que é política e non enxeñaría. Le esa política antes de desactivar un devasa para facer funcionar un periférico.

Comproba que está escoitando de verdade

Mira os sockets e non a páxina de configuración, porque a páxina describe a intención e a táboa de sockets describe a máquina. As dúas listas de abaixo separan cada socket que escoita dos que un veciño podería alcanzar. Execútaas no segmento non fiable antes de conectar o túnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

O primeiro comando mostra cada socket, e o segundo filtra os que están ligados máis alá do loopback. Un servizo en 0.0.0.0 ou en :: está dispoñible en todas as interfaces, incluída a sen fíos, mentres que o mesmo servizo en 127.0.0.1 non é accesible desde o segmento en absoluto. A consulta ao resolutor confirma que camiño toma o nome antes de que exista o túnel, e aí é onde interfiren os portais cativos. Repite a lista despois de conectar, porque algúns clientes levantan interfaces que cambian a resposta.

Un porto que só aparece mentres o túnel está activo está menos exposto, aínda que segue merecendo coñecerse. Anota a diferenza e non a lista absoluta, xa que o delta é o que engadiu o túnel.

Non aceptes unha identidade nova a metade da sesión

Un cambio de ruta inesperado, unha reconexión ou unha redirección do portal non son permiso para aceptar unha identidade de servidor distinta. Se o cliente informa dunha discrepancia de certificado ou de clave, trátaa como un achado de identidade e non como unha conectividade que haxa que sortear. Instalar un certificado raíz sen explicación para que funcione un portal converte un problema de entrega nun problema de confianza. E o problema de confianza sobrevive despois á viaxe que o creou.

Usa o fluxo de navegador propio do portal, logo reconecta o túnel e le o rexistro do cliente para saber que identidade verificou. Un fallo de identidade significa que o par non é quen esperabas, mentres que un fallo de entrega significa que o par nunca respondeu. O primeiro é motivo para deterte, e o segundo é motivo para probar outro camiño.

Decide primeiro o comportamento ante unha caída

Aquí confúndense dúas funcións distintas. A reconexión tenta restablecer o servizo, mentres que unha política de bloqueo controla que tráfico se permite mentres o túnel está caído. Ningunha proporciona unha ligazón sen fíos que funcione, e ningunha demostra que o extremo estea limpo. Escolle explicitamente: fallo pechado para as aplicacións que nunca deben usar o camiño local, e permitir a navegación normal fóra do túnel se iso é aceptable.

Anota a elección, porque o valor predeterminado na maioría dos clientes non é ningún dos dous, e varía segundo a versión. Despois dispón un camiño de acceso alternativo se a dispoñibilidade importa, como un punto de acceso telefónico co seu propio plan de datos. Unha proba de aceptación aceptable ten tres resultados separados: o tráfico previsto usa o túnel verificado, os oíntes locais non relacionados son inaccesibles, e unha caída produce o comportamento que escolliches.