Quina etapa de la VPN ha fallat: IPsec, el control L2TP o l’autenticació PPP

Heu canviat la contrasenya i no s’ha mogut res, perquè la fallada mai no era a PPP. L2TP/IPsec informa d’un sol error de connexió per a cinc lliuraments ben diferents, i cada lliurament té la seva pròpia reparació. Treballeu al revés: trobeu l’última etapa que ha reeixit i canvieu només el que ve després. L’ordre de sota també decideix quines proves recolliu primer.

Responeu quatre preguntes per ordre

Força un intent nou, perquè alguns clients continuen mostrant l’error anterior fins que el perfil no es desconnecta i es torna a connectar. Després responeu això: hi havia una associació de seguretat IPsec, van aparèixer una connexió de control L2TP i una trucada, PPP va arribar a un veredicte d’autenticació i IPCP va donar una adreça al client? El primer no és l’etapa que arregleu. Tot el que ve després no s’ha provat, així que un nom d’usuari rebutjat no demostra res quan mai no hi va haver associació.

Sincronitzeu els rellotges dels dos extrems abans de comparar. Un reintent que va netejar IPsec i va fallar a PPP sembla una sola fallada quan el client només mostra el missatge final i el registre del servidor encara guarda l’intent anterior. Llegiu per marca de temps, no per la línia més sorollosa.

Quan només teniu la captura de pantalla de l’usuari, recolzeu-vos en la separació més barata: una clau prèviament compartida incorrecta i un xl2tpd que no respon mai produeixen el mateix text al diàleg de Windows, però un necessita un secret canviat als dos extrems i l’altre necessita un dimoni engegat o una regla de tallafoc al mateix servidor. Un dispositiu al mig no pot descartar el 1701 interior un cop IPsec en mode transport l’ha embolcallat, així que no busqueu un filtre de camí que no hi és.

Què posseeix realment cada capa

IPsec protegeix els paquets entre els dos iguals; L2TP transporta una sessió PPP dins d’aquest camí protegit, i per això RFC 3193 especifica el mode transport en lloc d’un túnel propi. L’etiqueta del client diu L2TP, així que el túnel i l’inici de sessió semblen un sol mecanisme. No ho són: la connexió de control L2TP autentica els extrems del túnel on un desplegament ho habilita, i PPP autentica per separat l’usuari amb CHAP, PAP o MS-CHAPv2 segons la política del servidor.

Aquesta separació explica els dos secrets que la gent confon. Una clau prèviament compartida autentica els iguals IPsec. Un nom d’usuari i una contrasenya identifiquen l’usuari davant PPP. Reescriure el secret compartit de Windows en un perfil que s’autentica amb certificats no canvia res a l’etapa que falla, i editar la contrasenya PPP no pot proporcionar un canal protegit que falta. La mateixa contenció s’aplica a la comprovació d’identitat: no desactiveu la identitat de l’igual ni la validació del certificat per obtenir un túnel, perquè llavors el que es connecta és el camí, no l’igual.

L’autenticació tampoc no és el final de PPP. Un cop acceptat l’usuari, IPCP negocia l’adreça del client i les opcions DNS i WINS que el servidor està disposat a lliurar. Un client pot passar CHAP o MS-CHAPv2 i quedar-se sense adreça, cosa que és una fallada dins de PPP i no un problema d’encaminament. L2TP simple sense IPsec continua sent vàlid i desprotegit, així que una connexió correcta no demostra mai que el trànsit estigui protegit; comproveu què exigeix el servidor, no l’etiqueta del client.

Decidiu per la primera etapa que falta

Llegiu la taula pel primer element que falta, d’esquerra a dreta. La columna de la dreta és l’única feina que val la pena en aquell moment; tot el que té a l’esquerra ja està provat, i tornar-ho a provar crema la finestra d’interrupció sense afegir informació.

Tres files mereixen un avís. La fila 1701 és on solen arribar els clients Windows darrere de NAT: l’associació es completa, després no arriba res, i la causa és l’encapsulament, no una contrasenya dolenta. La fila IPCP és la que es llegeix malament com a problema de ruta, perquè Windows embolcalla l’adreça que falta en l’error 720 i la icona de la safata només diu que la connexió ha fallat; aquesta fallada se situa després de l’autenticació i abans de l’encaminament. L’última fila no és cap fallada d’IPsec, tot i que la icona de la safata digui desconnectat.

Ordres que separen les capes

