Wi-Fi públic i VPN: què no cobreix el túnel

Insígnia verda, portal satisfet, navegador que funciona: aquesta és tota la història visible. El que la insígnia omet és que la connexió xifrada la transporta precisament l'enllaç sense fils del qual hauria de protegir-te. Aquest enllaç encara lliura cada paquet, encara veu l'adreça de destinació i encara decideix si hi arribarà res. Recórrer el costat de l'ordinador portàtil d'una connexió d'hotel mostra quines parts cobreix el túnel i quines et deixa a tu.

L'enllaç d'accés ho transporta tot

Un túnel IPsec ESP embolcalla un paquet interior protegit dins d'una capçalera exterior que la xarxa pot encaminar, i RFC 4303 secció 3.1.2 exposa aquesta divisió. El paquet interior és el que protegeix el túnel. La capçalera exterior és el que llegeix el punt d'accés per reenviar-lo. Altres dissenys encapsulen de manera diferent, però la pregunta de planificació és idèntica: quin camí d'accés transporta aquesta connexió?

Una fallada de la passarel·la o un enllaç que descarta paquets atura el lliurament sense revelar el contingut. Passar a un xifratge més fort no hi fa res, perquè la peça que falta és el transport, no la criptografia. Un lliurament correcte demostra igual de poc en l'altra direcció, ja que un camí que funciona no diu res sobre l'estat de cap de les dues màquines.

El teu portàtil encara té les seves pròpies portes

Unir-se a un segment no fiable canvia qui pot arribar als ports on escolta la teva màquina. Un servei de compartició de fitxers, un agent d'administració remota o un servidor de desenvolupament lligat a totes les interfícies és abastable per qualsevol d'aquell segment tret que alguna cosa ho aturi. El trànsit que no entra mai al túnel no hi queda protegit. Un oient que respon abans que el túnel estigui aixecat queda exposat exactament durant aquella finestra.

El requisit és estret i val la pena formular-lo amb precisió: el portàtil ha d'arribar al punt final de la VPN, i els dispositius no relacionats del punt d'accés no han d'arribar als serveis locals. Les regles del tallafoc de l'amfitrió expressen aquesta frontera, i la configuració de compartició de la plataforma també n'expressa una part. Una impressora o un pas de portal és una excepció acotada que afegeixes deliberadament, no una prova que tot el punt d'accés mereixi la confiança d'una LAN d'oficina.

Algunes organitzacions també restringeixen l'accés local mentre hi ha una connexió de treball activa, cosa que és política i no enginyeria. Llegeix aquesta política abans de desactivar un tallafoc per fer funcionar un perifèric.

Comprova què escolta realment

Mira els sòcols i no la pàgina de configuració, perquè la pàgina descriu la intenció i la taula de sòcols descriu la màquina. Les dues llistes de sota separen cada sòcol que escolta dels que un veí podria abastar. Executa-les al segment no fiable abans de connectar el túnel.

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

La primera ordre mostra cada sòcol, i la segona filtra els que estan lligats més enllà del loopback. Un servei a 0.0.0.0 o :: és disponible a totes les interfícies, inclosa la sense fils, mentre que el mateix servei a 127.0.0.1 no és abastable des del segment de cap manera. La consulta al resolutor confirma quin camí pren el nom abans que existeixi el túnel, i és aquí on interfereixen els portals captius. Repeteix la llista després de connectar, perquè alguns clients aixequen interfícies que canvien la resposta.

Un port que només apareix mentre el túnel està aixecat està menys exposat, tot i que encara val la pena conèixer-lo. Anota la diferència i no la llista absoluta, ja que el delta és el que el túnel ha afegit.

No acceptis una identitat nova a mig de la sessió

Un canvi de ruta inesperat, una reconnexió o una redirecció del portal no és permís per acceptar una identitat de servidor diferent. Si el client informa d'una discrepància de certificat o de clau, tracta-ho com una troballa d'identitat i no com una connectivitat a esquivar. Instal·lar un certificat arrel sense explicació per fer funcionar un portal converteix un problema de lliurament en un problema de confiança. I el problema de confiança sobreviu després al viatge que el va crear.

Utilitza el flux de navegador propi del portal, després reconnecta el túnel i llegeix el registre del client per saber quina identitat ha verificat. Una fallada d'identitat vol dir que l'igual no és qui esperaves, mentre que una fallada de lliurament vol dir que l'igual no va respondre mai. La primera és una raó per aturar-se, i la segona és una raó per provar un altre camí.

Decideix primer el comportament davant d'una caiguda

Aquí es confonen dues funcions diferents. La reconnexió intenta restablir el servei, mentre que una política de bloqueig controla quin trànsit es permet mentre el túnel està caigut. Cap de les dues subministra un enllaç sense fils que funcioni, ni cap demostra que el punt final estigui net. Tria explícitament: fallada tancada per a les aplicacions que no han d'usar mai el camí local, i permetre la navegació ordinària fora del túnel si això és acceptable.

Anota l'elecció, perquè el valor per defecte a la majoria de clients no és cap de les dues i varia segons la versió. Després prepara un camí d'accés alternatiu si la disponibilitat importa, com un punt d'accés mòbil amb el seu propi pla de dades. Una prova d'acceptació acceptable té tres resultats separats: el trànsit previst usa el túnel verificat, els oients locals no relacionats són inabastables, i una caiguda produeix el comportament que has triat.