Clienthook of serverhook? Waar een OpenVPN-script draait

De taak is duidelijk: wanneer een laptop verbindt, moet er iets op de laptop veranderen. De configuratie die wordt bewerkt, hoort bij de server, en daar breekt de aanname. Een pad in een serverbestand wijst een bestand op die server aan, en geen enkele hoeveelheid push verandert welk proces het uitvoert. Kiezen tussen de twee hooks is vooral bepalen welke machine het werk bezit en de grenzen accepteren die daaruit volgen.

Twee machines, twee vragen die eerst beantwoord moeten worden

Vraag waar de toestandsverandering moet plaatsvinden, en vraag dan welke gebeurtenis daarbij hoort. Als de verandering een autorisatie per gebruiker of een configuratiebeslissing per client is, hoort die waar de gebruikersmap bekend is: de server. Als de verandering een route is, een resolverinstelling of een lokale helper op een eindpunt, hoort die op het eindpunt, en alleen het eindpunt kan dat doen.

Die twee vragen in omgekeerde volgorde beantwoorden is hoe mensen uiteindelijk een batchbestand naar een Windows-laptop proberen te pushen. De server weet wie er verbond; de laptop weet hoe zijn eigen netwerkstack eruitziet. Geen van beide heeft de informatie van de ander, en de poging mislukt meestal stil in plaats van met een duidelijke fout.

Vóór beide is een derde vraag de moeite waard: biedt het platform de hook die je wilt eigenlijk aan? Een apparaat dat zijn eigen configuratie genereert, biedt mogelijk niet dezelfde gebeurtenisnamen, en een desktopclient die een .ovpn-bestand importeert, is niet noodzakelijk dezelfde client waarvoor het bestand is geschreven. Het platform eerst bevestigen bespaart je ontwerpen rond een hook die daar niet bestaat. Het vertelt je ook welke documentatie echt van toepassing is op de machine voor je.

De optie aan de serverkant: een gebeurtenis per verbinding

Een client-connect-script draait in de procescontext van de server wanneer een geauthenticeerde client verbindt, en het ontvangt gedocumenteerde verbindingsgegevens zoals de common name en het toegewezen adres. Het is de juiste plek om een configuratiefragment per client te schrijven, een beleidsbeslissing af te dwingen of toestand vast te leggen die de server bezit.

Het onderscheid dat mensen missen, is het verschil tussen die hook en een server-up-hook. De up-hook wordt geactiveerd wanneer de server zijn tunnelapparaat opent, wat op een server met meerdere clients één keer gebeurt bij het starten van de daemon. Het is geen gebeurtenis per aanmelding, en code die daar staat, draait wanneer de dienst start in plaats van wanneer gebruikers verbinden.

Op een apparaat met een webinterface gebruik je het ondersteunde uitbreidingsmechanisme in plaats van gegenereerde daemonbestanden te bewerken. Gegenereerde bestanden worden bij de volgende opslag herschreven, en het herschrijven verwijdert je wijziging stil op het slechtst mogelijke moment. Bewaar een kopie van de uitbreidingstekst buiten het apparaat, zodat een firmware-update ook de bedoeling niet verliest.

De optie aan de clientkant: werk dat lokaal moet draaien

Een communityclient kan een lokaal script draaien wanneer het tunnelapparaat opkomt en opnieuw wanneer routes worden geïnstalleerd. Dat zijn twee verschillende momenten, en de verkeerde kiezen levert de klassieke race op waarbij een helper start voordat de route waarvan hij afhankelijk is bestaat.

De helper moet op die client bestaan, leesbaar en uitvoerbaar zijn voor het account dat de client draait, en toegestaan zijn door een expliciete script-security-instelling. Een script dat werkt wanneer je de client als administrator start, zegt niets over een dienst vóór de aanmelding of over de sessie van een andere gebruiker.

Naamgeving is ook belangrijk. De up-hook hoort bij het aanmaken van het apparaat en route-up bij het installeren van routes, maar een taak die vereist dat een particulier netwerk bereikbaar is, moet de bereikbaarheid verifiëren in plaats van aan te nemen dat het aanmaken van het apparaat betekent dat elke route, resolververmelding en applicatie klaar is.

Waarom het pushen van uitvoerbare code niet op het menu staat

Gepushte opties zijn bewust beperkt, en opties die scripts uitvoeren behoren tot de categorieën die de server niet mag doorgeven. Die beperking bestaat omdat het alternatief een gecompromitteerde of verkeerd geconfigureerde server zou toestaan willekeurige opdrachten uit te voeren op elke client die ooit verbindt.

Het lokaal inschakelen van scriptuitvoering verandert dat niet. Je script-security-instelling staat lokale scripts toe die je zelf hebt gekozen; ze geeft de server niet het recht nieuwe te leveren.

Als het doel simpelweg is VPN-routes te installeren, gebruik dan de ondersteunde routeconfiguratie in plaats van een schema voor uitvoering op afstand te bedenken. Als het doel echt lokale code vereist, distribueer die dan via de endpointbeheertools van de organisatie en beoordeel die zoals elke andere software die met de rechten van de gebruiker draait.

Wat je moet verifiëren voordat je een van beide hooks vertrouwt

Schrijf vier dingen op voor elke hook: de machine, de gebeurtenisnaam, het account waaronder hij draait, en de toestandsverandering die hij hoort te produceren. Test dan de verbinding, een herverbinding en het opruimpad, want een hook die toestand lekt bij herverbinding is erger dan een die nooit draaide.

Test onder het account dat hem daadwerkelijk uitvoert, op het moment dat hij daadwerkelijk wordt uitgevoerd. De handleiding openvpn(8) documenteert beide hookfamilies en de pushbeperkingen; het platform waarop je implementeert documenteert of het ze eigenlijk aanbiedt. Een script dat slaagt in een interactieve administratorterminal is een hypothese, geen verificatie.