En un servidor Linux amb strongSwan, swanctl --list-sas llista les associacions establertes amb la identitat de l’igual, i ipsec statusall cobreix els amfitrions strongSwan i libreswan més antics. A sota, ip xfrm state mostra les associacions reals del nucli, mentre que ss -lunp | grep 1701 demostra on està lligat xl2tpd. Executeu xl2tpd -D en primer pla per veure aparèixer les connexions de control i les trucades, i activeu la depuració de pppd a /etc/ppp/options.xl2tpd per veure el mètode ofert i la resposta.

Quan els registres mostren una autenticació correcta, la pregunta següent és si IPCP s’ha completat. Comproveu que ip range a la secció [lns default] de /etc/xl2tpd/xl2tpd.conf encara tingui adreces lliures, i que /etc/ppp/options.xl2tpd porti realment ms-dns i ms-wins si el client els espera. Un conjunt esgotat i una opció DNS que falta es veuen diferents al cable: el primer deixa el client sense adreça i amb un 720, el segon dóna adreça però cap resolutor, així que els noms fallen mentre els ping a adreces crues funcionen. Cap dels dos no es repara tornant a introduir la contrasenya.

Al client, el connector L2TP de NetworkManager escriu la conversa de pppd al registre, així que journalctl -u NetworkManager -b normalment separa túnel aixecat, autenticació rebutjada de cap túnel. A Windows, Get-VpnConnection informa de la configuració real d’autenticació del perfil, i els esdeveniments RasClient a Application del Visor d’esdeveniments anomenen el component que falla. Quan el diàleg és massa vague, activeu netsh ras set tracing * enable.

Les captures requereixen una precaució. Amb IPsec en mode transport, l’UDP 1701 interior va xifrat, així que una captura a la interfície exterior mostra ESP, o UDP 4500 sota NAT-T, i cap L2TP. Que falti 1701 en una captura és esperable i no és prova d’un port bloquejat; mireu si es mouen els comptadors d’ESP o de 4500.

NAT, MTU i rutes: on la pila us enginya

NAT trenca les suposicions abans que res no estigui autenticat. ESP és el seu propi protocol IP, així que un dispositiu que tradueix el descarta tret que els iguals encapsulin; això és el que proporciona l’UDP 4500. En un servidor Windows que ell mateix és darrere d’un encaminador domèstic o d’una passarel·la NAT al núvol, l’etapa IPsec falla amb l’error 789 fins que AssumeUDPEncapsulationContextOnSendRule no es posa a 2 sota la clau PolicyAgent i la màquina no es reinicia, i la fallada continua sent indistingible d’un port tancat. Els clients darrere de NAT són més fàcils: amb una adreça pública al servidor, NAT-T sobre UDP 4500 els transporta i aquell valor no hi intervé.

Un cop PPP està aixecat, un MTU amb forat negre imita un túnel mort: els paquets petits passen, una negociació TLS o una càrrega de pàgina es pengen, i el client pot encara mostrar connectat. Baixeu l’MTU de la interfície o fixeu l’MSS a la passarel·la abans de culpar el servidor. L’encaminament de túnel dividit és l’altre impostor; una subxarxa enviada amb la màscara equivocada deixa el túnel sa i una aplicació inabastable. Un nom d’amfitrió privat afegeix el seu propi salt: si la consulta surt pel resolutor local, el nom no es resol abans que es provi cap ruta.

Llista de comprovació abans de tocar credencials

Feu la llista per ordre i atureu-vos al primer element que falli. Cada pas és barat, i cadascun descarta tota una classe d’edicions.

1. Confirmeu que l’associació existeix als dos extrems, aparellada per la identitat de l’igual i no per una etiqueta de connectat.
2. Confirmeu que l’UDP 1701 arriba a xl2tpd; una associació sense trucada és la vostra fallada.
3. Llegiu el veredicte de PPP i, si ha autenticat, el resultat d’IPCP, abans de suposar que la contrasenya és incorrecta.
4. Només ara torneu a introduir les credencials en el format que espera el servidor, perquè un prefix de domini canvia el compte.
5. Si encara falla, captureu els dos extrems amb marques de temps alineades i compareu etapa per etapa.

Aturar-se al segon pas significa un problema de camí o d’encapsulament, i cap edició de la contrasenya no el mourà. Aturar-se al tercer pas significa que el registre ja anomena el mètode o el conjunt d’adreces que cal arreglar. En tots dos casos el canvi següent és un que podeu justificar, i deixeu de donar voltes per paràmetres que mai no hi van intervenir.