client-config-dir wordt genegeerd sinds OpenVPN een dienst werd

Je tunnel komt op en de client verbindt, maar het vaste adres en de gepushte routes die je voor die ene gebruiker hebt gedefinieerd ontbreken. In het log staat niets over “file not found”, en juist dat stuurt mensen eropuit om certificaten opnieuw te genereren. In de meeste van deze gevallen draait de daemon vanuit een andere map dan de shell waarin je testte, en client-config-dir is nooit opgelost zoals je aannam. De oplossing is een padcorrectie, geen reset van inloggegevens.

Lees de unit voordat je de configuratie aanraakt

Begin bij het proces dat echt draait, niet bij het bestand dat je hebt bewerkt. Vraag systemd naar de uitvoeringsregel, de werkmap en het account waarnaar het overgaat. Die drie antwoorden verklaren de meeste storingen in deze klasse:

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

Een lege WorkingDirectory betekent dat de unit start in /, dus een relatief client-config-dir ccd wordt gezocht in /ccd. Die map bestaat bijna nooit, en de daemon beschouwt het ontbreken ervan niet als fataal.

Vergelijk dat met de interactieve start die je tijdens het testen gebruikte, waar de huidige map van je shell waarschijnlijk de configuratiemap was. Hetzelfde bestand, dezelfde trefwoorden, twee verschillende uitkomsten.

Waartegen een relatief pad wordt opgelost

Het trefwoord wordt opgelost tegen de werkmap van het proces op het moment dat de optie wordt gebruikt. Het betekent niet “naast het configuratiebestand dat ik met --config heb meegegeven”. OpenVPN leest met plezier een configuratie vanaf een absoluut pad en lost relatieve waarden toch elders op, en dat is precies de val hier. De OpenVPN 2.6-handleiding noemt de regel onder --client-config-dir en nog eens onder --cd.

Het trefwoord cd verandert die context voordat andere bestanden worden gelezen, dus een unit die cd /etc/openvpn/server en daarna client-config-dir ccd instelt, wordt opgelost naar /etc/openvpn/server/ccd. Als je cd toevoegt, controleer dan de volgorde van de richtlijnen en bedenk dat het elke andere relatieve verwijzing in hetzelfde bestand beïnvloedt.

Loop het pad na als het account van de daemon

Een pad kan correct zijn en toch onleesbaar. Na het afstaan van privileges is de daemon geen root meer, dus elke bovenliggende map heeft zoekrecht nodig voor dat account, en het clientbestand zelf leesrecht. Eén ontbrekend uitvoeringsbit op een bovenliggende map is genoeg om het bestand te verbergen, en de fout openbaart zich alleen als een client die stilletjes de standaardpool krijgt.

namei drukt de rechten van elk onderdeel op volgorde af, wat sneller is dan de mappen één voor één controleren:

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

Test daarna het lezen als het dienstaccount in plaats van als jezelf:

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

Als de unit chroot gebruikt, moet de map binnen de gevangenis bestaan, en het pad in de configuratie wordt geïnterpreteerd nadat chroot is toegepast. Een bestand dat op de host buiten de gevangenis staat, is van binnenuit onzichtbaar.

Bevestig de opzoeking in plaats van te gissen

Verhoog het logniveau voor één herstart en lees wat de server zegt over clientspecifieke opties. Bij verb 4 meldt de daemon de configuratie per client die hij heeft geïmporteerd, dus een ontbrekende regel is direct bewijs dat er voor die verbinding geen bestand is gelezen.

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

Draai dat op de voorgrond op een extra poort en verbind één client. Dat haalt systemd volledig uit het beeld: als de overschrijvingen hier verschijnen en niet onder de dienst, zit het verschil in de context van de unit, niet in het bestand.

Bepaal wat er moet gebeuren als geen enkel bestand past. Zonder ccd-exclusive wordt de client alleen met de globale poolinstellingen toegelaten, en dat is de stille fout van hierboven. Met de optie wordt een ontbrekend bestand een geweigerde verbinding, en die weigering is makkelijker op te merken maar lastiger te debuggen onder belasting.

Corrigeer, herstart, verifieer

Maak de map absoluut in de configuratie en houd die zo. Relatieve paden zijn alleen veilig als de unit de werkmap vastzet, en dat vastzetten is een extra bewegend onderdeel dat iemand later weghaalt.

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

Herstart de instantie, verbind een bekende client opnieuw en lees het adres dat hij kreeg samen met de routes die naar hem zijn gepusht. Als het adres overeenkomt met de regel ifconfig-push in het bestand van die client, dan werkte de opzoeking. Als de client nog steeds in de algemene pool belandt, ga terug naar het aantal logregels: nul imports betekent dat het pad of de identiteit onjuist is, één import met verkeerde inhoud betekent dat je een ander bestand bewerkt dan de daemon leest.

Draai terug door de vorige unit en configuratie samen te herstellen en herstart daarna. Certificaten hoeven hier niet voor opnieuw te worden uitgegeven, en een mapprobleem als inloggegevensprobleem behandelen is hoe een correctie van vijf minuten een onderhoudsvenster wordt.