L2TP/IPsec ne deluje: ločite IPsec, preverjanje pristnosti predora ali prijavo PPP

V eni povezavi L2TP/IPsec se preverijo tri stvari in le ena od njih zadeva osebo, ki kliče. IPsec dokaže končne točke predora, krmilna povezava L2TP lahko znova dokaže partnerje z lastno skrivnostjo, nato pa PPP dokaže uporabniški račun znotraj seje. Napaka na kateri koli stopnji je v pogovornem oknu odjemalca videti kot splošna napaka prijave, v dnevniku strežnika pa povsem drugače. Pojdite skozi stopnje po vrsti in se ustavite pri prvi, ki odpove, ker je vsaka stopnja pod nepreverjeno tudi nepreverjena.

Tri stopnje preverjanja pristnosti, tri različne identitete

IPsec dokaže, komu pripadajo končne točke, z vnaprej dogovorjenim ključem ali potrdilom. Ta identiteta pripada strojem ali prehodom, nikoli človeku za tipkovnico. Ko se partnerji na tej stopnji ne morejo dogovoriti, se ne izmenja noben paket L2TP.

Krmilna povezava L2TP lahko doda drugo, ločeno izmenjavo izziv-odgovor, ki jo vodi skupna skrivnost, ki jo morata imeti oba konca.

RFC 2661 naredi to preverjanje pristnosti krmilne povezave neobvezno, kar pojasnjuje, zakaj ista napaka na dveh strežnikih povzroči različne simptome. Namestitev, ki nikoli ni nastavila skrivnosti predora, stopnjo povsem preskoči; tista, ki jo je nastavila le na eni strani, odpove, preden se PPP sploh ponudi. Nato PPP preveri uporabnika s PAP, CHAP ali MSCHAPv2 in ime preda shrambi računov, ki je lahko lokalna, v chap-secrets ali na RADIUS. Napačno geslo na tej točki vas vseeno pusti z delujočim predorom in neuspešno sejo.

Preberite točko zaustavitve, preden spremenite konfiguracijo

Začnite z ipsec --version, da veste, ali izpis stanja pripada strongSwan ali Libreswan. Nato berite dnevnik strežnika, ne pogovornega okna odjemalca, ker strežnik zabeleži, katera stopnja je zavrnila.

Ena vrstica običajno reši zahtevek: pritožba zaradi IKE ali predlogov je prva stopnja, sporočilo o krmilni povezavi je druga stopnja, zavrnitev metode PPP ali računa pa tretja stopnja. To vrstico kopirajte v zahtevek s časovnim žigom. Ugibanje na strani odjemalca zapravi edini dokaz, ki ga že imate.

Ključni material in gesla imejte zunaj tega prilepljenega besedila; ime stopnje usmerja delo, ujeta vnaprej dogovorjena skrivnost pa znova odpre zahtevek s slabšimi posledicami.

Prva stopnja: ima IPsec povezavo?

Zaženite ipsec statusall na strongSwan ali ipsec whack --status na Libreswan in poiščite vzpostavljeno podrejeno povezavo s števci, ki niso nič. ip xfrm state prikaže pogled jedra pri obeh. Nameščen par SA z naraščajočimi števci pomeni, da je prva stopnja opravljena in lahko nadaljujete.

Popolna odsotnost povezave kaže na naslov partnerja, nabor predlogov ali vnaprej dogovorjeni ključ, včasih pa na napravo, ki prepiše UDP 500, a zavrže UDP 4500. Povezava, ki se vzpostavi in nato po nekaj sekundah izgine, je običajno neskladje življenjske dobe med obema koncema in ne težava s poverilnicami. Preverite, ali obe strani navajata enake predloge šifriranja in zgoščevanja, preden kar koli znova vtipkate. Če ne, noben ključ ne bo nikoli deloval.

Ustavite se, dokler povezave ni. Urejanje možnosti PPP na tej točki ničesar ne spremeni in skrije pravo napako pred naslednjo osebo.

Druga stopnja: se je krmilna povezava L2TP preverila?

Ko IPsec deluje, spremljajte demo L2TP, ali krmilna povezava doseže vzpostavljeno stanje, saj PPP pred tem ne more začeti. Zavrnitev na krmilni povezavi pomeni, da se skrivnost predora med koncema razlikuje, ali da en konec zahteva skrivnost, ki je drugi nikoli ne pošlje. Odjemalci pogosto prikažejo eno polje z oznako shared secret, ki običajno pripada IPsec in ne L2TP. Izpolnitev tega ne nastavi skrivnosti predora, brisanje pa je ne onemogoči.

Če nobena stran ni nastavila skrivnosti predora, to stopnjo preskočite in napako krmilne povezave obravnavajte kot težavo dosegljivosti. Potrdite, da UDP 1701 doseže demo in da se oba konca strinjata o istem zapiranju. Pravilo požarnega zidu, napisano za enega od teh dveh pogojev, je pogost vzrok za povezavo, ki se odpre na pol.

Le seja, ki začne pogajati PPP, je resnično prestala stopnjo predora.

Tretja stopnja: PPP zavrača račun?

Napaka PPP je od zunaj videti drugače: predor je vzpostavljen, seja se začne, demon pa zabeleži napako metode preverjanja pristnosti ali zavrnitev računa. Preberite metodo, navedeno v tem sporočilu. PAP in CHAP odpovedujeta iz različnih razlogov in strežnik, ki eno zavrne, bo zavrnil odjemalca, ki ponuja samo to.

Na strežniku Linux preglejte datoteko možnosti, ki jo demon preda PPP, običajno /etc/ppp/options.xl2tpd, in potrdite, katere metode so sprejete in kje se računi razrešujejo. Ime, ki obstaja v RADIUS, a ne v lokalni datoteki skrivnosti, odpove čisto in je videti kot napačno geslo. Nato preverite, ali odjemalec ponuja metodo, ki jo strežnik sprejme, in ne močnejše, katere pogajanje strežnik zavrača. Spreminjanje vnaprej dogovorjenega ključa za popravilo te stopnje zapravi popoldne in ničesar ne spremeni.

Ko seja končno vstane, dodeljevanje naslovov, DNS in poti še niso preverjeni, in vsaka tiho odpove na svoj način. Tri plasti imejte ločene v svojih zapiskih: pravilen ključ z napačnim računom vedno odpove in popravilo ene plasti nikoli ne popravi druge.