DNS d'OpenVPN que queda després de SIGKILL: comproveu primer el propietari

El DNS deixa de resoldre després que es mati un client d'OpenVPN, i el primer instint és reescriure /etc/resolv.conf. Aquesta edició pot trencar un resolutor que funciona mentre l'estat real obsolet és en un altre lloc. La pregunta que cal resoldre primer és qui posseeix la configuració de DNS que va instal·lar el túnel, i si la sortida que va saltar la neteja realment va importar.

Tres condicions decideixen la reparació: el senyal que va acabar el procés, el component del resolutor que va rebre la configuració i si l'enllaç del túnel encara existeix. Responeu-les en aquest ordre i la solució normalment arriba sense tocar cap fitxer global.

Decidiu quin tipus de sortida ha passat

A l'edició Community d'OpenVPN, tant SIGINT com SIGTERM són peticions de sortida ordenada. SIGKILL no es pot capturar: no es pot bloquejar ni gestionar, així que cap rutina d'apagada té l'oportunitat d'executar-se. Un Ctrl+C normal en un terminal en primer pla genera SIGINT, mentre que un supervisor que deixa d'esperar normalment escala a SIGKILL. La diferència importa perquè només el segon cas garanteix que es van saltar els ganxos.

Executar-ho dins de screen o tmux no canvia quin senyal envia Ctrl+C. Comproveu què va rebre realment el procés, no què fa normalment el terminal.

Quan un servei o un gestor de connexions executa el túnel, atureu aquesta connexió concreta a través del seu propietari en lloc de matar el pid. Un gestor pot tornar a aixecar el procés, deixant-vos un túnel nou i un estat del resolutor confús. Un procés autònom només necessita una petició de terminació normal perquè s'executi la neteja.

Decidiu qui posseeix el resolutor

systemd-resolved, un script a l'estil de resolvconf i una simple reescriptura de fitxer són tres propietaris diferents. El primer manté la configuració per enllaç a la memòria i la descarta quan la interfície desapareix. El segon manté registres que persisteixen fins que alguna cosa els elimina. El tercer escriu un fitxer i deixa la restauració a qui l'hagi escrit.

Identifiqueu el propietari abans de triar una ordre de reparació. El mateix símptoma té tres respostes correctes diferents segons quin estigui en ús.

Una VPN gestionada per NetworkManager pot posseir ja els canvis del resolutor. Afegir-hi un segon auxiliar crea dos propietaris que competeixen pel mateix enllaç, i l'estat del perdedor reapareix a la següent reconnexió. Si un gestor té el comandament, correu la configuració al gestor i no en un script.

Què pot fer el ganxo down i què no

El script down s'executa un cop el dispositiu TUN/TAP s'ha tancat. Afegir down-pre inverteix aquest ordre i executa el script mentre el dispositiu encara existeix, cosa que requereixen els auxiliars que necessiten l'enllaç actiu.

Cap de les dues directives fa que un ganxo s'executi després de SIGKILL. Els privilegis tampoc no es restableixen amb down-pre: si el dimoni baixa a user o group o entra en un chroot, el ganxo s'executa amb l'accés que això li deixi. Un ganxo invocat encara pot fallar en actualitzar el resolutor. La referència d'OpenVPN cobreix els senyals i el cicle de vida de la retornada.

Comproveu l'error propi del ganxo al costat de l'estat de sortida del procés. Una neteja absent i una neteja fallida es veuen igual al resolutor i diferent als registres.

Comproveu l'estat que realment queda

En un sistema que utilitza systemd-resolved, resolvectl status mostra quin enllaç encara porta els servidors DNS de la VPN o els dominis d'encaminament. Aquest enllaç pot pertànyer a una connexió que ja no hi és o a un altre túnel que encara està aixecat.

Una interfície que desapareix s'emporta la seva configuració per enllaç, així que un ganxo saltat pot coexistir amb un DNS net. Si l'enllaç encara està registrat i el posseeix exclusivament la connexió aturada, el gestor propietari hauria d'eliminar-lo. Si un script més antic va reescriure un fitxer global del resolutor, busqueu en lloc d'això el pas de restauració documentat d'aquest script.

Recupereu-vos sense robar un altre enllaç

Quan la configuració per enllaç és vostra de gestionar, resolvectl revert agafa el nom de l'enllaç i esborra la configuració DNS d'execució per a aquesta interfície. És una acció d'execució i no una edició de perfil, així que la configuració persistent de la connexió queda intacta. Nomeneu l'enllaç equivocat i esborrareu el DNS d'un túnel que funciona: per això el nom surt de la sortida de l'estat.

Confirmeu que /etc/resolv.conf és un enllaç simbòlic gestionat abans d'editar-lo, després atureu el client normalment una vegada més i torneu a mirar el DNS. Si la segona aturada neteja, el problema anterior era la sortida forçada i no la configuració.