Hvad persist-tun og persist-key egentlig overlever i OpenVPN

Stop af tjenesten fjerner grænsefladen, selv med persist-tun sat. Det er indstillingen, der virker som dokumenteret, ikke en fejl. Indstillingen beskriver én genstartsvej inde i en kørende proces, og systemctl stop er ikke den vej.

Læs de to navne sammen, og designet bliver klart. Den ene beholder en deskriptor, den anden beholder nøglemateriale, og begge findes på grund af det, der sker, efter privilegierne slippes.

De to ressourcer og den genstart, de hører til

OpenVPN signalerer sin egen genstart i to almindelige situationer. Et eksplicit SIGUSR1 gør det, og et ping-restart udløst af en død peer gør det samme. Begge holder processen i live og kører forbindelsesopsætningen igen, og det er her, indstillingerne gør deres plads fortjent.

Kun rækken med blød genstart er det, disse to indstillinger ændrer, og det arbejde, de springer over, er den dyre del på et travlt link. Genåbning af en enhed river de adresser og ruter ned, der hænger på den, og genopbygningen kan tabe pakker, der var undervejs, da genstarten begyndte. Et stop ødelægger de samme objekter uden nogen mulighed for at bevare dem.

Hvorfor indstillingerne overhovedet findes

En hærdet OpenVPN-server starter normalt som root, åbner sine nøgler og sin enhed og skifter derefter til en bruger uden privilegier. Efter det skift er nogle handlinger simpelthen væk. Læsning af en nøglefil med tilstand 0600, oprettelse af en netværksgrænseflade eller ændring af ruter kan alt sammen blive afvist.

Uden persist-indstillingerne ville en peer, der tier længe nok til at udløse ping-restart, tvinge præcis disse handlinger. Genforbindelsen ville fejle, selv om intet i konfigurationen var ændret. Processen ville se ud, som om den døde uden grund, og loggen ville vise en tilladelsesfejl i stedet for en netværksfejl.

Med dem genbruger den bløde genstart det, som den privilegerede fase allerede har fået. Der er ingen magi, og processen overlever ikke noget. Anskaffelse af ressourcer er blot udskudt.

Læs den første fejl, ikke den sidste

Når en genstart fejler, skal du læse den første fejl i stedet for den sidste. En beskyttet nøgle, en auth-fil, en grænseflade-ioctl og et eksternt hook er fire forskellige ressourcer. At beholde én siger intet om adgangen til de andre. Et hook, der kalder et firewall-værktøj, har stadig brug for de privilegier, som værktøjet kræver.

Hooks har deres egen kontakt. OpenVPN-manualen parrer persist-indstillingerne med up-restart, som afgør, om up- og down-scripts kører igen efter en genstart. En grænseflade, der blev oppe, fortæller dig derfor intet om, hvorvidt din resolver-integration blev opdateret.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

Det par kommandoer skiller de to fejltilstande på sekunder. En grænseflade, der er til stede med manglende ruter, er et hook- eller ruteproblem. En grænseflade, der forsvandt, betyder, at processen faktisk sluttede.

En bevaret grænseflade er ikke en kill switch

Hvis kravet er, at trafik aldrig må forlade tunnelen, leverer en bevaret enhed det ikke. Ruter til den anden adressefamilie, en anden standardrute og det tilfælde, hvor processen helt afsluttes, ligger alle uden for indstillingens rækkevidde.

Behandl de to krav hver for sig. At beholde tunnelobjektet gennem genforbindelser er en bekvemmelighed for daemonen. Blokering af udgang, når tunnelen er nede, er en firewallpolitik med sine egne regler og sin egen test. Sammenblanding giver en konfiguration, der ser defensiv ud og opfører sig som genforbindelse efter bedste evne.

Navngiv hændelsen, før du diagnosticerer den. En blød genstart, et mislykket forbindelsesforsøg og et stop af tjenesten er tre hændelser med tre adfærdsmønstre, og kun den første er det, disse indstillinger beskriver.