De ce se opresc PPTP și L2TP/IPsec înainte de solicitarea numelui de utilizator?

Absența solicitării numelui de utilizator este un cadou de diagnostic: PPP nu a pornit încă, deci contul, parola și politica de domeniu nu au fost încă întrebate. Într-o conexiune PPTP sau L2TP/IPsec clientul cere acreditări doar după ce tunelul există și serverul a început o sesiune PPP. Tot ce poate eșua înainte de acel moment este transport, schimb de chei sau configurare a tunelului, o suprafață mult mai mică decât „VPN-ul este stricat”.

O solicitare lipsă reduce defecțiunea la trei etape

Notați ultima etapă care a reușit vizibil, pentru că fiecare are alt proprietar și altă soluție. Să ghicești setările contului în timp ce ești blocat cu două etape mai devreme este felul în care dispare o după-amiază.

Un client care expiră fără solicitare nu a obținut niciodată o asociere IPsec, deci defecțiunea este în IKE sau în faptul că pachetele tale ajung la gateway. Cel care raportează că verifică acreditările și apoi cade a ajuns mai departe decât sugerează mesajul. O solicitare urmată de un refuz este autentificare PPP, iar asta aparține unui articol despre cont, nu acestuia.

Prima etapă: protocolul pe care un firewall îl aruncă în tăcere

PPTP are nevoie de TCP 1723 pentru canalul de control și de protocolul IP 47 pentru calea de date, iar cele două călătoresc separat. Multe rețele transmit 1723 și aruncă protocolul 47, ceea ce produce un tunel care negociază și apoi nu transportă absolut nimic. Un router care face NAT are nevoie și de o trecere cu suport GRE, iar o cale de acces doar IPv6 nu poate transporta PPTP în nicio configurație.

L2TP peste IPsec consumă portul 500 pentru IKE și portul 4500 pentru traversarea NAT, apoi împachetează traficul L2TP în 1701, în timp ce ESP transportă încărcătura protejată odată ce asocierea există. Permite cele două porturi de control dar nu ESP, și obții exact simptomul din titlu: progres vizibil, apoi un client mort înainte de orice dialog de acreditări. Testarea de pe un hotspot de telefon este o modalitate ieftină de a separa o problemă de client de o problemă de cale.

A doua etapă: o cheie care nu este cheia, o propunere care nu este oferită

O cheie prepartajată care nu se potrivește eșuează rapid și silențios, iar versiunea obișnuită este o cheie care arată corect pe ecran dar poartă un sfârșit de rând lipit sau un spațiu la final. Pe un client Linux dialogul nu este neapărat sursa adevărului: modulul L2TP al NetworkManager păstrează secretele în fișiere sub /etc/ipsec.d/, iar un fișier mai vechi pentru fiecare conexiune pe care /etc/ipsec.secrets îl include încă va fi folosit în locul celui tocmai tastat. Copiază acel fișier într-un loc sigur, scoate-l din calea de includere și apoi tastează cheia din nou manual.

Cealaltă jumătate a acestei etape este propunerea. Ambele capete trebuie să cadă de acord asupra aceluiași set de algoritmi pentru faza 1 — criptare, integritate și grupul Diffie-Hellman — și asupra transformărilor ESP corespunzătoare pentru faza 2, altfel asocierea nu se formează deloc. Un gateway care oferă doar 3DES, SHA1 și MODP1024 va refuza un client configurat pentru algoritmi mai puternici, iar jurnalul său numește transformarea refuzată. Jurnalul numește nepotrivirea dacă îl citești în loc să repornești serviciul încă o dată. În loc să copiezi un șir de algoritmi dintr-un fir de forum, întreabă gateway-ul ce transformări va negocia de fapt: ike-scan îndreptat spre adresa sa returnează transformările pe care le va negocia. Dacă singura ofertă este criptografie pe care politica ta nu o mai permite, corectarea aparține gateway-ului, nu unei retrogradări a clientului.

În Windows cheia și metoda de autentificare stau în profilul VPN, iar o nepotrivire apare înainte de solicitarea acreditărilor, nu după. Unde receptorul este un Windows Server, confirmă că rolul de acces la distanță este instalat, că certificatul corespunde numelui la care se conectează clienții și că niciun filtru de porturi nu este mai îngust decât protocoalele de mai sus.

A treia etapă: tunelul există și PPP nu pornește niciodată

Când IKE s-a încheiat și solicitarea tot nu apare, uită-te la daemonul tunelului, nu la firewall. L2TP are nevoie de ceva care ascultă pe UDP 1701 — xl2tpd sau kl2tpd pe Linux, serviciul de acces la distanță pe Windows — iar un serviciu instalat dar oprit arată din partea clientului exact ca un pachet aruncat. Verifică ascultătorul înainte de a redeschide reguli pe care le-ai verificat deja. Apoi PPP trebuie să negocieze, iar primul schimb LCP este locul unde de obicei aterizează o eșuare silențioasă.

O capcană din această etapă nu este deloc o defecțiune de rețea: Windows permite o singură conexiune de un anumit tip de VPN odată, așa că o a doua încercare returnează eroarea 937, „o altă conexiune de acest tip este în uz”. Este o regulă locală, iar ocolirea ei este un alt dispozitiv, un alt tip de tunel sau partajarea singurei conexiuni care există deja.

Citiți jurnalul în ordinea etapelor în loc să ghiciți

Oprește clientul, pornește-l din nou și citește componentele în ordinea în care scriu în jurnal. Adică mai întâi daemonul IPsec — strongSwan sau Libreswan, iar ipsec --version îți spune care — apoi daemonul L2TP, apoi pppd. Componenta care a scris ultima înainte de eșuare marchează etapa de investigat, pentru că tot ce vine după ea în secvență nu a rulat deloc.

Verifică cu o conexiune proaspătă și nu cu o sesiune salvată, pentru că un client care se reconectează din cache poate sări peste părți ale schimbului și poate reproduce un rezultat învechit. Confirmă accesibilitatea, schimbul de chei, tunelul și PPP unul câte unul, în această ordine. Atunci solicitarea lipsă încetează să mai fie un mister și devine a doua linie a unei liste pe care chiar poți lucra. Acea listă este și ceea ce predai echipei de rețea, care altfel ar fi rugată să verifice firewall-ul pentru o defecțiune ce trăiește într-un daemon nepornit.