L2TP/IPsec ei ühenda: eraldage IPsec, tunnelite autentimine või PPP-sisselogimine

Ühe L2TP/IPsec-ühenduse sees autenditakse kolm asja ja neist ainult üks puudutab inimest, kes sisse helistab. IPsec tõestab tunneli otspunkte, L2TP juhtühendus võib partnerid uuesti omaenda saladusega tõestada, ja seejärel tõestab PPP seansi sees olevat kasutajakontot. Tõrge mis tahes etapil näeb kliendi dialoogis välja nagu üldine sisselogimistõrge ja serveri logis hoopis teistsugune. Käige etapid järjekorras läbi ja peatuge esimesel, mis ebaõnnestub, sest iga etapp allpool testimata etappi on samuti testimata.

Kolm autentimisetappi, kolm erinevat identiteeti

IPsec tõestab, kellele otspunktid kuuluvad, kasutades eelnevalt jagatud võtit või sertifikaati. See identiteet kuulub masinatele või lüüsidele, mitte kunagi klaviatuuri taga istuvale inimesele. Kui partnerid ei suuda sellel etapil kokku leppida, ei vahetata ühtegi L2TP-paketti.

L2TP juhtühendus võib lisada teise, eraldi väljakutse-vastuse vahetuse, mida juhib jagatud saladus, mis peab olema mõlemal otsal.

RFC 2661 muudab selle juhtühenduse autentimise valikuliseks, mis selgitab, miks sama viga annab kahes serveris erinevaid sümptomeid. Juurutus, mis ei ole kunagi tunneli saladust seadistanud, jätab etapi täielikult vahele; see, mis seadistas selle ainult ühel pool, ebaõnnestub enne, kui PPP üldse pakutakse. Seejärel autendib PPP kasutaja PAP, CHAP või MSCHAPv2 abil ja annab nime kontohoidlale, mis võib olla kohalik, failis chap-secrets või RADIUSes. Vale parool selles punktis jätab teid ikkagi töötava tunneliga ja ebaõnnestunud seansiga.

Lugege peatuspunkt enne konfiguratsiooni muutmist

Alustage käsuga ipsec --version, et teada, kas olekuväljund kuulub strongSwanile või Libreswanile. Seejärel lugege serveri logi, mitte kliendi dialoogi, sest server märgib üles, milline etapp keeldus.

Tavaliselt otsustab pileti üks rida: kaebus IKE või pakkumiste kohta on esimene etapp, juhtühenduse teade on teine ja PPP meetodi või konto tagasilükkamine on kolmas. Kopeerige see rida ajatempliga piletisse. Kliendi poolelt oletamine raiskab ainsa tõendi, mis teil juba on.

Hoidke võtmematerjal ja paroolid sellest kleepimisest väljas; etapi nimi suunab tööd ja lekkinud eelnevalt jagatud võti avab pileti uuesti halvemate tagajärgedega.

Esimene samm: kas IPsecil on assotsiatsioon?

Käivitage ipsec statusall strongSwanis või ipsec whack --status Libreswanis ja otsige loodud alamassotsiatsiooni, mille loendurid ei ole nullid. ip xfrm state näitab tuuma vaadet mõlemas. Paigaldatud SA-paar kasvavate loenduritega tähendab, et esimene etapp on tehtud ja võite edasi liikuda.

Assotsiatsiooni täielik puudumine osutab partneri aadressile, pakkumiste komplektile või eelnevalt jagatud võtmele ja mõnikord seadmele, mis kirjutab UDP 500 ümber, visates samal ajal UDP 4500 kõrvale. Assotsiatsioon, mis luuakse ja kaob seejärel mõne sekundi pärast, on tavaliselt kahe otsa eluea lahknevus, mitte mandaadiprobleem. Kontrollige, kas mõlemad pooled loetlevad samu krüpteerimis- ja räsi-pakkumisi, enne kui midagi ümber trükite. Kui ei, ei hakka ükski võti kunagi tööle.

Peatuge, kuni assotsiatsioon puudub. PPP valikute muutmine selles punktis ei muuda midagi ja peidab tegeliku rikke järgmise inimese eest.

Teine samm: kas L2TP juhtühendus autentis end?

Kui IPsec töötab, jälgige L2TP deemonit, kas juhtühendus jõuab loodud olekusse, sest PPP ei saa enne alata. Keeldumine juhtühendusel tähendab, et tunneli saladus erineb otste vahel, või et üks ots nõuab saladust, mida teine kunagi ei saada. Kliendid pakuvad sageli ühte välja nimega jagatud saladus, ja see kuulub tavaliselt IPsecile, mitte L2TP-le. Selle täitmine ei seadista tunneli saladust ja selle tühjendamine ei lülita seda välja.

Kui kummalgi poolel ei ole tunneli saladust seadistatud, jätke see etapp vahele ja käsitlege juhtühenduse tõrget hoopis kättesaadavuse probleemina. Kinnitage, et UDP 1701 jõuab deemonini ja et mõlemad otsad lepivad kokku sama kapseldusega. Tulemüürireegel, mis on kirjutatud ühele neist kahest tingimusest, on tavaline poolenisti avaneva ühenduse põhjus.

Ainult seanss, mis alustab PPP läbirääkimisi, on tunneli etapi tegelikult läbinud.

Kolmas samm: kas PPP lükkab konto tagasi?

PPP tõrge näeb väljast teistsugune: tunnel on loodud, seanss algab ja deemon logib autentimismeetodi tõrke või konto tagasilükkamise. Lugege seda meetodit, mida selles teates nimetatakse. PAP ja CHAP ebaõnnestuvad erinevatel põhjustel ja server, mis lükkab ühe tagasi, lükkab tagasi kliendi, kes pakub ainult seda.

Linuxi serveris vaadake läbi valikute fail, mille deemon PPP-le annab, tavaliselt /etc/ppp/options.xl2tpd, ja kinnitage, millised meetodid on lubatud ja kus kontosid lahendatakse. Nimi, mis on RADIUSes olemas, kuid kohalikus saladuste failis mitte, ebaõnnestub puhtalt ja näeb välja nagu vale parool. Seejärel kontrollige, kas klient pakub meetodit, mille server vastu võtab, mitte tugevamat, mille üle server keeldub läbi rääkimast. Eelnevalt jagatud võtme vahetamine selle etapi parandamiseks kaotab ühe pärastlõuna ega muuda midagi.

Kui seanss lõpuks tõuseb, on aadresside määramine, DNS ja marsruudid endiselt kontrollimata, ja igaüks neist ebaõnnestub vaikselt omal moel. Hoidke kolm kihti märkmetes lahus: õige võti vale kontoga ebaõnnestub alati ja ühe kihi parandamine ei paranda kunagi teist.