OpenVPN-DNS står tilbage efter SIGKILL: undersøg ejeren først

DNS holder op med at slå op, efter at en OpenVPN-klient er dræbt, og den første indskydelse er at omskrive /etc/resolv.conf. Den ændring kan ødelægge en fungerende resolver, mens den egentlige forældede tilstand ligger et andet sted. Spørgsmålet, der skal afgøres først, er, hvem der ejer de DNS-indstillinger, tunnelen installerede, og om den afslutning, der sprang oprydningen over, faktisk betød noget.

Tre forhold afgør reparationen: signalet, der afsluttede processen, den resolverkomponent, der modtog indstillingerne, og om tunnellinket stadig findes. Besvar dem i den rækkefølge, og rettelsen følger normalt uden at røre en global fil.

Afgør, hvilken slags afslutning der skete

I Community-udgaven af OpenVPN er både SIGINT og SIGTERM anmodninger om en kontrolleret afslutning. SIGKILL kan ikke fanges: det kan hverken blokeres eller håndteres, så ingen nedlukningsrutine får en chance for at køre. Et normalt Ctrl+C i en terminal i forgrunden udsender SIGINT, mens en supervisor, der giver op med at vente, normalt eskalerer til SIGKILL. Forskellen betyder noget, fordi kun det andet tilfælde garanterer, at hookene blev sprunget over.

Det ændrer ikke, hvilket signal Ctrl+C sender, at køre inde i screen eller tmux. Kontroller, hvad processen faktisk modtog, i stedet for hvad terminalen normalt gør.

Når en tjeneste eller forbindelsesmanager kører tunnelen, stop da den ene forbindelse via dens ejer i stedet for at dræbe pid'en. En manager kan starte processen igen og efterlade dig med en ny tunnel og en forvirrende resolvertilstand. En selvstændig proces har kun brug for en almindelig afslutningsanmodning, for at oprydningen kører.

Afgør, hvem der ejer resolveren

systemd-resolved, et script i resolvconf-stil og en simpel filomskrivning er tre forskellige ejere. Den første holder per-link-indstillinger i hukommelsen og dropper dem, når grænsefladen forsvinder. Den anden holder poster, der består, indtil noget fjerner dem. Den tredje skriver en fil og overlader gendannelsen til den, der skrev den.

Find ejeren, før du vælger en reparationskommando. Det samme symptom har tre forskellige rigtige svar afhængigt af, hvilken der er i brug.

Et NetworkManager-styret VPN kan allerede eje resolverændringer. Tilføjer du endnu en hjælper ovenpå, får du to ejere, der konkurrerer om det samme link, og taberens tilstand dukker op igen ved næste genopkobling. Hvis en manager har ansvaret, så ret indstillingen i manageren i stedet for i et script.

Hvad down-hooket kan og ikke kan

Scriptet down kører én gang, efter at TUN/TAP-enheden er lukket. Tilføjer du down-pre vendes den rækkefølge, og scriptet kører, mens enheden stadig findes, hvilket hjælpere, der har brug for det levende link, kræver.

Ingen af direktiverne får et hook til at køre efter SIGKILL. Privilegier gendannes heller ikke af down-pre: hvis dæmonen skifter til user eller group eller går ind i et chroot, kører hooket med den adgang, det efterlader. Et kaldt hook kan stadig mislykkes med at opdatere resolveren. OpenVPN-referenceværket dækker signalerne og callback-livscyklussen.

Kontroller hookets egen fejl ved siden af processens afslutningsstatus. Manglende oprydning og mislykket oprydning ser ens ud i resolveren og forskelligt ud i loggene.

Kontroller den tilstand, der faktisk er tilbage

På et system med systemd-resolved viser resolvectl status, hvilket link der stadig bærer VPN'ens DNS-servere eller routingdomæner. Det link kan tilhøre en forbindelse, der er væk, eller en anden tunnel, der stadig er oppe.

En grænseflade, der forsvinder, tager sin per-link-konfiguration med sig, så et sprunget hook kan eksistere sammen med ren DNS. Hvis linket stadig er registreret og udelukkende ejes af den stoppede forbindelse, bør den ejende manager fjerne det. Hvis et ældre script omskrev en global resolverfil, så led efter det scripts dokumenterede gendannelsestrin i stedet.

Gendan uden at stjæle et andet link

Når per-link-indstillinger er dit ansvar at styre, resolvectl revert tager linknavnet og rydder runtime-DNS-konfigurationen for den grænseflade. Det er en runtime-handling og ikke en profilændring, så den vedvarende forbindelseskonfiguration forbliver urørt. Navngiver du det forkerte link, rydder du DNS for en fungerende tunnel, og derfor kommer navnet fra statusoutputtet.

Bekræft, at /etc/resolv.conf er et administreret symbolsk link, før du redigerer det, og stop derefter klienten normalt én gang mere og se på DNS igen. Hvis den anden stop rydder op, var det tidligere problem den tvungne afslutning og ikke konfigurationen.