Oppgåva er klar: når ein berbar PC koplar til, skal noko på den berbare endre seg. Konfigurasjonen som blir redigert, høyrer til serveren, og det er der føresetnaden bryt saman. Ein sti i ei serverfil namngir ei fil på den serveren, og inga mengd push endrar kva prosess som utfører han. Å velje mellom dei to krokane er stort sett å avgjere kva maskin som eig arbeidet, og å godta grensene som følgjer.

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

Spør kvar tilstandsendringa må skje, og spør så kva hending som svarar til henne. Om endringa er ein autorisasjon per brukar eller ei konfigurasjonsavgjerd per klient, høyrer ho til der brukarkatalogen er kjend: serveren. Om endringa er ei rute, ein resolver-innstilling eller ein lokal hjelpar på eit endepunkt, høyrer ho til på endepunktet, og berre endepunktet kan gjere det.

Å svare på desse to spørsmåla i motsett rekkjefølgje er korleis folk endar med å prøve å dytte ei batchfil til ein Windows-berbar. Serveren veit kven som kopla til; den berbare veit korleis eigen nettverksstakk ser ut. Ingen av dei har informasjonen til den andre, og forsøket mislukkast vanlegvis stille i staden for med ein klar feil.

Før begge er eit tredje spørsmål verdt å stille: tilbyr plattforma i det heile kroken du vil ha? Eit apparat som genererer sin eigen konfigurasjon tilbyr kanskje ikkje dei same hendingsnamna, og ein skrivebordsklient som importerer ei .ovpn-fil er ikkje nødvendigvis den same klienten som fila vart skriven for. Å stadfeste plattforma først sparar deg for å designe rundt ein krok som ikkje finst der. Det fortel deg òg kva dokumentasjon som faktisk gjeld for maskina framfor deg.

Serveralternativet: ei hending per tilkopling

Eit client-connect-skript køyrer i prosesskonteksten til serveren når ein autentisert klient koplar til, og det tek imot dokumenterte tilkoplingsdetaljar som common name og den tildelte adressa. Det er rett stad å skrive eit konfigurasjonsfragment per klient, handheve ei politikkavgjerd eller registrere tilstand som serveren eig.

Skilnaden folk går glipp av, er skilnaden mellom den kroken og ein server-up-krok. Up-kroken blir utløyst når serveren opnar tunnelinnretninga si, noko som skjer éin gong ved demonstart på ein server med fleire klientar. Det er ikkje ei hending per innlogging, og kode som blir plassert der, køyrer når tenesta startar i staden for når brukarar koplar til.

På eit apparat med webgrensesnitt brukar du den støtta utvidingsmekanismen i staden for å redigere genererte demonfiler. Genererte filer blir skrivne om ved neste lagring, og omskrivinga fjernar stille endringa di på det verst tenkjelege tidspunktet. Ta vare på ein kopi av utvidingsteksten utanfor apparatet, slik at ein fastvareoppdatering ikkje òg mistar hensikta.

Klientalternativet: arbeid som må køyre lokalt

Ein fellesskapsklient kan køyre eit lokalt skript når tunnelinnretninga kjem opp, og igjen når ruter blir installerte. Det er to ulike augneblink, og å velje feil gir det klassiske kappløpet der ein hjelpar startar før ruta han er avhengig av, finst.

Hjelparen må finnast på den klienten, vere lesbar og køyrbar for kontoen som køyrer klienten, og vere tillaten av ei eksplisitt script-security-innstilling. Eit skript som fungerer når du startar klienten som administrator, seier ingenting om ei teneste før innlogging eller om økta til ein annan brukar.

Namngjeving spelar òg ei rolle. Up-kroken svarar til opprettinga av innretninga og route-up til installasjon av ruter, men ei oppgåve som krev at eit privat nettverk kan nåast, bør stadfeste nåbarheita i staden for å anta at opprettinga av innretninga betyr at kvar rute, resolver-oppføring og applikasjon er klar.

Kvifor pushing av køyrbar kode ikkje er på menyen

Pusha alternativ er med vilje avgrensa, og alternativ som køyrer skript, er blant kategoriane serveren ikkje har lov til å sende ned. Den avgrensinga finst fordi alternativet ville late ein kompromittert eller feilkonfigurert server køyre vilkårlege kommandoar på kvar klient som nokon gong koplar til.

Å slå på skriptkøyring lokalt endrar ikkje det. Di script-security-innstilling tillèt lokale skript du sjølv valde; ho gir ikkje serveren rett til å levere nye.

Om målet berre er å installere VPN-ruter, bruk den støtta rutekonfigurasjonen i staden for å finne opp ei ordning for fjernkøyring. Om målet verkeleg krev lokal kode, distribuer han via organisasjonen sine verktøy for endepunktsadministrasjon og gå gjennom han som all annan programvare som køyrer med rettane til brukaren.

Kva du bør stadfeste før du stolar på nokon av krokane

Skriv ned fire ting for kvar krok: maskina, hendingsnamnet, kontoen han køyrer som, og tilstandsendringa han skal produsere. Test så tilkoplinga, ei attilkopling og oppryddingsstien, fordi ein krok som lek tilstand ved attilkopling, er verre enn ein som aldri køyrde.

Test under kontoen som faktisk skal utføre han, i det augneblinken han faktisk skal utførast. Openvpn(8)-handboka dokumenterer begge krokfamiliane og push-avgrensingane; plattforma du distribuerer på, dokumenterer om ho i det heile eksponerer dei. Eit skript som lukkast i ein interaktiv administratorterminal, er ein hypotese, ikkje ein stadfesting.

Relaterte artiklar