Je .ovpn-bestand kan code uitvoeren, niet alleen verkeer routeren

De meeste mensen lezen een .ovpn-bestand zoals ze de instellingenpagina van een router lezen: adressen, routes, een lijst met cijfers. Het deel dat code uitvoert, staat dicht bij de onderkant, naast richtlijnen die op loodgieterswerk lijken, en het draait met welke rechten de client al heeft. Dat is de opening die een slordig of kwaadwillig profiel misbruikt, en het is ook de opening die een nuttige DNS-hulp drie weken later in een supportprobleem verandert. De gebeurtenisrichtlijn, het beveiligingsniveau en het eigenaarschap van het bestand bepalen wat er kan gebeuren; de inhoud van het script bepaalt wat er werkelijk gebeurt. Lees alle vier voordat je verbindt.

Een profiel dat een hulp start, is een programma, geen instellingenbestand

Richtlijnen zoals route en dhcp-option beschrijven toestand die de client moet opbouwen, en de client behandelt ze als data. Een up-script is anders: de client start het als een proces en geeft het een omgeving vol verbindingsdetails, dus alles wat de auteur schreef, draait met de rechten van jouw account. Op een laptop waar de gebruiker beheerder is, is dat een brede deur voor een bestand dat als bijlage of als plaksel uit een forumbijdrage binnenkwam. Het onderscheid is niet stilistisch, het is het verschil tussen configuratie en code.

De mythe die we mogen laten varen, is dat een profiel alleen verkeer kan omleiden. Een hulp die ip route add uitvoert en een die curl tegen een externe host uitvoert, zijn hetzelfde mechanisme, en het profiel ziet er van buiten identiek uit. Niets in het uiterlijk van het bestand vertelt welke je hebt, daarom moet de controle tot het script zelf reiken.

Wat de uitvoering werkelijk bepaalt, en hoe de regels die het toestaan eruitzien

Drie dingen sturen een hulp: de gebeurtenisrichtlijn die hem benoemt, het script-security-niveau dat hem toestaat, en de eigen implementatie van het clientplatform. Een profiel kan een hook aanvragen en toch niets zien gebeuren, omdat een mobiele client of een uitgeklede desktopbuild die gebeurtenis misschien helemaal niet implementeert. Evenzo zegt een profiel dat meer toestemming vraagt dan zijn functie nodig heeft, iets over zijn herkomst. Een toestemmingsniveau is een vermogen, geen goedkeuring. De regels die het toestaan zien er zo uit, met een pad dat voor het jouwe staat.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Niveau 0 weigert externe programma's en niveau 1, de standaard, staat alleen de ingebouwde uitvoerbare bestanden van de client toe, dus een hook heeft 2 of hoger nodig; niveau 3 bestaat vooral voor het doorgeven van oude wachtwoorden en kun je beter vermijden. Een profiel dat met een hook wordt geleverd, heeft zowel de richtlijn als dat niveau nodig, daarom verdient één regel bij de onderkant van het bestand dezelfde controle als het certificaatblok. De OpenVPN-handleiding somt de toestemmingsniveaus op, en de formulering ervan is het lezen waard naast wat het profiel werkelijk vraagt.

Eigendom, pad en waarmee de hulp wordt gevoed

Een profiel dat je vertrouwt maar dat naar een script wijst dat een ander account kan herschrijven, is geen betrouwbare regeling, want de controle van gisteren beschrijft niet meer wat vandaag draait. Controleer de eigenaar en modus van de hulp, en controleer dat het ingestelde pad naar het bestand leidt dat je hebt onderzocht en niet naar een naam die iets anders kan overschaduwen. Argumenten en omgeving verdienen dezelfde blik: de client geeft verbindingsdetails aan de hook, en een hulp die zijn hele omgeving logt, schrijft misschien inloggegevens in een supportticket. Geef de voorkeur aan een gedocumenteerde integratie van de operator of het platform boven een DNS-script dat uit een ongerelateerde bijdrage is gekopieerd, want twee resolverbeheerders die om hetzelfde bestand vechten, veroorzaken een storing die op een kapotte VPN lijkt.

Wanneer je een falende hook meldt, redigeer dan de omgeving voordat je die ergens plakt. De dump die je helpt bij het debuggen, kan ook het token dragen dat je authenticeert.

Opruimfouten verschijnen nadat de tunnel weg is

Een up-hulp voegt routes en resolverinstellingen toe, en de down-hulp hoort ze weer weg te halen. Als de down-hook ontbreekt, stil faalt of nooit draait omdat de client is gedood, overleven de resten de sessie. Verkeer neemt dan een pad dat niemand had gepland en namen worden opgelost via een resolver die verwijderd had moeten zijn, terwijl de tunnel zelf gezond lijkt. Die symptomen komen na het verbreken, daarom krijgt het netwerk de schuld in plaats van het profiel.

Test het afbreken als een eigen stap: breng de tunnel op, noteer de routes en de resolver, laat hem vallen, en bevestig dan dat beide weg zijn. Een profiel dat schoon verbindt, kan toch toestand achterlaten, en een nul-exitcode van de hulp bewijst niet dat de resolver terechtkwam waar jij denkt.

De hulp beoordelen en een uitweg houden

Lees het script van begin tot eind en zoek naar drie dingen: opdrachten die rechten nodig hebben, hardgecodeerde paden die misschien niet op je systeem bestaan, en elke netwerkaanroep die het doet. Kijk dan hoe het faalt, want een hulp die fouten inslikt, verandert een configuratiefout in een raadsel. Als je niet in één zin kunt zeggen wat het script doet en wie het kan wijzigen, ben je niet klaar om het in te schakelen. Een profiel dat meer rechten vraagt dan die zin vereist, is het signaal om te stoppen.

Bewaar het laatst werkende profiel en de hulp waarnaar het verwees in beveiligde opslag, met beide versies genoteerd, zodat een terugdraai een kopie is en geen herbouw op het slechtst denkbare moment. Als de hulp alleen bestaat voor een distributie of clientversie die hem niet meer nodig heeft, trek hem dan terug in de configuratie die de instelling bezit in plaats van rechten te verhogen tot de fouten stoppen. Dat is de uitweg: minder bewegende delen, niet meer toestemming.