client-config-dir ignoreras efter att OpenVPN blev en tjänst

Din tunnel kommer upp och klienten ansluter, men den fasta adressen och de pushade rutter du definierade för den enda användaren saknas. Loggen säger inte “file not found”, och det är just detta som skickar folk att generera om certifikat. I de flesta av dessa fall körs demonen från en annan katalog än det skal du testade i, och client-config-dir löstes aldrig som du antog. Rättelsen är en sökvägskorrigering, inte en återställning av inloggningsuppgifter.

Läs unit-filen innan du rör konfigurationen

Börja med processen som faktiskt körs, inte filen du redigerade. Fråga systemd om körraden, arbetskatalogen och kontot den byter till. De tre svaren förklarar de flesta felen i den här klassen:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

En tom WorkingDirectory betyder att unit-filen startar i /, så en relativ client-config-dir ccd letas efter i /ccd. Den katalogen finns nästan aldrig, och demonen ser inte frånvaron som fatal.

Jämför med den interaktiva starten du använde under testningen, där skalets aktuella katalog troligen var konfigurationskatalogen. Samma fil, samma nyckelord, två olika resultat.

Vad en relativ sökväg löses mot

Nyckelordet löses mot processens arbetskatalog i det ögonblick alternativet används. Det betyder inte “bredvid konfigurationsfilen jag skickade med --config”. OpenVPN läser gärna en konfiguration från en absolut sökväg och löser ändå relativa värden någon annanstans, och det är precis fällan här. Handboken för OpenVPN 2.6 anger regeln under --client-config-dir och igen under --cd.

Nyckelordet cd ändrar den kontexten innan andra filer läses, så en unit som sätter cd /etc/openvpn/server och därefter client-config-dir ccd löses till /etc/openvpn/server/ccd. Om du lägger till cd, kontrollera direktivens ordning och kom ihåg att det påverkar varje annan relativ referens i samma fil.

Gå sökvägen som demonens konto

En sökväg kan vara korrekt och ändå oläslig. Efter privilegiefallet är demonen inte längre root, så varje överordnad katalog behöver sökrätt för det kontot, och klientfilen själv behöver läsrätt. En enda saknad körningsbit på en överordnad katalog räcker för att dölja filen, och felet visar sig bara som en klient som stilla får standardpoolen.

namei skriver ut behörigheten för varje komponent i ordning, vilket är snabbare än att kontrollera katalogerna en i taget:

namei -l /etc/openvpn/server/ccd/client1

Testa sedan läsningen som tjänstekontot i stället för som dig själv:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Om unit-filen använder chroot, måste katalogen finnas inne i fängelset, och sökvägen i konfigurationen tolkas efter att chroot har tillämpats. En fil som ligger på värden utanför fängelset är osynlig inifrån.

Bekräfta uppslaget i stället för att gissa

Höj loggnivån för en omstart och läs vad servern säger om klientspecifika alternativ. Vid verb 4 rapporterar demonen den konfiguration per klient som den importerade, så en saknad rad är direkta bevis på att ingen fil lästes för den anslutningen.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Kör det i förgrunden på en ledig port och anslut en klient. Det tar bort systemd helt från bilden: om överstyrningarna dyker upp här och inte under tjänsten, är skillnaden unit-filens kontext, inte filen.

Bestäm vad som ska hända när ingen fil matchar. Utan ccd-exclusive tas klienten in med bara de globala poolinställningarna, och det är det tysta felet som beskrivs ovan. Med den blir en saknad fil en avvisad anslutning, och den avvisningen är lättare att lägga märke till men svårare att felsöka under last.

Rätta, starta om, verifiera

Gör katalogen absolut i konfigurationen och håll den så. Relativa sökvägar är bara säkra när unit-filen fäster arbetskatalogen, och att fästa den är en extra rörlig del som någon tar bort senare.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Starta om instansen, anslut en känd klient igen och läs adressen den fick tillsammans med rutterna som pushades till den. Om adressen stämmer med raden ifconfig-push i den klientens fil, fungerade uppslaget. Om klienten fortfarande hamnar i den allmänna poolen, gå tillbaka till antalet loggrader: noll importer betyder att sökvägen eller identiteten är fel, en import med fel innehåll betyder att du redigerar en annan fil än den demonen läser.

Rulla tillbaka genom att återställa föregående unit och konfiguration tillsammans och starta sedan om. Certifikat behöver inte utfärdas om för något av detta, och att behandla ett katalogproblem som ett inloggningsproblem är hur en femminutersrättelse blir ett underhållsfönster.