Katera faza VPN je spodletela: IPsec, nadzor L2TP ali preverjanje pristnosti PPP

Spremenili ste geslo in nič se ni premaknilo, ker napaka nikoli ni bila v PPP. L2TP/IPsec poroča o eni napaki povezave za pet zelo različnih predaj, in vsaka predaja ima svoje popravilo. Delajte vzvratno: poiščite zadnjo uspešno fazo in spreminjajte le tisto, kar pride za njo. Vrstni red spodaj odloča tudi, katere dokaze zberete prve.

Odgovorite na štiri vprašanja po vrsti

Vsilite nov poskus, ker nekateri odjemalci še naprej prikazujejo prejšnjo napako, dokler se profil ne prekine in znova poveže. Nato odgovorite: ali je obstajala varnostna asociacija IPsec, ali sta se pojavila krmilna povezava L2TP in klic, ali je PPP prišel do razsodbe o preverjanju pristnosti in ali je IPCP odjemalcu dal naslov? Prvi ne je faza, ki jo popravljate. Vse za njo je nepreizkušeno, zato zavrnjeno uporabniško ime ničesar ne dokaže, kadar asociacije nikoli ni bilo.

Pred primerjavo sinhronizirajte ure na obeh koncih. Poskus, ki je počistil IPsec in spodletel na PPP, je videti kot ena sama napaka, ko odjemalec prikazuje le zadnje sporočilo in dnevnik strežnika še vedno hrani prejšnji poskus. Berite po časovnem žigu, ne po najglasnejši vrstici.

Ko imate le posnetek zaslona uporabnika, se zanesite na najcenejšo delitev: napačen vnaprej deljen ključ in xl2tpd, ki nikoli ne odgovori, ustvarita isto besedilo v pogovornem oknu Windows, vendar eno zahteva skrivnost, spremenjeno na obeh koncih, drugo pa zagnanega demona ali pravilo požarnega zidu na samem strežniku. Naprava na sredini ne more zavreči notranjega 1701, ko ga je IPsec v transportnem načinu že ovil, zato ne iščite filtra poti, ki ga ni.

Kaj vsaka plast dejansko ima

IPsec ščiti pakete med dvema partnerjema; L2TP prenaša sejo PPP znotraj te zaščitene poti, zato RFC 3193 predpisuje transportni način namesto lastnega tunela. Oznaka odjemalca pravi L2TP, zato se tunel in prijava zdita en mehanizem. Nista: krmilna povezava L2TP preverja pristnost koncev tunela tam, kjer to uvedba omogoči, PPP pa ločeno preverja pristnost uporabnika s CHAP, PAP ali MS-CHAPv2 po politiki strežnika.

Ta delitev pojasnjuje dve skrivnosti, ki jih ljudje nenehno mešajo. Vnaprej deljen ključ preverja pristnost partnerjev IPsec. Uporabniško ime in geslo identificirata uporabnika pred PPP. Ponovno vnašanje deljene skrivnosti Windows v profilu, ki preverja pristnost s potrdili, ne spremeni ničesar v fazi, ki spodleti, in urejanje gesla PPP ne more zagotoviti manjkajočega zaščitenega kanala. Ista zadržanost velja za preverjanje identitete: ne izklopite identitete partnerja ali preverjanja potrdila, da bi dobili tunel, ker se takrat poveže pot, ne partner.

Tudi preverjanje pristnosti ni konec PPP. Ko je uporabnik sprejet, IPCP pogaja o naslovu odjemalca in možnostih DNS in WINS, ki jih je strežnik pripravljen izdati. Odjemalec lahko opravi CHAP ali MS-CHAPv2 in vseeno ostane brez naslova, kar je napaka znotraj PPP in ne težava usmerjanja. Navaden L2TP brez IPsec ostane veljaven in nezaščiten, zato uspešna povezava nikoli ne dokaže, da je promet zaščiten; preverite, kaj zahteva strežnik, ne oznake odjemalca.

Odločite se po prvi manjkajoči fazi

Berite tabelo po prvem manjkajočem elementu, od leve proti desni. Desni stolpec je edino delo, ki je v tistem trenutku vredno; vse levo od njega je že dokazano, ponovno preizkušanje pa sežge okno izpada, ne da bi dodalo informacijo.

Tri vrstice si zaslužijo opozorilo. Vrstica 1701 je kraj, kjer običajno pristanejo odjemalci Windows za NAT: asociacija se dokonča, nato nič ne prispe, in vzrok je enkapsulacija, ne slabo geslo. Vrstica IPCP je tista, ki se napačno bere kot težava poti, ker Windows manjkajoči naslov zavije v napako 720 in ikona v pladnju samo pove, da povezava ni uspela; ta napaka je po preverjanju pristnosti in pred usmerjanjem. Zadnja vrstica sploh ni napaka IPsec, čeprav ikona pravi prekinjeno.

Ukazi, ki ločijo plasti

