L2TP/IPsec neveikia: atskirkite IPsec, tunelio autentifikavimą arba PPP prisijungimą

Vienoje L2TP/IPsec jungtyje autentifikuojasi trys dalykai, ir tik vienas jų susijęs su žmogumi, kuris skambina. IPsec įrodo tunelio galinius taškus, L2TP valdymo jungtis gali dar kartą įrodyti partnerius savo pačios paslaptimi, o tada PPP įrodo naudotojo paskyrą sesijos viduje. Bet kuriame etape įvykęs gedimas kliento dialoge atrodo kaip bendra prisijungimo klaida, o serverio žurnale – visiškai kitaip. Eikite per etapus iš eilės ir sustokite prie pirmojo, kuris nepavyksta, nes kiekvienas etapas žemiau neišbandyto etapo taip pat neišbandytas.

Trys autentifikavimo etapai, trys skirtingos tapatybės

IPsec įrodo, kam priklauso galiniai taškai, naudodamas iš anksto bendrinamą raktą arba sertifikatą. Ta tapatybė priklauso mašinoms arba tinklų sietuvams, niekada – žmogui prie klaviatūros. Kai partneriai šiame etape nesusitaria, L2TP paketai iš viso neapsikeičia.

L2TP valdymo jungtis gali pridėti antrą, atskirą iššūkio-atsakymo apsikeitimą, kurį valdo bendra paslaptis, kurią turi turėti abu galai.

RFC 2661 tą valdymo jungties autentifikavimą padaro neprivalomą, o tai paaiškina, kodėl ta pati klaida dviejuose serveriuose sukelia skirtingus simptomus. Diegimas, kuris niekada nesukonfigūravo tunelio paslapties, etapą visiškai praleidžia; tas, kuris ją sukonfigūravo tik vienoje pusėje, nepavyksta dar prieš pasiūlant PPP. Tada PPP autentifikuoja naudotoją naudodamas PAP, CHAP arba MSCHAPv2 ir perduoda vardą paskyrų saugyklai, kuri gali būti vietinė, faile chap-secrets arba RADIUS. Neteisingas slaptažodis tuo metu vis tiek palieka veikiantį tunelį ir nepavykusią sesiją.

Prieš keisdami konfigūraciją perskaitykite sustojimo vietą

Pradėkite nuo ipsec --version, kad žinotumėte, ar būsenos išvestis priklauso strongSwan, ar Libreswan. Tada skaitykite serverio žurnalą, o ne kliento dialogą, nes serveris užrašo, kuris etapas atsisakė.

Viena eilutė dažniausiai išsprendžia bilietą: IKE arba pasiūlymų skundas yra pirmas etapas, valdymo jungties pranešimas yra antras etapas, o PPP metodo ar paskyros atmetimas yra trečias etapas. Nukopijuokite tą eilutę į bilietą su laiko žyma. Spėliojimas iš kliento pusės iššvaisto vienintelį įrodymą, kurį jau turite.

Laikykite raktų medžiagą ir slaptažodžius toli nuo to įklijavimo; etapo pavadinimas nukreipia darbą, o nutekėjęs iš anksto bendrinamas raktas vėl atidaro bilietą su blogesnėmis pasekmėmis.

Pirmas etapas: ar IPsec turi asociaciją?

Paleiskite ipsec statusall sistemoje strongSwan arba ipsec whack --status sistemoje Libreswan ir ieškokite nustatytos podukros asociacijos su ne nuliniais skaitikliais. ip xfrm state rodo branduolio vaizdą abiem atvejais. Įdiegta SA pora su augančiais skaitikliais reiškia, kad pirmas etapas baigtas ir galite eiti toliau.

Visai nėra asociacijos – tai rodo į partnerio adresą, pasiūlymų rinkinį arba iš anksto bendrinamą raktą, o kartais į įrenginį, kuris perrašo UDP 500, bet numeta UDP 4500. Asociacija, kuri nusistovi ir po kelių sekundžių išnyksta, dažniausiai yra gyvavimo trukmės nesutapimas tarp abiejų galų, o ne prisijungimo duomenų problema. Patikrinkite, ar abi pusės išvardija tuos pačius šifravimo ir maišos pasiūlymus, prieš ką nors įvesdami iš naujo. Jei ne, joks raktas niekada neveiks.

Sustokite, kol asociacijos nėra. PPP parinkčių redagavimas tuo metu nieko nekeičia ir paslepia tikrą gedimą nuo kito žmogaus.

Antras etapas: ar L2TP valdymo jungtis autentifikavosi?

Kai IPsec veikia, stebėkite L2TP tarnybą, ar valdymo jungtis pasiekia nusistovėjusią būseną, nes PPP negali prasidėti anksčiau. Atsisakymas valdymo jungtyje reiškia, kad tunelio paslaptis skiriasi tarp galų, arba vienas galas reikalauja paslapties, kurios kitas niekada nesiunčia. Klientai dažnai rodo vieną lauką su žyme shared secret, ir jis paprastai priklauso IPsec, o ne L2TP. Jo užpildymas nesukonfigūruoja tunelio paslapties, o išvalymas jos neišjungia.

Jei nė viena pusė nesukonfigūravo tunelio paslapties, praleiskite šį etapą ir valdymo jungties gedimą laikykite pasiekiamumo problema. Patvirtinkite, kad UDP 1701 pasiekia tarnybą ir abu galai sutaria dėl tos pačios inkapsuliacijos. Ugniasienės taisyklė, parašyta vienai iš tų dviejų sąlygų, yra dažna pusiau atsidarančios jungties priežastis.

Tik sesija, kuri pradeda derėtis dėl PPP, iš tikrųjų įveikė tunelio etapą.

Trečias etapas: ar PPP atmeta paskyrą?

PPP gedimas iš išorės atrodo kitaip: tunelis nustatytas, sesija prasideda, o tarnyba registruoja autentifikavimo metodo gedimą arba paskyros atmetimą. Perskaitykite tame pranešime įvardytą metodą. PAP ir CHAP nepavyksta dėl skirtingų priežasčių, o serveris, kuris atmeta vieną, atmes klientą, siūlantį tik tą.

Linux serveryje patikrinkite parinkčių failą, kurį tarnyba perduoda PPP, paprastai /etc/ppp/options.xl2tpd, ir patvirtinkite, kurie metodai priimami ir kur sprendžiamos paskyros. Vardas, kuris yra RADIUS, bet ne vietiniame paslapčių faile, nepavyksta švariai ir atrodo kaip neteisingas slaptažodis. Tada patikrinkite, ar klientas siūlo serverio priimamą metodą, o ne stipresnį, kurio serveris atsisako derėtis. Iš anksto bendrinamo rakto keitimas šiam etapui taisyti iššvaisto popietę ir nieko nekeičia.

Kai sesija pagaliau pakyla, adresų priskyrimas, DNS ir maršrutai dar nepatikrinti, ir kiekvienas tyliai nepavyksta savaip. Laikykite tris sluoksnius atskirai savo užrašuose: teisingas raktas su neteisinga paskyra visada nepavyksta, o vieno sluoksnio taisymas niekada nepataiso kito.