Care etapă VPN a eșuat: IPsec, controlul L2TP sau autentificarea PPP

Ați schimbat parola și nimic nu s-a mișcat, pentru că defecțiunea nu a fost niciodată în PPP. L2TP/IPsec raportează o singură eroare de conexiune pentru cinci predări foarte diferite, iar fiecare predare are reparația ei. Lucrați invers: găsiți ultima etapă care a reușit și schimbați doar ce urmează după ea. Ordinea de mai jos decide și ce dovezi strângeți mai întâi.

Răspundeți la patru întrebări în ordine

Forțați o încercare nouă, pentru că unii clienți continuă să afișeze eroarea anterioară până când profilul este deconectat și reconectat. Apoi răspundeți: a existat o asociere de securitate IPsec, au apărut o conexiune de control L2TP și un apel, PPP a ajuns la un verdict de autentificare și IPCP a dat clientului o adresă? Primul nu este etapa pe care o reparați. Tot ce urmează nu a fost testat, așa că un nume de utilizator respins nu dovedește nimic când nu a existat niciodată o asociere.

Sincronizați ceasurile de la ambele capete înainte de a compara. O reîncercare care a curățat IPsec și a eșuat la PPP pare o singură defecțiune când clientul arată doar mesajul final, iar jurnalul serverului păstrează încă încercarea anterioară. Citiți după marcajul de timp, nu după linia cea mai zgomotoasă.

Când aveți doar captura de ecran a utilizatorului, sprijiniți-vă pe cea mai ieftină separare: o cheie prepartajată greșită și un xl2tpd care nu răspunde niciodată produc același text în dialogul Windows, însă unul cere un secret schimbat la ambele capete, iar celălalt un demon pornit sau o regulă de firewall pe serverul însuși. Un echipament la mijloc nu poate arunca 1701 interior după ce IPsec în modul transport l-a împachetat, așa că nu căutați un filtru de cale care nu există.

Ce deține de fapt fiecare strat

IPsec protejează pachetele între cei doi parteneri; L2TP transportă o sesiune PPP în interiorul acelei căi protejate, de aceea RFC 3193 specifică modul transport în locul unui tunel propriu. Eticheta clientului spune L2TP, așa că tunelul și autentificarea par un singur mecanism. Nu sunt: conexiunea de control L2TP autentifică capetele tunelului acolo unde implementarea o activează, iar PPP autentifică utilizatorul separat cu CHAP, PAP sau MS-CHAPv2 conform politicii serverului.

Această separare explică cele două secrete pe care oamenii le confundă mereu. O cheie prepartajată autentifică partenerii IPsec. Un nume de utilizator și o parolă identifică utilizatorul în fața PPP. Rescrierea secretului partajat Windows pe un profil care se autentifică cu certificate nu schimbă nimic la etapa care eșuează, iar editarea parolei PPP nu poate furniza un canal protejat lipsă. Aceeași reținere se aplică verificării identității: nu dezactivați identitatea partenerului sau validarea certificatului pentru a obține un tunel, pentru că atunci se conectează calea, nu partenerul.

Nici autentificarea nu este sfârșitul PPP. După ce utilizatorul este acceptat, IPCP negociază adresa clientului și opțiunile DNS și WINS pe care serverul este dispus să le dea. Un client poate trece CHAP sau MS-CHAPv2 și totuși rămâne fără adresă, ceea ce este o defecțiune în interiorul PPP și nu o problemă de rutare. L2TP simplu fără IPsec rămâne valid și neprotejat, așa că o conexiune reușită nu dovedește niciodată că traficul este protejat; verificați ce impune serverul, nu eticheta clientului.

Decideți după prima etapă lipsă

Citiți tabelul după primul element lipsă, de la stânga la dreapta. Coloana din dreapta este singura muncă ce merită în acel moment; tot ce este la stânga ei este deja dovedit, iar retestarea arde fereastra de întrerupere fără a adăuga informație.

Trei rânduri merită un avertisment. Rândul 1701 este locul unde ajung de obicei clienții Windows din spatele NAT: asocierea se completează, apoi nu sosește nimic, iar cauza este încapsularea, nu o parolă proastă. Rândul IPCP este cel citit greșit ca problemă de rută, pentru că Windows împachetează adresa lipsă în eroarea 720 și pictograma din tavă spune doar că conexiunea a eșuat; acea defecțiune stă după autentificare și înainte de rutare. Ultimul rând nu este deloc o defecțiune IPsec, deși pictograma spune deconectat.

Comenzi care separă straturile

