L2TP/IPsec nedarbojas: izolējiet IPsec, tuneļa autentifikāciju vai PPP pieteikšanos

Vienā L2TP/IPsec savienojumā autentificējas trīs lietas, un tikai viena no tām attiecas uz cilvēku, kas zvana. IPsec pierāda tuneļa galapunktus, L2TP vadības savienojums var vēlreiz pierādīt partnerus ar savu noslēpumu, un pēc tam PPP pierāda lietotāja kontu sesijas ietvaros. Neveiksme jebkurā posmā klienta dialogā izskatās kā vispārīga pieteikšanās kļūda, bet servera žurnālā izskatās pilnīgi citādi. Izejiet posmus pēc kārtas un apstājieties pie pirmā, kas neizdodas, jo katrs posms zem nepārbaudīta posma arī ir nepārbaudīts.

Trīs autentifikācijas posmi, trīs dažādas identitātes

IPsec pierāda, kam pieder galapunkti, izmantojot iepriekš koplietotu atslēgu vai sertifikātu. Šī identitāte pieder mašīnām vai vārtejām, nekad cilvēkam pie klaviatūras. Ja partneri šajā posmā nespēj vienoties, netiek apmainīts neviens L2TP pakete.

L2TP vadības savienojums var pievienot otru, atsevišķu izaicinājuma-atbildes apmaiņu, ko vada kopīgs noslēpums, kam jābūt abiem galiem.

RFC 2661 padara šo vadības savienojuma autentifikāciju neobligātu, kas izskaidro, kāpēc viena un tā pati kļūda divos serveros rada dažādus simptomus. Izvietojums, kas nekad nav konfigurējis tuneļa noslēpumu, posmu pilnībā izlaiž; tas, kas to konfigurējis tikai vienā pusē, neizdodas pirms PPP vispār tiek piedāvāts. Pēc tam PPP autentificē lietotāju ar PAP, CHAP vai MSCHAPv2 un nodod vārdu kontu krātuvei, kas var būt lokāla, failā chap-secrets vai RADIUS. Nepareiza parole šajā brīdī joprojām atstāj strādājošu tuneli un neizdevušos sesiju.

Pirms konfigurācijas rediģēšanas izlasiet apstāšanās vietu

Sāciet ar ipsec --version, lai zinātu, vai statusa izvade pieder strongSwan vai Libreswan. Pēc tam lasiet servera žurnālu, nevis klienta dialogu, jo serveris reģistrē, kurš posms atteicās.

Viena rinda parasti atrisina biļeti: IKE vai priekšlikumu sūdzība ir pirmais posms, vadības savienojuma ziņojums ir otrais posms, bet PPP metodes vai konta noraidījums ir trešais posms. Nokopējiet šo rindu biļetē ar laika zīmogu. Minēšana no klienta puses izšķiež vienīgo pierādījumu, kas jums jau ir.

Turiet atslēgas materiālu un paroles ārpus šīs ielīmēšanas; posma nosaukums virza darbu, un noplūdusi iepriekš koplietota atslēga atkārtoti atver biļeti ar sliktākām sekām.

Pirmais posms: vai IPsec ir asociācija?

Palaidiet ipsec statusall uz strongSwan vai ipsec whack --status uz Libreswan un meklējiet izveidotu bērnasociāciju ar skaitītājiem, kas nav nulle. ip xfrm state parāda kodola skatījumu abos gadījumos. Instalēts SA pāris ar augošiem skaitītājiem nozīmē, ka pirmais posms ir pabeigts un varat doties tālāk.

Pilnīgs asociācijas trūkums norāda uz partnera adresi, priekšlikumu kopu vai iepriekš koplietotu atslēgu, un dažreiz uz ierīci, kas pārraksta UDP 500, bet izmet UDP 4500. Asociācija, kas izveidojas un pēc dažām sekundēm pazūd, parasti ir dzīves ilguma nesaskaņa starp abiem galiem, nevis akreditācijas datu problēma. Pārbaudiet, vai abas puses uzskaita vienus un tos pašus šifrēšanas un jaucējfunkciju priekšlikumus, pirms kaut ko ievadāt no jauna. Ja nē, neviena atslēga nekad nedarbosies.

Apstājieties, kamēr asociācijas nav. PPP opciju rediģēšana šajā brīdī neko nemaina un slēpj īsto defektu no nākamā cilvēka.

Otrais posms: vai L2TP vadības savienojums autentificējās?

Kad IPsec darbojas, vērojiet L2TP dēmonu, vai vadības savienojums sasniedz izveidotu stāvokli, jo PPP nevar sākties pirms tam. Atteikums vadības savienojumā nozīmē, ka tuneļa noslēpums atšķiras starp galiem, vai viens gals pieprasa noslēpumu, ko otrs nekad nesūta. Klienti bieži rāda vienu lauku ar apzīmējumu shared secret, un tas parasti pieder IPsec, nevis L2TP. Tā aizpildīšana nekonfigurē tuneļa noslēpumu, un tā notīrīšana to neizslēdz.

Ja neviena puse nav konfigurējusi tuneļa noslēpumu, izlaidiet šo posmu un vadības savienojuma neveiksmi uzskatiet par sasniedzamības problēmu. Pārliecinieties, ka UDP 1701 sasniedz dēmonu un abi gali vienojas par vienu un to pašu iekapsulējumu. Ugunsmūra noteikums, kas rakstīts vienam no šiem diviem nosacījumiem, ir izplatīts iemesls savienojumam, kas atveras tikai pa pusei.

Tikai sesija, kas sāk pārrunāt PPP, patiešām ir izgājusi tuneļa posmu.

Trešais posms: vai PPP noraida kontu?

PPP neveiksme no ārpuses izskatās citādi: tunelis ir izveidots, sesija sākas, un dēmons reģistrē autentifikācijas metodes neveiksmi vai konta noraidījumu. Izlasiet šajā ziņojumā nosaukto metodi. PAP un CHAP neizdodas dažādu iemeslu dēļ, un serveris, kas noraida vienu, noraidīs klientu, kas piedāvā tikai to.

Linux serverī pārbaudiet opciju failu, ko dēmons nodod PPP, parasti /etc/ppp/options.xl2tpd, un apstipriniet, kuras metodes tiek pieņemtas un kur konti tiek atrisināti. Vārds, kas eksistē RADIUS, bet ne lokālajā noslēpumu failā, neizdodas tīri un izskatās kā nepareiza parole. Pēc tam pārbaudiet, vai klients piedāvā servera pieņemtu metodi, nevis stiprāku, par kuru serveris atsakās pārrunāt. Iepriekš koplietotās atslēgas maiņa šī posma labošanai izšķiež pēcpusdienu un neko nemaina.

Kad sesija beidzot paceļas, adrešu piešķiršana, DNS un maršruti vēl nav pārbaudīti, un katra klusi neizdodas savā veidā. Turiet trīs slāņus atsevišķi savās piezīmēs: pareiza atslēga ar nepareizu kontu vienmēr neizdodas, un viena slāņa labošana nekad nelabo otru.