L2TP/IPsec falla: aïlleu IPsec, l'autenticació del túnel o l'inici de sessió PPP

Dins d'una connexió L2TP/IPsec s'autentiquen tres coses, i només una afecta la persona que truca. IPsec demostra els extrems del túnel, la connexió de control L2TP pot tornar a demostrar els parells amb el seu propi secret, i després PPP demostra el compte d'usuari dins la sessió. Un fracàs en qualsevol etapa sembla un error genèric d'inici de sessió al diàleg del client i sembla completament diferent al registre del servidor. Recorreu les etapes en ordre i atureu-vos a la primera que falli, perquè tota etapa per sota d'una de no provada també és no provada.

Tres etapes d'autenticació, tres identitats diferents

IPsec demostra de qui són els extrems, amb una clau prèviament compartida o un certificat. Aquesta identitat pertany a màquines o passarel·les, mai a la persona davant del teclat. Quan els parells no es poden posar d'acord en aquesta etapa, no s'intercanvia cap paquet L2TP.

La connexió de control L2TP pot afegir un segon intercanvi de repte i resposta, separat, impulsat per un secret compartit que tots dos extrems han de tenir.

El RFC 2661 fa opcional aquesta autenticació de la connexió de control, cosa que explica per què el mateix error produeix símptomes diferents en dos servidors. Un desplegament que mai ha configurat un secret de túnel s'alta l'etapa del tot; un que l'ha configurat només en un costat falla abans que PPP s'ofereixi. Després PPP autentica l'usuari amb PAP, CHAP o MSCHAPv2 i lliura el nom a un magatzem de comptes que pot ser local, a chap-secrets o a RADIUS. Una contrasenya incorrecta en aquest punt encara us deixa amb un túnel que funciona i una sessió fallida.

Llegiu el punt d'aturada abans d'editar una configuració

Comenceu amb ipsec --version per saber si la sortida d'estat pertany a strongSwan o a Libreswan. Després llegiu el registre del servidor, no el diàleg del client, perquè el servidor enregistra quina etapa s'ha negat.

Una línia sol resoldre el tiquet: una queixa d'IKE o de les propostes és la primera etapa, un missatge de la connexió de control és la segona, i un rebuig del mètode PPP o del compte és la tercera. Copieu aquesta línia al tiquet amb la marca de temps. Endevinar des del costat del client malbarata l'única prova que ja teniu.

Mantingueu el material de clau i les contrasenyes fora d'aquest enganxall; el nom de l'etapa encamina la feina, i una clau prèviament compartida filtrada reobre el tiquet amb conseqüències pitjors.

Primer pas: té IPsec una associació?

Executeu ipsec statusall a strongSwan o ipsec whack --status a Libreswan i busqueu una associació filla establerta amb comptadors diferents de zero. ip xfrm state mostra la vista del nucli en tots dos. Una parella d'SA instal·lada amb comptadors que pugen vol dir que la primera etapa està feta i que podeu continuar.

Que no hi hagi cap associació apunta a l'adreça del parell, al conjunt de propostes o a la clau prèviament compartida, i de vegades a un dispositiu que reescriu UDP 500 mentre descarta UDP 4500. Una associació que s'estableix i després desapareix al cap de pocs segons sol ser un desajust de durada entre els dos extrems i no un problema de credencials. Comproveu si tots dos costats llisten les mateixes propostes de xifratge i de hash abans de reescriure res. Si no ho fan, cap clau funcionarà mai.

Atureu-vos mentre falta l'associació. Editar les opcions de PPP en aquest moment no canvia res i amaga l'avaria real a la persona següent.

Segon pas: s'ha autenticat la connexió de control L2TP?

Un cop IPsec està aixecat, vigileu el dimoni L2TP per veure si una connexió de control arriba a un estat establert, ja que PPP no pot començar abans. Un rebuig a la connexió de control vol dir que el secret del túnel difereix entre els extrems, o que un extrem exigeix un secret que l'altre no envia mai. Els clients sovint exposen un sol camp etiquetat com a secret compartit, i normalment pertany a IPsec i no a L2TP. Omplir-lo no configura el secret del túnel, i esborrar-lo no el desactiva.

Si cap dels dos costats té un secret de túnel configurat, salteu aquesta etapa i tracteu el fracàs de la connexió de control com un problema d'abast. Confirmeu que UDP 1701 arriba al dimoni i que tots dos extrems coincideixen en la mateixa encapsulació. Una regla de tallafoc escrita per a una d'aquestes dues condicions és una causa habitual d'una connexió que s'obre a mitges.

Només una sessió que comença a negociar PPP ha superat realment l'etapa del túnel.

Tercer pas: rebutja PPP el compte?

Un fracàs de PPP es veu diferent des de fora: el túnel està establert, la sessió comença i el dimoni registra un fracàs del mètode d'autenticació o un rebuig del compte. Llegiu el mètode que s'anomena en aquest missatge. PAP i CHAP fallen per motius diferents, i un servidor que en rebutja un rebutjarà un client que només n'ofereixi aquell.

En un servidor Linux, reviseu el fitxer d'opcions que el dimoni passa a PPP, normalment /etc/ppp/options.xl2tpd, i confirmeu quins mètodes s'accepten i on es resolen els comptes. Un nom que existeix a RADIUS però no al fitxer de secrets local falla netament i sembla una contrasenya dolenta. Després comproveu que el client ofereixi un mètode que el servidor accepti, i no un de més fort que el servidor es negui a negociar. Canviar la clau prèviament compartida per reparar aquesta etapa fa perdre una tarda i no canvia res.

Quan la sessió finalment s'aixeca, l'assignació d'adreces, el DNS i les rutes encara no estan comprovats, i cadascun falla en silenci a la seva manera. Mantingueu les tres capes separades a les notes: una clau correcta amb un compte equivocat sempre falla, i reparar una capa mai no repara una altra.