Koja faza VPN-a je pala: IPsec, L2TP kontrola ili PPP autentifikacija

Promijenili ste lozinku i ništa se nije pomjerilo, jer kvar nikada nije bio u PPP-u. L2TP/IPsec prijavljuje jednu grešku veze za pet sasvim različitih predaja, a svaka predaja ima svoje popravke. Radite unatrag: pronađite posljednju fazu koja je uspjela i mijenjajte samo ono što dolazi poslije nje. Redoslijed ispod također određuje koje dokaze prvo skupljate.

Odgovorite na četiri pitanja po redu

Prisilite svjež pokušaj, jer neki klijenti stalno prikazuju prethodnu grešku dok se profil ne isključi i ponovo uključi. Zatim odgovorite: je li postojala IPsec sigurnosna asocijacija, jesu li se pojavili L2TP kontrolna veza i poziv, je li PPP došao do odluke o autentifikaciji i je li IPCP dodijelio klijentu adresu? Prvo ne je faza koju popravljate. Sve poslije njega nije testirano, pa odbijeno korisničko ime ne dokazuje ništa kada asocijacija nikada nije postojala.

Uskladite satove na oba kraja prije poređenja. Pokušaj koji je očistio IPsec i pao na PPP-u izgleda kao jedan kvar kada klijent pokazuje samo konačnu poruku, a serverski dnevnik još čuva prethodni pokušaj. Čitajte po vremenskoj oznaci, ne po najglasnijem redu.

Kada imate samo korisnički snimak ekrana, oslonite se na najjeftiniju podjelu: pogrešan unaprijed dijeljeni ključ i xl2tpd koji nikada ne odgovara daju isti tekst u Windows dijalogu, ali jedno traži tajnu promijenjenu na oba kraja, a drugo pokrenut demon ili pravilo firewall-a na samom serveru. Uređaj u sredini ne može odbaciti unutrašnji 1701 nakon što ga je IPsec u transportnom režimu zamotao, zato ne tražite filter puta kojeg nema.

Šta svaki sloj zapravo posjeduje

IPsec štiti pakete između dva partnera; L2TP nosi PPP sesiju unutar tog zaštićenog puta, zato RFC 3193 propisuje transportni režim umjesto vlastitog tunela. Oznaka klijenta kaže L2TP, pa tunel i prijava izgledaju kao jedan mehanizam. Nisu: L2TP kontrolna veza autentifikuje krajnje točke tunela gdje to implementacija omogući, a PPP odvojeno autentifikuje korisnika pomoću CHAP, PAP ili MS-CHAPv2 prema politici servera.

Ta podjela objašnjava dvije tajne koje ljudi stalno miješaju. Unaprijed dijeljeni ključ autentifikuje IPsec partnere. Korisničko ime i lozinka identificiraju korisnika prema PPP-u. Ponovno upisivanje Windows dijeljene tajne na profilu koji se autentifikuje certifikatima ne mijenja ništa u fazi kvara, a uređivanje PPP lozinke ne može osigurati nedostajući zaštićeni kanal. Ista suzdržanost vrijedi i za provjeru identiteta: ne isključujte identitet partnera ni provjeru certifikata da biste dobili tunel, jer tada se povezuje put, a ne partner.

Autentifikacija također nije kraj PPP-a. Nakon što je korisnik prihvaćen, IPCP pregovara adresu klijenta i DNS i WINS opcije koje je server spreman dati. Klijent može proći CHAP ili MS-CHAPv2 i ipak ostati bez adrese, što je kvar unutar PPP-a, a ne problem rutiranja. Obični L2TP bez IPsec-a ostaje valjan i nezaštićen, pa uspješna veza nikada ne dokazuje da je promet zaštićen; provjerite šta server zahtijeva, a ne oznaku klijenta.

Odlučite po prvoj fazi koja nedostaje

Čitajte tabelu po prvom nedostajućem elementu, slijeva nadesno. Desna kolona je jedini posao koji u tom trenutku vrijedi; sve lijevo od nje već je dokazano, a ponovno testiranje troši prozor zastoja bez dodavanja informacija.

Tri reda zaslužuju upozorenje. Red 1701 je mjesto gdje obično završe Windows klijenti iza NAT-a: asocijacija se završi, zatim ništa ne stiže, a uzrok je enkapsulacija, ne loša lozinka. Red IPCP je onaj koji se pogrešno čita kao problem rute, jer Windows umota nedostajuću adresu u grešku 720, a ikona u traci samo kaže da veza nije uspjela; taj kvar stoji poslije autentifikacije i prije rutiranja. Posljednji red nije nikakav IPsec kvar iako ikona u traci kaže da je veza prekinuta.

Komande koje razdvajaju slojeve