Na strežniku Linux s strongSwan swanctl --list-sas našteje vzpostavljene asociacije z identiteto partnerja, ipsec statusall pa pokriva starejše gostitelje strongSwan in libreswan. Pod tem ip xfrm state prikaže dejanske asociacije jedra, medtem ko ss -lunp | grep 1701 dokaže, kam je xl2tpd vezan. Zaženite xl2tpd -D v ospredju, da vidite krmilne povezave in klice, in vklopite razhroščevanje pppd v /etc/ppp/options.xl2tpd, da vidite ponujeno metodo in odgovor.

Ko dnevniki pokažejo uspešno preverjanje pristnosti, je naslednje vprašanje, ali se je IPCP dokončal. Preverite, ali ima ip range v razdelku [lns default] datoteke /etc/xl2tpd/xl2tpd.conf še proste naslove in ali /etc/ppp/options.xl2tpd res nosi ms-dns in ms-wins, če jih odjemalec pričakuje. Izčrpan nabor in manjkajoča možnost DNS sta na žici videti drugače: prvi pusti odjemalca brez naslova in s 720, drugi da naslov, a nobenega razreševalnika, zato imena spodletijo, medtem ko ping na surove naslove deluje. Nobenega ne popravi ponovno vnašanje gesla.

Na odjemalcu vtičnik L2TP v NetworkManagerju zapiše pogovor pppd v dnevnik, zato journalctl -u NetworkManager -b običajno loči tunel gor, preverjanje pristnosti zavrnjeno od nobenega tunela. V Windows Get-VpnConnection poroča dejanske nastavitve preverjanja pristnosti profila, dogodki RasClient v razdelku Application v pregledovalniku dogodkov pa poimenujejo komponento, ki spodleti. Ko je pogovorno okno preveč nejasno, omogočite netsh ras set tracing * enable.

Posnetki zahtevajo eno previdnost. Pri IPsec v transportnem načinu je notranji UDP 1701 šifriran, zato posnetek na zunanjem vmesniku pokaže ESP ali UDP 4500 pod NAT-T in sploh nobenega L2TP. Manjkajoči 1701 v posnetku je pričakovan in ni dokaz zapornega vrat, opazujte, ali se števci ESP ali 4500 premikajo.

NAT, MTU in poti: kjer vas sklad zavaja

NAT zlomi predpostavke, preden je karkoli preverjeno. ESP je lasten protokol IP, zato ga naprava, ki prevaja, zavrže, razen če partnerja enkapsulirata; prav to zagotavlja UDP 4500. Na strežniku Windows, ki sam stoji za domačim usmerjevalnikom ali oblačnim prehodom NAT, faza IPsec spodleti z napako 789, dokler se AssumeUDPEncapsulationContextOnSendRule ne nastavi na 2 pod ključem PolicyAgent in se stroj ne znova zažene, napaka pa ostane nerazločljiva od zaprtega vrat. Odjemalci za NAT so lažji: z javnim naslovom na strežniku jih nosi NAT-T na UDP 4500 in ta vrednost ni vpletena.

Ko je PPP gor, MTU s črno luknjo posnema mrtev tunel: majhni paketi gredo skozi, rokovanje TLS ali nalaganje strani se ustavi, odjemalec pa lahko še vedno kaže povezano. Znižajte MTU vmesnika ali stisnite MSS na prehodu, preden obtožite strežnik. Usmerjanje razdeljenega tunela je drugi slepar; podomrežje, poslano z napačno masko, pusti tunel zdrav in eno aplikacijo nedosegljivo. Zasebno ime gostitelja doda svoj korak: če poizvedba odide skozi krajevni razreševalnik, se ime ne razreši, preden se preizkusi katera koli pot.

Kontrolni seznam, preden se dotaknete poverilnic

Pojdite skozi seznam po vrsti in se ustavite pri prvem elementu, ki spodleti. Vsak korak je poceni in vsak izloči cel razred sprememb.

1. Potrdite, da asociacija obstaja na obeh koncih, usklajena po identiteti partnerja in ne po oznaki povezano.
2. Potrdite, da UDP 1701 doseže xl2tpd; asociacija brez klica je vaša napaka.
3. Preberite razsodbo PPP in, če je preveril pristnost, izid IPCP, preden domnevate, da je geslo napačno.
4. Šele zdaj znova vnesite poverilnice v obliki, ki jo pričakuje strežnik, ker predpona domene spremeni račun.
5. Če še vedno spodleti, posnemite oba konca z poravnanimi časovnimi žigi in primerjajte fazo za fazo.

Ustavitev pri drugem koraku pomeni težavo poti ali enkapsulacije in nobena sprememba gesla je ne premakne. Ustavitev pri tretjem koraku pomeni, da dnevnik že imenuje metodo ali nabor naslovov za popravilo. V vsakem primeru je naslednja sprememba taka, ki jo lahko utemeljite, in prenehate krožiti skozi nastavitve, ki nikoli niso bile vpletene.