L2TP/IPsec malsukcesas: izolu IPsec, tunelan aŭtentikigon aŭ PPP-anĉesion

Ene de unu L2TP/IPsec-konekto aŭtentikiĝas tri aferoj, kaj nur unu el ili koncernas la personon, kiu alvokas. IPsec pruvas la finpunktojn de la tunelo, la L2TP-kontrolkonekto povas denove pruvi la kunulojn per sia propra sekreto, kaj poste PPP pruvas la uzantokonton ene de la seanco. Malsukceso ĉe iu ajn etapo aspektas kiel ĝenerala ensaluta eraro en la klienta dialogo kaj aspektas tute alie en la servila protokolo. Trapasu la etapojn laŭorde kaj haltu ĉe la unua, kiu malsukcesas, ĉar ĉiu etapo sub neprovita estas ankaŭ neprovita.

Tri aŭtentikigaj etapoj, tri malsamaj identecoj

IPsec pruvas, al kiu apartenas la finpunktoj, per antaŭe dividita ŝlosilo aŭ atestilo. Tiu identeco apartenas al maŝinoj aŭ pordegoj, neniam al la homo antaŭ la klavaro. Kiam la kunuloj ne povas interkonsenti ĉe ĉi tiu etapo, tute neniu L2TP-paketo estas interŝanĝata.

La L2TP-kontrolkonekto povas aldoni duan, apartan interŝanĝon de defio kaj respondo, pelatan de komuna sekreto, kiun ambaŭ finoj devas posedi.

RFC 2661 faras tiun aŭtentikigon de la kontrolkonekto laŭvola, kio klarigas, kial la sama eraro produktas malsamajn simptomojn en du serviloj. Instalaĵo, kiu neniam agordis tunelan sekreton, tute preterlasas la etapon; tiu, kiu agordis ĝin nur unuflanke, malsukcesas antaŭ ol PPP entute proponiĝas. Poste PPP aŭtentikigas la uzanton per PAP, CHAP aŭ MSCHAPv2 kaj transdonas la nomon al kontenero, kiu povas esti loka, en chap-secrets aŭ en RADIUS. Malĝusta pasvorto ĉe tiu punkto ankoraŭ lasas al vi funkciantan tunelon kaj malsukcesan seancon.

Legu la haltpunkton antaŭ ol redakti agordon

Komencu per ipsec --version, por ke vi sciu, ĉu la statusa eligo apartenas al strongSwan aŭ al Libreswan. Poste legu la servilan protokolon, ne la klientan dialogon, ĉar la servilo registras, kiu etapo rifuzis.

Kutime unu linio decidas la bileton: plendo pri IKE aŭ pri la proponoj estas la unua etapo, mesaĝo de la kontrolkonekto estas la dua, kaj rifuzo de PPP-metodo aŭ de konto estas la tria. Kopiu tiun linion en la bileton kun la tempstampo. Diveni de la klienta flanko malŝparas la solan pruvon, kiun vi jam havas.

Tenadu ŝlosilmaterialon kaj pasvortojn ekster tiu enmeto; la nomo de la etapo direktas la laboron, kaj tralikita antaŭe dividita ŝlosilo remalfermas la bileton kun pli malbonaj sekvoj.

Unua paŝo: ĉu IPsec havas asocion?

Rulu ipsec statusall en strongSwan aŭ ipsec whack --status en Libreswan kaj serĉu establitan idan asocion kun ne-nulaj nombriloj. ip xfrm state montras la vidon de la kerno en ambaŭ. Instalita paro da SA kun kreskantaj nombriloj signifas, ke la unua etapo finiĝis kaj vi povas daŭrigi.

Tute mankanta asocio montras al la adreso de la kunulo, al la aro de proponoj aŭ al la antaŭe dividita ŝlosilo, kaj foje al aparato, kiu reskribas UDP 500 dum ĝi forĵetas UDP 4500. Asocio, kiu establiĝas kaj poste malaperas post kelkaj sekundoj, estas kutime malkongruo de vivdaŭro inter la du finoj, ne problemo pri akreditaĵoj. Kontrolu, ĉu ambaŭ flankoj listigas la samajn ĉifradajn kaj haketajn proponojn, antaŭ ol vi reskribu ion ajn. Se ne, neniu ŝlosilo iam funkcios.

Haltu, dum la asocio mankas. Redakti PPP-opciojn ĉe tiu punkto ŝanĝas nenion kaj kaŝas la realan difekton de la sekva persono.

Dua paŝo: ĉu la L2TP-kontrolkonekto aŭtentikiĝis?

Post kiam IPsec funkcias, observu la L2TP-demonon por kontrolkonekto, kiu atingas establitan staton, ĉar PPP ne povas komenciĝi antaŭe. Rifuzo ĉe la kontrolkonekto signifas, ke la tunela sekreto diferencas inter la finoj, aŭ ke unu fino postulas sekreton, kiun la alia neniam sendas. Klientoj ofte montras unu solan kampon nomitan komuna sekreto, kaj ĝi kutime apartenas al IPsec, ne al L2TP. Plenigi ĝin ne agordas la tunelan sekreton, kaj malplenigi ĝin ne malŝaltas ĝin.

Se neniu flanko havas agorditan tunelan sekreton, preterlasu ĉi tiun etapon kaj traktu malsukceson de la kontrolkonekto kiel atingeblon anstataŭe. Konfirmu, ke UDP 1701 atingas la demonon kaj ke ambaŭ finoj konsentas pri la sama enkapsuligo. Fajroŝirmila regulo skribita por unu el tiuj du kondiĉoj estas ofta kaŭzo de konekto, kiu malfermiĝas duone.

Nur seanco, kiu komencas intertrakti PPP, efektive trapasis la tunelan etapon.

Tria paŝo: ĉu PPP rifuzas la konton?

Malsukceso de PPP aspektas alie de ekstere: la tunelo estas establita, la seanco komenciĝas, kaj la demono protokolas malsukceson de aŭtentikiga metodo aŭ rifuzon de konto. Legu la metodon nomitan en tiu mesaĝo. PAP kaj CHAP malsukcesas pro malsamaj kaŭzoj, kaj servilo, kiu rifuzas unu, rifuzos klienton, kiu proponas nur ĝin.

Sur Linux-servilo, ekzamenu la opcian dosieron, kiun la demono transdonas al PPP, kutime /etc/ppp/options.xl2tpd, kaj konfirmu, kiuj metodoj estas akceptataj kaj kie kontoj estas solvitaj. Nomo, kiu ekzistas en RADIUS sed ne en la loka sekreta dosiero, malsukcesas pure kaj aspektas kiel malbona pasvorto. Poste kontrolu, ĉu la kliento proponas metodon, kiun la servilo akceptas, ne pli fortan, pri kiu la servilo rifuzas intertrakti. Ŝanĝi la antaŭe dividitan ŝlosilon por ripari ĉi tiun etapon malŝparas posttagmezon kaj ŝanĝas nenion.

Kiam la seanco fine leviĝos, adresdisdonado, DNS kaj itineroj ankoraŭ ne estas kontrolitaj, kaj ĉiu el ili malsukcesas silente laŭ sia propra maniero. Tenu la tri tavolojn aparte en viaj notoj: ĝusta ŝlosilo kun malĝusta konto ĉiam malsukcesas, kaj ripari unu tavolon neniam riparas alian.