Na Linux serveru sa strongSwan swanctl --list-sas ispisuje uspostavljene asocijacije s identitetom partnera, a ipsec statusall pokriva starije strongSwan i libreswan hostove. Ispod ip xfrm state prikazuje stvarne asocijacije kernela, dok ss -lunp | grep 1701 dokazuje gdje je xl2tpd vezan. Pokrenite xl2tpd -D u prvom planu da vidite kontrolne veze i pozive, i uključite pppd debug u /etc/ppp/options.xl2tpd da vidite ponuđenu metodu i odgovor.

Kada dnevnici pokažu uspješnu autentifikaciju, sljedeće pitanje je je li IPCP završio. Provjerite ima li ip range u odjeljku [lns default] fajla /etc/xl2tpd/xl2tpd.conf još slobodnih adresa i nosi li /etc/ppp/options.xl2tpd zaista ms-dns i ms-wins ako ih klijent očekuje. Iscrpljen pul i nedostajuća DNS opcija izgledaju različito na žici: prvo ostavlja klijenta bez adrese i sa 720, drugo daje adresu ali bez resolvera, pa imena padaju dok ping na sirove adrese radi. Ni jedno se ne popravlja ponovnim unosom lozinke.

Na klijentu NetworkManager L2TP dodatak upisuje pppd razgovor u dnevnik, pa journalctl -u NetworkManager -b obično razdvaja tunel podignut, autentifikacija odbijena od nema tunela uopće. Na Windowsu Get-VpnConnection prijavljuje stvarne postavke autentifikacije profila, a RasClient događaji pod Application u Event Vieweru imenuju komponentu koja pada. Kada je dijalog nejasan, uključite netsh ras set tracing * enable.

Snimke traže jedno upozorenje. U transportnom režimu IPsec-a unutrašnji UDP 1701 je šifrovan, pa snimka na vanjskom interfejsu pokazuje ESP, ili UDP 4500 pod NAT-T, i nikakav L2TP. Nedostatak 1701 u snimci je očekivan i nije dokaz blokiranog porta; gledajte pomjeraju li se brojači ESP ili 4500.

NAT, MTU i rute: gdje vas stek zavarava

NAT lomi pretpostavke prije nego što je išta autentifikovano. ESP je vlastiti IP protokol, pa ga uređaj koji prevodi odbacuje osim ako partneri ne enkapsuliraju; to pruža UDP 4500. Na Windows serveru koji i sam stoji iza kućnog rutera ili cloud NAT gatewaya IPsec faza pada s greškom 789 dok se AssumeUDPEncapsulationContextOnSendRule ne postavi na 2 pod ključem PolicyAgent i mašina ne restartuje, a kvar ostaje nerazlučiv od zatvorenog porta. Klijenti iza NAT-a su lakši: uz javnu adresu na serveru NAT-T na UDP 4500 ih nosi i ta vrijednost nije uključena.

Kada je PPP podignut, MTU s crnom rupom oponaša mrtav tunel: mali paketi prolaze, TLS rukovanje ili učitavanje stranice visi, a klijent može još pokazivati povezano. Spustite MTU interfejsa ili stisnite MSS na gatewayu prije nego optužite server. Rutiranje podijeljenog tunela je drugi varalica; podmreža poslana s pogrešnom maskom ostavlja tunel zdravim, a jednu aplikaciju nedostupnom. Privatno ime hosta dodaje svoj korak: ako upit izađe preko lokalnog resolvera, ime se ne razriješi prije nego što se testira ikakva ruta.

Kontrolna lista prije nego dirnete akreditive

Prođite listu po redu i zaustavite se na prvom elementu koji padne. Svaki korak je jeftin, a svaki isključuje čitavu klasu izmjena.

1. Potvrdite da asocijacija postoji na oba kraja, uparena po identitetu partnera, a ne po oznaci veze.
2. Potvrdite da UDP 1701 stiže do xl2tpd; asocijacija bez poziva je vaš kvar.
3. Pročitajte PPP presudu, i ako je autentifikovao, IPCP rezultat, prije nego pretpostavite da je lozinka pogrešna.
4. Tek sada ponovo unesite akreditive u formatu koji server očekuje, jer prefiks domena mijenja račun.
5. Ako i dalje padne, snimite oba kraja s usklađenim vremenskim oznakama i uporedite fazu po fazu.

Zaustavljanje na drugom koraku znači problem puta ili enkapsulacije, i nikakva izmjena lozinke ga neće pomjeriti. Zaustavljanje na trećem koraku znači da dnevnik već imenuje metodu ili pul adresa koji treba popraviti. U oba slučaja sljedeća izmjena je ona koju možete opravdati, i prestajete kružiti kroz postavke koje nikada nisu bile uključene.