L2TP/IPsec se conectează într-o rețea și expiră în alta

Același laptop, același profil și aceeași parolă funcționează într-o clădire și eșuează în alta. Această comparație este cea mai utilă dovadă din tichet, și de obicei este primul lucru aruncat. Între două rețele de acces, schimbul trece prin altă traducere de adrese, alte filtre și alți ajutoare de router. Păstrarea clientului neschimbat și modificarea doar a rețelei este modul de a afla care dintre acestea contează.

Fixați clientul înainte de a compara rețelele

Nu modificați nimic pe dispozitiv până nu aveți o înregistrare a cazului funcțional: versiunea clientului, conținutul profilului, numele serverului și ora conexiunii reușite. Apoi reproduceți defecțiunea în a doua rețea în aceeași sesiune, astfel încât starea clientului să fie cât mai identică posibil. Un profil editat între cele două încercări invalidează întreaga comparație. Scopul este o singură variabilă, iar acea variabilă este rețeaua.

Confirmați mai întâi accesul obișnuit la internet în rețeaua care eșuează, inclusiv un portal pentru oaspeți dacă există. Un portal care nu a fost niciodată completat produce o expirare care arată exact ca un tunel filtrat, iar acea verificare durează un minut.

Patru etape, patru mesaje de eroare diferite

O conexiune L2TP/IPsec trece prin patru etape, iar RFC 3193 descrie aranjamentul care le leagă pe primele două. Negocierea IKE este locul unde o cale filtrată produce o expirare silențioasă. Autentificarea IPsec este locul unde o nepotrivire de certificat sau de cheie prepartajată produce în schimb un refuz explicit. Configurarea tunelului L2TP este locul unde o asociere de securitate deja stabilită poate totuși să nu ducă nicăieri, iar autentificarea PPP este locul unde o credențială greșită produce în cele din urmă o eroare vizibilă. Citiți jurnalul pentru etapa care s-a oprit, nu pentru ultima linie tipărită.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

Jurnalul strongSwan arată dacă schimbul IKE a ajuns la o propunere și dacă partenerul a răspuns măcar, ceea ce separă accesibilitatea de politică. Jurnalul xl2tpd preia unde se termină IPsec, așa că o asociere de securitate stabilită fără nimic în acel jurnal indică etapa L2TP. Interogarea rutei confirmă că clientul trimite către adresa de server pe care o credeți, ceea ce prinde un răspuns DNS învechit moștenit de la rețeaua anterioară. Împreună, cele trei ieșiri numesc o etapă în loc de un simptom.

Comparați adâncimea NAT și comportamentul ajutorului

Traversarea NAT mută traficul protejat pe încapsulare UDP atunci când este detectată traducerea, astfel încât numerele de port care transportă o sesiune funcțională pot diferi de cele dintr-o diagramă statică. Permiterea unui singur pachet de configurare nu dovedește nimic despre restul schimbului, iar o scanare externă de porturi nu vă poate spune cum tratează partenerul traficul autentificat valid. Un al doilea strat de traducere schimbă din nou tabloul, pentru că maparea există acum de două ori și expiră după două calendare diferite. Traducerea la nivel de operator pe o conexiune mobilă este motivul obișnuit pentru care un profil de birou funcțional eșuează pe un hotspot de telefon.

Ajutoarele de router variază la fel de mult ca rețelele. Unele firmware-uri interceptează și rescriu schimbul, altele doar nu mai aruncă pachetele, iar altele aplică setarea doar într-un mod vechi. Citiți descrierea pe care firmware-ul o dă căsuței de bifare, iar unde există un mod de compatibilitate, testați-l ca o singură modificare deliberată în loc de trei deodată.

Client de ieșire, server de intrare: două probleme diferite

Un client de ieșire și un server de intrare au nevoie de accesibilitate diferită în amonte, iar o funcție de trecere care ajută primul nu face nimic pentru al doilea. Un router de acasă care lasă laptopul să ajungă la o poartă îndepărtată nu acceptă prin asta conexiuni de intrare către un server din spatele lui. Confundarea celor două vă trimite să căutați redirecționare de porturi care nu a fost niciodată problema. Precizați ce rol are dispozitivul care eșuează înainte de a compara ceva.

După o modificare acceptată, repetați aceeași conexiune și notați etapa la care a ajuns. Păstrați împreună profilul funcțional și nota despre rețeaua care eșuează, și nu resetați datele de autentificare și nu reinstalați clientul, pentru că asta aruncă dovada pe care s-a construit comparația.