Klienthook eller serverhook? Hvor kører et OpenVPN-script

Opgaven er klar: når en bærbar computer opretter forbindelse, skal noget på den bærbare ændre sig. Den konfiguration, der redigeres, tilhører serveren, og det er der, antagelsen brister. En sti i en serverfil navngiver en fil på den server, og ingen mængde push ændrer, hvis proces der udfører den. Valget mellem de to hooks handler mest om at beslutte, hvilken maskine der ejer arbejdet, og acceptere de grænser, der følger.

To maskiner, to spørgsmål der skal besvares først

Spørg, hvor tilstandsændringen skal ske, og spørg derefter, hvilken hændelse der svarer til den. Hvis ændringen er en autorisation pr. bruger eller en konfigurationsbeslutning pr. klient, hører den til der, hvor brugerkataloget er kendt: serveren. Hvis ændringen er en rute, en resolverindstilling eller en lokal hjælper på et endepunkt, hører den til på endepunktet, og kun endepunktet kan gøre det.

At besvare de to spørgsmål i omvendt rækkefølge er, hvordan folk ender med at forsøge at skubbe en batchfil til en Windows-bærbar. Serveren ved, hvem der har forbundet; den bærbare ved, hvordan dens egen netværksstak ser ud. Ingen af dem har den andens oplysninger, og forsøget fejler som regel stille i stedet for med en klar fejl.

Et tredje spørgsmål er værd at stille før begge: tilbyder platformen overhovedet det hook, du vil have? Et apparat, der selv genererer sin konfiguration, tilbyder måske ikke de samme hændelsesnavne, og en desktopklient, der importerer en .ovpn-fil, er ikke nødvendigvis den samme klient, som filen blev skrevet til. At bekræfte platformen først sparer dig for at designe omkring et hook, der ikke findes der. Det fortæller dig også, hvilken dokumentation der faktisk gælder for maskinen foran dig.

Servermuligheden: en hændelse pr. forbindelse

Et client-connect-script kører i serverens proceskontekst, når en autentificeret klient opretter forbindelse, og det modtager dokumenterede forbindelsesoplysninger som common name og den tildelte adresse. Det er det rigtige sted at skrive et konfigurationsfragment pr. klient, håndhæve en politisk beslutning eller registrere tilstand, som serveren ejer.

Den forskel, folk overser, er forskellen mellem det hook og et server-up-hook. Up-hooket udløses, når serveren åbner sin tunneleenhed, hvilket sker én gang ved dæmonstart på en server med flere klienter. Det er ikke en hændelse pr. login, og kode, der placeres der, kører, når tjenesten starter, i stedet for når brugere forbinder.

På et apparat med webgrænseflade skal du bruge den understøttede udvidelsesmekanisme i stedet for at redigere genererede dæmonfiler. Genererede filer bliver skrevet om ved næste gemning, og omskrivningen fjerner stille din ændring på det værst tænkelige tidspunkt. Opbevar en kopi af udvidelsesteksten uden for apparatet, så en firmwareopdatering ikke også mister hensigten.

Klientmuligheden: arbejde, der skal køre lokalt

En fællesskabsklient kan køre et lokalt script, når tunneleenheden kommer op, og igen når ruter installeres. Det er to forskellige øjeblikke, og vælger man det forkerte, opstår det klassiske kapløb, hvor en hjælper starter, før den rute, den afhænger af, findes.

Hjælperen skal findes på den klient, være læsbar og eksekverbar for den konto, der kører klienten, og være tilladt af en eksplicit script-security-indstilling. Et script, der virker, når du starter klienten som administrator, siger intet om en tjeneste før login eller en anden brugers session.

Navngivning betyder også noget. Up-hooket svarer til oprettelse af enheden og route-up til installation af ruter, men en opgave, der kræver, at et privat netværk kan nås, bør verificere tilgængeligheden i stedet for at antage, at oprettelse af enheden betyder, at hver rute, resolverpost og applikation er klar.

Hvorfor skub af eksekverbar kode ikke er på menuen

Push-ede indstillinger er bevidst begrænsede, og indstillinger, der udfører scripts, er blandt de kategorier, som serveren ikke må sende videre. Den begrænsning findes, fordi alternativet ville lade en kompromitteret eller fejlkonfigureret server køre vilkårlige kommandoer på enhver klient, der nogensinde forbinder.

At aktivere scriptkørsel lokalt ændrer ikke det. Din script-security-indstilling tillader lokale scripts, du selv har valgt; den giver ikke serveren ret til at levere nye.

Hvis målet blot er at installere VPN-ruter, skal du bruge den understøttede rutekonfiguration i stedet for at opfinde en ordning til fjernkørsel. Hvis målet virkelig kræver lokal kode, skal du distribuere det via organisationens værktøjer til endpoint-styring og gennemgå det som enhver anden software, der kører med brugerens rettigheder.

Hvad du skal kontrollere, før du stoler på et af hookene

Skriv fire ting ned for hvert hook: maskinen, hændelsesnavnet, den konto det kører som, og den tilstandsændring, det skal frembringe. Test derefter forbindelsen, en genoprettelse af forbindelsen og oprydningsstien, fordi et hook, der lækker tilstand ved genforbindelse, er værre end et, der aldrig kørte.

Test under den konto, der faktisk skal køre det, på det tidspunkt, det faktisk skal køre. Openvpn(8)-manualen dokumenterer begge hook-familier og push-begrænsningerne; den platform, du udruller på, dokumenterer, om den overhovedet eksponerer dem. Et script, der lykkes i en interaktiv administratorterminal, er en hypotese, ikke en verifikation.