Pe un server Linux cu strongSwan, swanctl --list-sas listează asocierile stabilite cu identitatea partenerului, iar ipsec statusall acoperă gazde strongSwan și libreswan mai vechi. Dedesubt, ip xfrm state arată asocierile reale ale nucleului, iar ss -lunp | grep 1701 dovedește unde este legat xl2tpd. Rulați xl2tpd -D în prim-plan pentru a vedea conexiuni de control și apeluri apărând, și activați depanarea pppd în /etc/ppp/options.xl2tpd pentru a vedea metoda oferită și răspunsul.

Când jurnalele arată o autentificare reușită, următoarea întrebare este dacă IPCP s-a încheiat. Verificați dacă ip range din secțiunea [lns default] a fișierului /etc/xl2tpd/xl2tpd.conf mai are adrese libere și dacă /etc/ppp/options.xl2tpd poartă într-adevăr ms-dns și ms-wins dacă clientul le așteaptă. Un bazin epuizat și o opțiune DNS lipsă arată diferit pe fir: primul lasă clientul fără adresă și cu 720, al doilea dă o adresă dar niciun resolver, așa că numele eșuează în timp ce ping către adrese brute funcționează. Niciunul nu se repară prin reintroducerea parolei.

Pe client, modulul L2TP al NetworkManager scrie conversația pppd în jurnal, așa că journalctl -u NetworkManager -b separă de obicei tunel sus, autentificare refuzată de niciun tunel deloc. Pe Windows, Get-VpnConnection raportează setările reale de autentificare ale profilului, iar evenimentele RasClient din Application în Event Viewer numesc componenta care eșuează. Când dialogul este prea vag, activați netsh ras set tracing * enable.

Capturile cer o singură precauție. Cu IPsec în modul transport, UDP 1701 interior este criptat, așa că o captură pe interfața exterioară arată ESP, sau UDP 4500 sub NAT-T, și niciun L2TP. Lipsa 1701 într-o captură este așteptată și nu este dovada unui port blocat; urmăriți dacă contoarele ESP sau 4500 se mișcă.

NAT, MTU și rute: unde stiva vă induce în eroare

NAT sparge presupunerile înainte ca ceva să fie autentificat. ESP este propriul său protocol IP, așa că un echipament care traduce îl aruncă dacă partenerii nu încapsulează; exact asta oferă UDP 4500. Pe un server Windows care stă el însuși în spatele unui router de acasă sau al unei porți NAT din cloud, etapa IPsec eșuează cu eroarea 789 până când AssumeUDPEncapsulationContextOnSendRule este setat la 2 sub cheia PolicyAgent și mașina repornește, iar defecțiunea rămâne imposibil de distins de un port închis. Clienții din spatele NAT sunt mai simpli: cu o adresă publică pe server, NAT-T pe UDP 4500 îi transportă și acea valoare nu este implicată.

După ce PPP este sus, un MTU cu gaură neagră imită un tunel mort: pachetele mici trec, o strângere de mână TLS sau încărcarea unei pagini se blochează, iar clientul poate afișa în continuare conectat. Coborâți MTU-ul interfeței sau strângeți MSS la poartă înainte de a da vina pe server. Rutarea tunelului despicat este celălalt impostor; o subrețea trimisă cu masca greșită lasă tunelul sănătos și o aplicație inaccesibilă. Un nume de gazdă privat adaugă propriul salt: dacă interogarea iese prin resolverul local, numele nu se rezolvă înainte de testarea vreunei rute.

Listă de verificare înainte de a atinge acreditările

Parcurgeți lista în ordine și opriți-vă la primul element care eșuează. Fiecare pas este ieftin, iar fiecare exclude o întreagă clasă de modificări.

1. Confirmați că asocierea există la ambele capete, potrivită după identitatea partenerului, nu după o etichetă conectat.
2. Confirmați că UDP 1701 ajunge la xl2tpd; o asociere fără apel este defecțiunea dumneavoastră.
3. Citiți verdictul PPP și, dacă a autentificat, rezultatul IPCP, înainte de a presupune că parola este greșită.
4. Abia acum reintroduceți acreditările în formatul așteptat de server, fiindcă un prefix de domeniu schimbă contul.
5. Dacă tot eșuează, capturați ambele capete cu marcaje de timp aliniate și comparați etapă cu etapă.

Oprirea la pasul doi înseamnă o problemă de cale sau de încapsulare, iar nicio modificare a parolei nu o va mișca. Oprirea la pasul trei înseamnă că jurnalul numește deja metoda sau bazinul de adrese de reparat. În ambele cazuri, următoarea schimbare este una pe care o puteți justifica, și nu mai învârtiți setări care nu au fost niciodată implicate.