L2TP/IPsec connecta en una xarxa i falla en una altra

El mateix portàtil, el mateix perfil i la mateixa contrasenya funcionen en un edifici i fallen en un altre. Aquesta comparació és la prova més útil del tiquet, i normalment és la primera cosa que es descarta. Entre dues xarxes d’accés, l’intercanvi passa per una traducció d’adreces diferent, filtres diferents i auxiliars de router diferents. Mantenir el client fix i canviar només la xarxa és la manera d’esbrinar quin d’aquests elements importa.

Fixeu el client abans de comparar xarxes

No canvieu res al dispositiu fins que tingueu un registre del cas que funciona: versió del client, contingut del perfil, nom del servidor i hora de la connexió correcta. Després reproduïu la fallada a la segona xarxa durant la mateixa sessió, perquè l’estat del client sigui tan idèntic com sigui possible. Un perfil editat entre els dos intents invalida tota la comparació. L’objectiu és una sola variable, i aquesta variable és la xarxa.

Confirmeu primer l’accés normal a internet a la xarxa que falla, inclòs un portal de convidats si n’hi ha. Un portal que mai no es va completar produeix un temps d’espera que sembla exactament un túnel filtrat, i aquesta comprovació costa un minut.

Quatre etapes, quatre missatges d’error diferents

Una connexió L2TP/IPsec travessa quatre etapes, i RFC 3193 descriu la disposició que uneix les dues primeres. La negociació IKE és on un camí filtrat produeix un temps d’espera silenciós. L’autenticació IPsec és on una discordança de certificat o de clau prèviament compartida produeix, en canvi, un rebuig explícit. La configuració del túnel L2TP és on una associació de seguretat ja establerta pot no dur enlloc, i l’inici de sessió PPP és on una credencial errònia produeix finalment una fallada visible. Llegiu el registre de l’etapa que es va aturar, no de l’última línia que va imprimir.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

El registre de strongSwan mostra si l’intercanvi IKE va arribar a una proposta i si el parell va respondre almenys, cosa que separa l’accessibilitat de la política. El registre de xl2tpd continua on acaba IPsec, així que una associació de seguretat establerta sense res en aquest registre apunta a l’etapa L2TP. La consulta de ruta confirma que el client envia cap a l’adreça de servidor que us penseu, cosa que detecta una resposta DNS obsoleta heretada de la xarxa anterior. Juntes, les tres sortides anomenen una etapa en lloc d’un símptoma.

Compareu la profunditat de NAT i el comportament de l’auxiliar

La travessa de NAT trasllada el trànsit protegit a l’encapsulament UDP quan es detecta traducció, de manera que els números de port que porten una sessió funcional poden diferir dels d’un diagrama estàtic. Permetre un sol paquet de configuració no demostra res sobre la resta de l’intercanvi, i una anàlisi externa de ports no us pot dir com tracta el parell el trànsit autenticat vàlid. Una segona capa de traducció torna a canviar el panorama, perquè el mapatge ara existeix dues vegades i caduca segons dos calendaris diferents. La traducció de nivell d’operador en una connexió mòbil és la raó habitual perquè un perfil d’oficina que funciona falli en un punt d’accés del telèfon.

Els auxiliars del router varien tant com les xarxes. Alguns firmwares intercepten i reescriuen l’intercanvi, d’altres simplement deixen de descartar-lo, i d’altres apliquen l’ajust només en un mode antic. Llegiu la descripció que el mateix firmware fa de la casella, i quan existeixi un mode de compatibilitat, proveu-lo com un canvi deliberat en lloc de tres alhora.

Client de sortida, servidor d’entrada: dos problemes diferents

Un client de sortida i un servidor d’entrada necessiten una accessibilitat amunt diferent, i una funció de pas que ajuda el primer no fa res pel segon. Un router domèstic que deixa el portàtil arribar a una passarel·la remota no accepta per això connexions d’entrada cap a un servidor al darrere. Confondre els dos us envia a buscar un redireccionament de ports que mai no va ser el problema. Digueu quin paper fa el dispositiu que falla abans de comparar res.

Després d’un canvi admès, repetiu la mateixa connexió i anoteu l’etapa a què va arribar. Guardeu junts el perfil funcional i la nota sobre la xarxa que falla, i no restabliu les credencials ni reinstal·leu el client, perquè això descarta la prova sobre la qual es va construir la comparació.