Que ocorre realmente cando inicias unha VPN en Linux
Iniciar unha VPN en Linux crea unha interface, instala rutas e cambia o resolutor. Saber que servizo posúe cada paso explica a maioría dos fallos de configuración.
Prema conectar e tres cousas cambian nunha máquina Linux: aparece unha interface, instálanse rutas e o resolutor comeza a responder doutro xeito. A maioría dos fallos de configuración veñen de que unha desas tres ocorra sen as outras, ou de que dous programas non se poñan de acordo sobre quen as posúe. Entender a secuencia explica o fallo máis rápido que ler a saída do rexistro dun cliente.
Unha interface aparece antes de que nada funcione
Un cliente de túnel abre unha interface virtual e entrégalle paquetes. Un dispositivo TUN transporta paquetes IP, que é o que necesita unha VPN encamiñada; un dispositivo TAP transporta tramas Ethernet, que é o que necesita un deseño ponte. O módulo do núcleo fornece o dispositivo, e o cliente posúeo mentres dura a sesión.
Que a interface suba non é o mesmo que o túnel funcione. Pode existir cun enderezo mentres o par non é accesible, e por iso a lista de interfaces é a primeira comprobación e non a última. Un dispositivo que se declara levantado describe a visión do núcleo dunha ligazón virtual, non a disposición do par a responder.
Deixe o modo de interface fornecido tal como está. Cambiar un perfil TUN a TAP non converte un servidor encamiñado nun de ponte, e normalmente produce unha conexión que se establece e non reenvía nada.
As rutas instálaas quen posúe o túnel
As rutas son o segundo cambio, e a súa propiedade importa máis que o seu contido. Un perfil de NetworkManager, unha unidade de systemd e un cliente executado a man poden instalar rutas, e que dous o fagan á vez produce unha táboa que ninguén poderá explicar despois.
ip -br addr show ip route show ip -6 route show
Un perfil de túnel completo substitúe a ruta por defecto; un perfil de túnel dividido engade rutas máis específicas e deixa a ruta por defecto tal como está. Ambas son normais, e a segunda é a razón pola que borrar a ruta por defecto é unha mala primeira proba nunha máquina que administra en remoto. Eliminala é tamén a forma máis rápida de perder a sesión que usa para arranxar o problema.
Lea a táboa en lugar de supoñer. Unha ruta máis específica ou unha regra de política poden enviar tráfico ao túnel mentres a ruta por defecto segue apuntando á interface física, o que parece contradictorio ata que le toda a táboa. Esa combinación é normal para o túnel dividido e confusa para quen espera que unha soa liña describa o deseño. Busque a ruta que coincide co seu destino real, non a que coincide co diagrama.
O resolutor cambia de mans
O DNS é o terceiro cambio e o que máis probablemente se xestiona nun lugar onde non mirou. Nun escritorio, NetworkManager pode enviar a configuración do resolutor por conexión. Nun sistema que usa systemd-resolved, a configuración aplícase por ligazón e /etc/resolv.conf pode ser un stub ou unha ligazón simbólica en lugar dun ficheiro que deba editar.
resolvectl status readlink -f /etc/resolv.conf cat /etc/resolv.conf
Se unha edición manual do ficheiro do resolutor desaparece tras unha reconexión, esa é a señal para atopar o compoñente que o mantén e cambiar o perfil no seu lugar. Editar o ficheiro xerado é un cambio que unha reconexión borrará.
Os nomes privados normalmente necesitan o resolutor interno e os dominios de busca que forneceu o operador. Substituílo por un resolutor público pode romper xusto o recurso para o que existe a VPN, e o síntoma parece un fallo de encamiñamento e non de DNS. Probe o nome e o enderezo por separado, porque que un funcione e o outro falle dille exactamente onde mirar. Esa única comparación aforra unha hora de depuración de rutas.
Un xestor por conexión
O formato do perfil decide que programa pode usalo. Un perfil de OpenVPN necesita OpenVPN ou un complemento compatible, e unha configuración de WireGuard ten o seu propio formato con claves de par e prefixos permitidos. Un diálogo de importación non converte un no outro, diga o que diga a extensión do ficheiro.
Escolla un xestor e deixe que sexa dono da conexión. Levantar o mesmo túnel con dúas ferramentas fai ambiguos a táboa de rutas e o comportamento de reconexión, e o segundo que arrinca adoita gañar de formas difíciles de reproducir.
Instale os paquetes que admite a súa distribución e obteña o perfil do operador. Tráteo como unha credencial, porque normalmente contén unha clave privada ou material equivalente, e gárdeo onde viven o resto dos seus segredos. Un perfil deixado nun cartafol de descargas é unha clave deixada sobre un escritorio.
Que comprobar cando está levantado pero non funciona
Coa interface levantada e o cliente informando de éxito, traballe cara a fóra: a táboa de rutas selecciona o túnel para o destino, o resolutor responde polo nome privado e o lado remoto ten un camiño de volta. Cada un ten un comando separado e un propietario separado.
nmcli connection show --active nmcli device status wg show
A referencia de nmcli documenta os comandos de estado e conexión se precisa o conxunto completo. O que importa aquí é a distinción entre un perfil activo e un dispositivo que transporta tráfico, porque ambos poden discrepar.
Reconecte unha vez co mesmo xestor antes de dar a configuración por rematada, e comprobe que o DNS segue funcionando tras unha desconexión. Unha configuración que só funciona ata o primeiro cambio de rede non está rematada, simplemente funciona neste momento.