Kuris VPN etapas nepavyko: IPsec, L2TP valdymas ar PPP autentifikavimas
Raskite paskutinį sėkmingą etapą ir sutaisykite tik tą sluoksnį: IPsec, L2TP valdymo kanalą, PPP autentifikavimą ar adreso priskyrimą.
Pakeitėte slaptažodį ir niekas nepajudėjo, nes gedimas niekada nebuvo PPP. L2TP/IPsec praneša apie vieną ryšio klaidą penkiems visiškai skirtingiems perdavimams, ir kiekvienas perdavimas turi savo taisymą. Dirbkite atgaline tvarka: raskite paskutinį sėkmingą etapą ir keiskite tik tai, kas ateina po jo. Žemiau pateikta tvarka taip pat nulemia, kokius įrodymus rinksite pirmiausia.
Atsakykite į keturis klausimus iš eilės
Priverskite naują bandymą, nes kai kurie klientai rodo ankstesnę klaidą tol, kol profilis atjungiamas ir vėl prijungiamas. Tada atsakykite: ar buvo IPsec saugumo asociacija, ar pasirodė L2TP valdymo ryšys ir skambutis, ar PPP pasiekė autentifikavimo sprendimą ir ar IPCP suteikė klientui adresą? Pirmasis ne yra etapas, kurį taisote. Viskas po jo nepatikrinta, todėl atmestas vartotojo vardas nieko neįrodo, kai asociacijos niekada nebuvo.
Prieš lygindami sinchronizuokite laikrodžius abiejuose galuose. Bandymas, kuris išvalė IPsec ir nepavyko ties PPP, atrodo kaip vienas gedimas, kai klientas rodo tik paskutinę žinutę, o serverio žurnalas dar laiko ankstesnį bandymą. Skaitykite pagal laiko žymą, o ne pagal garsiausią eilutę.
Kai turite tik vartotojo ekrano nuotrauką, remkitės pigiausiu atskyrimu: neteisingas iš anksto bendrinamas raktas ir xl2tpd, kuris niekada neatsako, sukuria tą patį tekstą Windows dialoge, tačiau vienam reikia abiejuose galuose pakeistos paslapties, o kitam – serveryje paleisto demono ar ugniasienės taisyklės. Tarpinis įrenginys negali išmesti vidinio 1701 po to, kai transporto režimo IPsec jį apvyniojo, todėl neieškokite kelio filtro, kurio nėra.
Ką iš tikrųjų valdo kiekvienas sluoksnis
IPsec saugo paketus tarp dviejų partnerių; L2TP perduoda PPP sesiją to apsaugoto kelio viduje, todėl RFC 3193 nurodo transporto režimą, o ne savo tunelį. Kliento etiketė sako L2TP, todėl tunelis ir prisijungimas atrodo kaip vienas mechanizmas. Taip nėra: L2TP valdymo ryšys autentifikuoja tunelio galus ten, kur įdiegimas tai įjungia, o PPP atskirai autentifikuoja vartotoją CHAP, PAP arba MS-CHAPv2 pagal serverio politiką.
Šis atskyrimas paaiškina dvi paslaptis, kurias žmonės nuolat painioja. Iš anksto bendrinamas raktas autentifikuoja IPsec partnerius. Vartotojo vardas ir slaptažodis identifikuoja vartotoją PPP. Windows bendrinamos paslapties perrašymas profilyje, kuris autentifikuojasi sertifikatais, nieko nekeičia nepavykusiame etape, o PPP slaptažodžio redagavimas negali suteikti trūkstamo apsaugoto kanalo. Toks pat susilaikymas galioja tapatybės patikrai: neišjunkite partnerio tapatybės ar sertifikato tikrinimo, kad gautumėte tunelį, nes tada jungiasi kelias, o ne partneris.
Autentifikavimas taip pat nėra PPP pabaiga. Kai vartotojas priimtas, IPCP derasi dėl kliento adreso ir DNS bei WINS parinkčių, kurias serveris sutinka duoti. Klientas gali praeiti CHAP arba MS-CHAPv2 ir vis tiek likti be adreso, o tai yra gedimas PPP viduje, o ne maršrutizavimo problema. Paprastas L2TP be IPsec lieka galiojantis ir neapsaugotas, todėl sėkmingas prisijungimas niekada neįrodo, kad srautas apsaugotas; tikrinkite, ko reikalauja serveris, o ne kliento etiketę.
Spręskite pagal pirmą trūkstamą etapą
Lentelę skaitykite pagal pirmą trūkstamą elementą, iš kairės į dešinę. Dešinysis stulpelis yra vienintelis darbas, kuris tuo metu vertas; viskas jo kairėje jau įrodyta, o pakartotinis tikrinimas sudegina sutrikimo langą nepridėdamas informacijos.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Trys eilutės vertos įspėjimo. 1701 eilutė yra vieta, kur paprastai atsiduria Windows klientai už NAT: asociacija baigiama, tada niekas neateina, o priežastis yra inkapsuliavimas, o ne blogas slaptažodis. IPCP eilutė yra ta, kuri klaidingai skaitoma kaip maršruto problema, nes Windows trūkstamą adresą įvynioja į klaidą 720, o dėklo piktograma tik pasako, kad ryšys nepavyko; šis gedimas yra po autentifikavimo ir prieš maršrutizavimą. Paskutinė eilutė visai nėra IPsec gedimas, nors piktograma sako atjungta.
Komandos, kurios atskiria sluoksnius
Linux serveryje su strongSwan swanctl --list-sas išvardija nustatytas asociacijas su partnerio tapatybe, o ipsec statusall apima senesnius strongSwan ir libreswan hostus. Po tuo ip xfrm state rodo tikrąsias branduolio asociacijas, o ss -lunp | grep 1701 įrodo, kur xl2tpd susietas. Paleiskite xl2tpd -D priekiniame plane, kad matytumėte valdymo ryšius ir skambučius, ir įjunkite pppd derinimą /etc/ppp/options.xl2tpd, kad matytumėte pasiūlytą metodą ir atsakymą.
Kai žurnalai rodo sėkmingą autentifikavimą, kitas klausimas – ar IPCP baigtas. Patikrinkite, ar ip range /etc/xl2tpd/xl2tpd.conf [lns default] skiltyje dar turi laisvų adresų, ir ar /etc/ppp/options.xl2tpd tikrai turi ms-dns bei ms-wins, jei klientas jų tikisi. Išsemtas telkinys ir trūkstama DNS parinktis laide atrodo skirtingai: pirmasis palieka klientą be adreso ir su 720, antrasis duoda adresą, bet ne rezolverį, todėl vardai nepavyksta, o ping į neapdorotus adresus veikia. Nė vieno nepataiso pakartotinis slaptažodžio įvedimas.
Kliente NetworkManager L2TP papildinys įrašo pppd pokalbį į žurnalą, todėl journalctl -u NetworkManager -b paprastai atskiria tunelis pakeltas, autentifikavimas atmestas nuo tunelio visai nėra. Windows Get-VpnConnection praneša tikruosius profilio autentifikavimo nustatymus, o RasClient įvykiai po Application Event Viewer programoje įvardija nepavykusį komponentą. Kai dialogas pernelyg neaiškus, įjunkite netsh ras set tracing * enable.
Įrašams reikia vieno atsargumo. Transporto režimo IPsec atveju vidinis UDP 1701 yra šifruotas, todėl įrašas išoriniame sąsajoje rodo ESP arba UDP 4500 su NAT-T ir visai jokio L2TP. 1701 nebuvimas įraše yra tikėtinas ir nėra užblokuoto prievado įrodymas; stebėkite, ar juda ESP ar 4500 skaitikliai.
NAT, MTU ir maršrutai: kur krūva jus klaidina
NAT laužo prielaidas dar prieš ką nors autentifikuojant. ESP yra savas IP protokolas, todėl verčiantis įrenginys jį išmeta, nebent partneriai inkapsuliuoja; būtent tai suteikia UDP 4500. Windows serveryje, kuris pats stovi už namų maršrutizatoriaus ar debesų NAT šliuzo, IPsec etapas nepavyksta su klaida 789, kol AssumeUDPEncapsulationContextOnSendRule PolicyAgent rakte nustatomas į 2 ir mašina paleidžiama iš naujo, o gedimas lieka neatskiriamas nuo uždaryto prievado. Klientai už NAT yra lengvesni: kai serveryje yra viešas adresas, NAT-T per UDP 4500 juos perneša ir ta vertė nedalyvauja.
Kai PPP pakeltas, juodos skylės MTU imituoja mirusį tunelį: maži paketai praeina, TLS rankos paspaudimas ar puslapio įkėlimas pakimba, o klientas gali vis dar rodyti prisijungusį. Prieš kaltindami serverį sumažinkite sąsajos MTU arba suspaustkite MSS šliuze. Skirtojo tunelio maršrutizavimas yra kitas apsimetėlis; potinklis, išsiųstas su neteisinga kauke, palieka tunelį sveiką, o vieną programą nepasiekiamą. Privatus pagrindinio kompiuterio vardas prideda savo šuolį: jei užklausa išeina per vietinį rezolverį, vardas neišsprendžiamas dar prieš išbandant bet kurį maršrutą.
Kontrolinis sąrašas prieš liesdami prisijungimo duomenis
Atlikite sąrašą iš eilės ir sustokite ties pirmu nepavykusiu elementu. Kiekvienas žingsnis pigus, ir kiekvienas atmeta visą pataisų klasę.
- Patvirtinkite, kad asociacija yra abiejuose galuose, suderinta pagal partnerio tapatybę, o ne pagal prisijungta etiketę.
- Patvirtinkite, kad UDP 1701 pasiekia xl2tpd; asociacija be skambučio yra jūsų gedimas.
- Perskaitykite PPP nuosprendį ir, jei autentifikuota, IPCP rezultatą, prieš manydami, kad slaptažodis neteisingas.
- Tik dabar įveskite prisijungimo duomenis iš naujo tokiu formatu, kokio tikisi serveris, nes domeno priešdėlis keičia paskyrą.
- Jei vis tiek nepavyksta, užfiksuokite abu galus su sulygintomis laiko žymomis ir palyginkite etapą po etapo.
Sustojimas ties antru žingsniu reiškia kelio ar inkapsuliavimo problemą, ir jokia slaptažodžio pataisa to nepajudins. Sustojimas ties trečiu žingsniu reiškia, kad žurnalas jau įvardija taisytiną metodą ar adresų telkinį. Bet kuriuo atveju kitas pakeitimas yra toks, kurį galite pagrįsti, ir liaujatės sukdamiesi per nustatymus, kurie niekada nedalyvavo.