Pașii strângerii de mână VPN: ce se întâmplă înainte să curgă traficul

Apăsarea butonului Conectare pornește patru sarcini separate care reușesc sau eșuează independent. Clientul trebuie să atingă un ascultător, să cadă de acord cine este partenerul, să derive chei și apoi să predea un tunel funcțional restului sistemului. Majoritatea conexiunilor eșuate sunt diagnosticate în sarcina greșită. De aceea prima eroare contează mai mult decât a treia încercare.

Atingeți mai întâi ascultătorul

Înainte de a se schimba orice identitate, clientul rezolvă un nume, alege o rută și deschide un transport către un port. Un portal captiv care răspunde la tot, un port închis și un nume de gazdă greșit eșuează toate aici, și niciunul nu este o problemă de autentificare. Schimbarea unei parole nu poate repara niciunul dintre cele trei. Citiți prima linie a erorii înainte de a atinge acreditările.

Un timeout, o respingere de certificat și un cont respins sunt trei defecțiuni diferite cu trei verificări diferite. Sortarea lor mai întâi este ceea ce împiedică o problemă de rețea să fie depanată ca problemă de acreditări.

Dovediți partenerul, apoi derivați cheile

Fiecare protocol are nevoie de o modalitate de a recunoaște serverul dorit, fie printr-o cheie publică configurată, fie printr-un lanț de certificate. Autentificarea utilizatorului este suplimentară acelei verificări, nu un substitut al ei. Un server care acceptă parola dumneavoastră nu a dovedit nimic despre propria identitate. De aceea un secret comun tastat într-un client nu înlocuiește verificarea cine a răspuns.

Schimbul derivă apoi cheile de trafic din intrările proprii ale protocolului, iar parola de autentificare nu este de obicei cheia ștampilată pe fiecare pachet. Materialul de identitate pe termen lung și cheile de sesiune pe termen scurt au durate de viață și sarcini diferite. Exact despre această separare este vorba în confidențialitatea înainte.

Păstrați verificarea activă în timp ce depanați, pentru că un tunel care se conectează după ce dezactivați o verificare nu a dovedit nimic în afară de faptul că verificarea făcea ceva. Notați ce ați schimbat și puneți la loc înainte de următorul test.

Trei protocoale, trei conversații

Într-o implementare OpenVPN bazată pe TLS, canalul de control negociază parametrii de securitate în timp ce canalul de date transportă traficul tunelului, așa că o opțiune de canal de date și o problemă de certificat se află în locuri diferite. IKEv2 autentifică ambii participanți și apoi stabilește asocieri de securitate IPsec cu propriile durate de viață. WireGuard derivă chei prin schimbul său bazat pe Noise și ține mașina de stări intenționat mică. A ști pe care dintre cele trei îl rulați decide ce jurnal merită citit.

Clienți care arată similar nu înseamnă mesaje interschimbabile dedesubt, iar un câmp de configurare care există într-un produs poate să nu aibă echivalent în altul. Copierea unui profil între ei este o presupunere, nu o migrare.

Ce nu face strângerea de mână

Rutele, rezolvarea numelor și politica de destinație rămân toate după aceea. Un site intern poate rămâne inaccesibil pentru că lipsește ruta subrețelei sale, chiar dacă partenerul a fost autentificat corect și tunelul este activ. Tratarea acestui lucru ca criptare slabă vă trimite să căutați în stratul greșit, și de obicei se termină cu o schimbare de cifru care nu repară nimic.

Reîmprospătarea cheilor și reconectarea arată la fel în majoritatea afișajelor de stare, și niciuna nu vă spune dacă traficul obișnuit a fost blocat în timpul întreruperii. Doar politica de eșec a clientului răspunde la această întrebare, așa că citiți politica, nu pictograma.

Parcurgeți etapele în ordinea de mai sus și opriți-vă la prima care produce o eroare. Fiecare etapă ulterioară moștenește starea celor anterioare, așa că o eroare la a treia etapă nu spune nimic despre a patra.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal