Què passa realment quan engegues una VPN a Linux

Premeu connecta i a una màquina Linux canvien tres coses: apareix una interfície, s'instal·len rutes i el resolutor comença a respondre d'una manera diferent. La majoria de les fallades de configuració venen que una d'aquestes tres coses passi sense les altres, o que dos programes no es posin d'acord sobre qui les posseeix. Entendre la seqüència explica la fallada més de pressa que llegir la sortida del registre d'un client.

Una interfície apareix abans que res funcioni

Un client de túnel obre una interfície virtual i hi lliura paquets. Un dispositiu TUN transporta paquets IP, que és el que necessita una VPN encaminada; un dispositiu TAP transporta trames Ethernet, que és el que necessita un disseny pont. El mòdul del nucli proporciona el dispositiu, i el client el posseeix mentre dura la sessió.

Que la interfície pugi no és el mateix que el túnel funcioni. Pot existir amb una adreça mentre el par no és accessible, i per això la llista d'interfícies és la primera comprovació i no l'última. Un dispositiu que es declara aixecat descriu la visió del nucli d'un enllaç virtual, no la disposició del par a respondre.

Deixeu el mode d'interfície subministrat tal com és. Canviar un perfil TUN a TAP no converteix un servidor encaminat en un de pont, i normalment produeix una connexió que s'estableix i no reenvia res.

Les rutes les instal·la qui posseeix el túnel

Les rutes són el segon canvi, i la seva propietat importa més que el seu contingut. Un perfil de NetworkManager, una unitat de systemd i un client executat a mà poden instal·lar rutes, i que dos ho facin alhora produeix una taula que ningú no podrà explicar després.

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

Un perfil de túnel complet substitueix la ruta per defecte; un perfil de túnel dividit afegeix rutes més específiques i deixa la ruta per defecte tal com és. Tots dos són normals, i el segon és la raó per la qual esborrar la ruta per defecte és una mala primera prova en una màquina que administreu en remot. Eliminar-la és també la manera més ràpida de perdre la sessió que feu servir per arreglar el problema.

Llegiu la taula en lloc de suposar. Una ruta més específica o una regla de política poden enviar trànsit al túnel mentre la ruta per defecte encara apunta a la interfície física, cosa que sembla contradictòria fins que llegiu tota la taula. Aquesta combinació és normal per al túnel dividit i confusa per a qui espera que una sola línia descrigui el disseny. Cerqueu la ruta que coincideix amb la vostra destinació real, no la que coincideix amb el diagrama.

El resolutor canvia de mans

El DNS és el tercer canvi i el que més probablement es gestiona en un lloc on no heu mirat. En un escriptori, NetworkManager pot enviar la configuració del resolutor per connexió. En un sistema que fa servir systemd-resolved, la configuració s'aplica per enllaç i /etc/resolv.conf pot ser un stub o un enllaç simbòlic en lloc d'un fitxer que hàgiu d'editar.

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

Si una edició manual del fitxer del resolutor desapareix després de reconnectar, això és el senyal per trobar el component que el manté i canviar el perfil en lloc d'això. Editar el fitxer generat és un canvi que una reconnexió esborrarà.

Els noms privats normalment necessiten el resolutor intern i els dominis de cerca que va proporcionar l'operador. Substituir-lo per un resolutor públic pot trencar precisament el recurs per al qual existeix la VPN, i el símptoma sembla una fallada d'encaminament i no de DNS. Proveu el nom i l'adreça per separat, perquè que un funcioni i l'altre falli us diu exactament on mirar. Aquesta única comparació estalvia una hora de depuració de rutes.

Un gestor per connexió

El format del perfil decideix quin programa el pot fer servir. Un perfil d'OpenVPN necessita OpenVPN o un connector compatible, i una configuració de WireGuard té el seu propi format amb claus de par i prefixos permesos. Un diàleg d'importació no converteix un en l'altre, digui el que digui l'extensió del fitxer.

Trieu un gestor i deixeu que posseeixi la connexió. Aixecar el mateix túnel amb dues eines fa ambigus la taula de rutes i el comportament de reconnexió, i el segon que arrenca normalment guanya de maneres difícils de reproduir.

Instal·leu els paquets que admet la vostra distribució i obteniu el perfil de l'operador. Tracteu-lo com una credencial, perquè normalment conté una clau privada o material equivalent, i deseu-lo on viuen la resta dels vostres secrets. Un perfil deixat en una carpeta de baixades és una clau deixada damunt d'un escriptori.

Què cal comprovar quan està aixecat però no funciona

Amb la interfície aixecada i el client informant d'èxit, aneu cap enfora: la taula de rutes selecciona el túnel per a la destinació, el resolutor respon pel nom privat i el costat remot té un camí de tornada. Cadascun té una ordre separada i un propietari separat.

nmcli connection show --active
nmcli device status
wg show

La referència d'nmcli documenta les ordres d'estat i de connexió si us cal el conjunt complet. El que importa aquí és la distinció entre un perfil actiu i un dispositiu que transporta trànsit, perquè tots dos poden discrepar.

Reconnecteu una vegada amb el mateix gestor abans de donar la configuració per acabada, i comproveu que el DNS encara funciona després d'una desconnexió. Una configuració que només funciona fins al primer canvi de xarxa no està acabada, simplement funciona en aquest moment.