Ce se întâmplă de fapt când pornești un VPN pe Linux

Apasă conectare și pe o mașină Linux se schimbă trei lucruri: apare o interfață, se instalează rute și resolverul începe să răspundă altfel. Majoritatea eșecurilor de configurare vin din faptul că unul dintre aceste trei se întâmplă fără celelalte, sau din faptul că două programe nu sunt de acord cine le deține. Înțelegerea secvenței explică eșecul mai repede decât citirea ieșirii din jurnal a unui client.

O interfață apare înainte ca ceva să funcționeze

Un client de tunel deschide o interfață virtuală și îi predă pachete. Un dispozitiv TUN transportă pachete IP, de care are nevoie un VPN rutat; un dispozitiv TAP transportă cadre Ethernet, de care are nevoie un design punte. Modulul kernelului furnizează dispozitivul, iar clientul îl deține cât durează sesiunea.

Faptul că interfața urcă nu este același lucru cu un tunel care funcționează. Poate exista cu o adresă în timp ce partenerul este inaccesibil, și de aceea lista de interfețe este prima verificare, nu ultima. Un dispozitiv care raportează că este sus descrie viziunea kernelului asupra unei legături virtuale, nu disponibilitatea partenerului de a răspunde.

Lasă modul de interfață furnizat așa cum este. Trecerea unui profil TUN în TAP nu transformă un server rutat într-unul punte, și de obicei produce o conexiune care se stabilește și nu transmite nimic.

Rutele sunt instalate de cel care deține tunelul

Rutele sunt a doua schimbare, iar proprietatea lor contează mai mult decât conținutul. Un profil NetworkManager, o unitate systemd și un client pornit manual pot toate instala rute, iar două dintre ele făcând asta simultan produc un tabel pe care nimeni nu îl va putea explica mai târziu.

ip -br addr show
ip route show
ip -6 route show

Un profil de tunel complet înlocuiește ruta implicită; un profil de tunel divizat adaugă rute mai specifice și lasă ruta implicită în pace. Ambele sunt normale, iar al doilea este motivul pentru care ștergerea unei rute implicite este un prim test prost pe o mașină pe care o administrezi de la distanță. Eliminarea ei este și cea mai rapidă cale de a pierde sesiunea pe care o folosești pentru a remedia problema.

Citește tabelul în loc să presupui. O rută mai specifică sau o regulă de politică poate trimite traficul în tunel în timp ce ruta implicită încă indică interfața fizică, ceea ce pare contradictoriu până citești tot tabelul. Această combinație este normală pentru tunelul divizat și derutantă pentru cine se așteaptă ca o singură linie să descrie designul. Caută ruta care corespunde destinației tale reale, nu cea care corespunde diagramei.

Resolverul schimbă mâinile

DNS este a treia schimbare și cea care cel mai probabil este administrată într-un loc în care nu te-ai uitat. Pe un desktop, NetworkManager poate împinge setările resolverului pentru fiecare conexiune. Pe un sistem care folosește systemd-resolved, setările se aplică pentru fiecare legătură și /etc/resolv.conf poate fi un stub sau o legătură simbolică în loc de un fișier pe care ar trebui să îl editezi.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Dacă o modificare manuală a fișierului resolverului dispare după o reconectare, acesta este semnalul să găsești componenta care îl întreține și să schimbi profilul în schimb. Editarea fișierului generat este o schimbare pe care o reconectare o va șterge.

Numele private au de obicei nevoie de resolverul intern și de domeniile de căutare furnizate de operator. Înlocuirea cu un resolver public poate rupe exact resursa pentru care există VPN-ul, iar simptomul arată ca un eșec de rutare și nu ca un eșec DNS. Testează numele și adresa separat, pentru că unul funcționează și celălalt eșuează îți spune exact unde să te uiți. Acea singură comparație economisește o oră de depanare a rutelor.

Un singur manager pe conexiune

Formatul profilului decide ce program îl poate folosi. Un profil OpenVPN are nevoie de OpenVPN sau de un plugin compatibil, iar o configurație WireGuard are propriul format cu chei de partener și prefixe permise. O fereastră de import nu traduce unul în celălalt, orice ar sugera extensia fișierului.

Alege un singur manager și lasă-l să dețină conexiunea. Ridicarea aceluiași tunel prin două unelte face tabelul de rute și comportamentul la reconectare ambigue, iar al doilea care pornește câștigă de obicei în moduri greu de reprodus.

Instalează pachetele pe care le suportă distribuția ta și obține profilul de la operator. Tratează-l ca pe o acreditare, pentru că de obicei conține o cheie privată sau material echivalent, și păstrează-l acolo unde trăiesc restul secretelor tale. Un profil lăsat într-un folder de descărcări este o cheie lăsată pe un birou.

Ce să verifici când este sus dar nu funcționează

Cu interfața sus și clientul raportând succes, lucrează spre exterior: tabelul de rute selectează tunelul pentru destinație, resolverul răspunde pentru numele privat și partea îndepărtată are o cale de întoarcere. Fiecare are o comandă separată și un proprietar separat.

nmcli connection show --active
nmcli device status
wg show

Referința nmcli documentează comenzile de stare și de conexiune dacă ai nevoie de setul complet. Ce contează aici este distincția dintre un profil activ și un dispozitiv care transportă trafic, pentru că cele două pot fi în dezacord.

Reconectează-te o dată prin același manager înainte de a declara configurarea terminată, și verifică dacă DNS-ul încă funcționează după o deconectare. O configurație care funcționează doar până la prima schimbare de rețea nu este terminată, ea doar funcționează în acest moment.