Klientkrok eller serverkrok? Hvor et OpenVPN-skript kjører

Oppgaven er klar: når en bærbar PC kobler til, skal noe på den bærbare endres. Konfigurasjonen som redigeres, tilhører serveren, og det er der antakelsen brister. En bane i en serverfil navngir en fil på den serveren, og ingen mengde push endrer hvilken prosess som utfører den. Å velge mellom de to krokene er stort sett å bestemme hvilken maskin som eier arbeidet, og å godta grensene som følger.

To maskiner, to spørsmål som må besvares først

Spør hvor tilstandsendringen må skje, og spør deretter hvilken hendelse som svarer til den. Hvis endringen er en autorisasjon per bruker eller en konfigurasjonsbeslutning per klient, hører den til der brukerkatalogen er kjent: serveren. Hvis endringen er en rute, en resolver-innstilling eller en lokal hjelper på et endepunkt, hører den til på endepunktet, og bare endepunktet kan gjøre det.

Å svare på disse to spørsmålene i motsatt rekkefølge er hvordan folk ender med å prøve å dytte en batchfil til en Windows-bærbar. Serveren vet hvem som koblet til; den bærbare vet hvordan dens egen nettverksstakk ser ut. Ingen av dem har den andres informasjon, og forsøket feiler vanligvis stille i stedet for med en klar feil.

Før begge er et tredje spørsmål verdt å stille: tilbyr plattformen i det hele tatt kroken du vil ha? Et apparat som genererer sin egen konfigurasjon tilbyr kanskje ikke de samme hendelsesnavnene, og en skrivebordsklient som importerer en .ovpn-fil er ikke nødvendigvis den samme klienten som filen ble skrevet for. Å bekrefte plattformen først sparer deg for å designe rundt en krok som ikke finnes der. Det forteller deg også hvilken dokumentasjon som faktisk gjelder for maskinen foran deg.

Serveralternativet: en hendelse per tilkobling

Et client-connect-skript kjører i serverens prosesskontekst når en autentisert klient kobler til, og det mottar dokumenterte tilkoblingsdetaljer som common name og den tildelte adressen. Det er det riktige stedet å skrive et konfigurasjonsfragment per klient, håndheve en policybeslutning eller registrere tilstand som serveren eier.

Forskjellen folk går glipp av, er forskjellen mellom den kroken og en server-up-krok. Up-kroken utløses når serveren åpner tunnelinnretningen sin, noe som skjer én gang ved demonstart på en server med flere klienter. Det er ikke en hendelse per innlogging, og kode som plasseres der, kjører når tjenesten starter i stedet for når brukere kobler til.

På et apparat med webgrensesnitt bruker du den støttede utvidelsesmekanismen i stedet for å redigere genererte demonfiler. Genererte filer skrives om ved neste lagring, og omskrivingen fjerner stille endringen din på det verst tenkelige tidspunktet. Ta vare på en kopi av utvidelsesteksten utenfor apparatet, slik at en fastvareoppdatering ikke også mister hensikten.

Klientalternativet: arbeid som må kjøre lokalt

En fellesskapsklient kan kjøre et lokalt skript når tunnelinnretningen kommer opp, og igjen når ruter installeres. Det er to forskjellige øyeblikk, og å velge feil gir det klassiske kappløpet der en hjelper starter før ruten den avhenger av, finnes.

Hjelperen må finnes på den klienten, være lesbar og kjørbar for kontoen som kjører klienten, og være tillatt av en eksplisitt script-security-innstilling. Et skript som fungerer når du starter klienten som administrator, sier ingenting om en tjeneste før innlogging eller en annen brukers økt.

Navngivning betyr også noe. Up-kroken svarer til opprettelsen av innretningen og route-up til installasjon av ruter, men en oppgave som krever at et privat nettverk kan nås, bør verifisere nåbarheten i stedet for å anta at opprettelsen av innretningen betyr at hver rute, resolver-oppføring og applikasjon er klar.

Hvorfor pushing av kjørbar kode ikke er på menyen

Push-ede alternativer er bevisst begrenset, og alternativer som kjører skript, er blant kategoriene serveren ikke har lov til å sende ned. Den begrensningen finnes fordi alternativet ville la en kompromittert eller feilkonfigurert server kjøre vilkårlige kommandoer på hver klient som noen gang kobler til.

Å aktivere skriptkjøring lokalt endrer ikke det. Din script-security-innstilling tillater lokale skript du selv valgte; den gir ikke serveren rett til å levere nye.

Hvis målet bare er å installere VPN-ruter, bruk den støttede rutekonfigurasjonen i stedet for å finne opp en ordning for fjernkjøring. Hvis målet virkelig krever lokal kode, distribuer den via organisasjonens verktøy for endepunktsadministrasjon og gjennomgå den som all annen programvare som kjører med brukerens rettigheter.

Hva du bør verifisere før du stoler på noen av krokene

Skriv ned fire ting for hver krok: maskinen, hendelsesnavnet, kontoen den kjører som, og tilstandsendringen den skal produsere. Test deretter tilkoblingen, en gjentilkobling og oppryddingsbanen, fordi en krok som lekker tilstand ved gjentilkobling, er verre enn en som aldri kjørte.

Test under kontoen som faktisk skal utføre den, i det øyeblikket den faktisk skal utføres. Openvpn(8)-håndboken dokumenterer begge krokfamiliene og push-begrensningene; plattformen du distribuerer på, dokumenterer om den i det hele tatt eksponerer dem. Et skript som lykkes i en interaktiv administratorterminal, er en hypotese, ikke en verifisering.