Kliënt-haak of bediener-haak? Waar ’n OpenVPN-skrip hardloop

Die taak is duidelik: wanneer ’n skootrekenaar koppel, moet iets op die skootrekenaar verander. Die konfigurasie wat geredigeer word, behoort aan die bediener, en dit is waar die aanname breek. ’n Pad in ’n bediener-lêer noem ’n lêer op daardie bediener, en geen hoeveelheid push verander wie se proses dit uitvoer nie. Om tussen die twee hake te kies is meestal ’n kwessie van besluit watter masjien die werk besit en die grense wat daaruit volg, aanvaar.

Twee masjiene, twee vrae om eerste te beantwoord

Vra waar die toestandsverandering moet plaasvind, vra dan watter gebeurtenis daarmee ooreenstem. As die verandering ’n per-gebruiker magtiging of ’n per-kliënt konfigurasiebesluit is, hoort dit waar die gebruikersgids bekend is: die bediener. As die verandering ’n roete is, ’n resolver-instelling of ’n plaaslike helper op ’n eindpunt, hoort dit op die eindpunt, en net die eindpunt kan dit doen.

Om daardie twee vrae in die ander volgorde te beantwoord, is hoe mense uiteindelik ’n batch-lêer na ’n Windows-skootrekenaar probeer push. Die bediener weet wie gekoppel het; die skootrekenaar weet hoe sy eie netwerkstapel lyk. Nie een het die ander se inligting nie, en die poging misluk gewoonlik stilweg eerder as met ’n duidelike fout.

’n Derde vraag is die moeite werd om voor albei te vra: bied die platform selfs die haak wat jy wil hê? ’n Toestel wat sy eie konfigurasie genereer, het dalk nie dieselfde gebeurtenisname nie, en ’n tafelblad-kliënt wat ’n .ovpn-lêer invoer, is nie noodwendig dieselfde kliënt waarvoor die lêer geskryf is nie. Om eers die platform te bevestig, beskerm jou teen die ontwerp rondom ’n haak wat daar nie bestaan nie. Dit sê ook vir jou watter dokumentasie werklik op die masjien voor jou van toepassing is.

Die bediener-kant opsie: ’n per-verbinding gebeurtenis

’n client-connect-skrip loop in die bediener se proseskonteks wanneer ’n geauthentiseerde kliënt koppel, en dit ontvang gedokumenteerde verbindingsbesonderhede soos die common name en die toegewysde adres. Dit is die regte plek om ’n per-kliënt konfigurasiefragment te skryf, ’n beleidsbesluit af te dwing of toestand wat die bediener besit, aan te teken.

Die onderskeid wat mense miskyk, is die verskil tussen daardie haak en ’n bediener-up-haak. Die up-haak vuur wanneer die bediener sy tonnel-toestel oopmaak, wat een keer by daemon-start op ’n multi-kliënt bediener gebeur. Dit is nie ’n per-aanmelding gebeurtenis nie, en kode wat daar geplaas word, loop wanneer die diens begin eerder as wanneer gebruikers koppel.

Op ’n toestel met ’n web-koppelvlak, gebruik die ondersteunde uitbreidingsmeganisme eerder as om gegenereerde daemon-lêers te redigeer. Gegenereerde lêers word by die volgende stoor herskryf, en die herskrywing verwyder jou verandering stilweg op die slegste moontlike oomblik. Hou ’n kopie van die uitbreidingsteks buite die toestel sodat ’n firmware-opdatering nie ook die bedoeling verloor nie.

Die kliënt-kant opsie: werk wat plaaslik moet loop

’n Gemeenskapskliënt kan ’n plaaslike skrip laat loop wanneer die tonnel-toestel opkom en weer wanneer roetes geïnstalleer word. Dit is twee verskillende oomblikke, en om die verkeerde een te kies, veroorsaak die klassieke resies waar ’n helper begin voordat die roete waarvan dit afhanklik is, bestaan.

Die helper moet op daardie kliënt bestaan, leesbaar en uitvoerbaar wees deur die rekening wat die kliënt laat loop, en toegelaat word deur ’n eksplisiete script-security-instelling. ’n Skrip wat werk wanneer jy die kliënt as administrateur begin, sê niks oor ’n voor-aanmelding diens of ’n ander gebruiker se sessie nie.

Naamgewing maak ook saak. Die up-haak stem ooreen met toestel-skepping en route-up met roete-installasie, maar ’n taak wat ’n private netwerk bereikbaar moet hê, moet bereikbaarheid verifieer eerder as om aan te neem dat toestel-skepping impliseer dat elke roete, resolver-inskrywing en toepassing gereed is.

Waarom push van uitvoerbare kode nie op die spyskaart is nie

Gepusde opsies is doelbewus beperk, en opsies wat skripte uitvoer, is een van die kategorieë wat die bediener nie mag deurgee nie. Daardie beperking bestaan omdat die alternatief ’n gekompromitteerde of verkeerd gekonfigureerde bediener toelaat om willekeurige opdragte op elke kliënt wat ooit koppel, te laat loop.

Om skripuitvoering plaaslik te aktiveer, verander dit nie. Jou script-security-instelling laat plaaslike skripte toe wat jy gekies het; dit magtig nie die bediener om nuwes te voorsien nie.

As die doel bloot is om VPN-roetes te installeer, gebruik die ondersteunde roete-konfigurasie eerder as om ’n afstand-uitvoeringskema te bedink. As die doel werklik plaaslike kode vereis, versprei dit deur die organisasie se eindpunt-bestuursgereedskap en hersien dit soos enige ander sagteware wat met die gebruiker se voorregte loop.

Wat om te verifieer voordat jy enige van die twee hake vertrou

Skryf vier dinge vir elke haak neer: die masjien, die gebeurtenisnaam, die rekening waaronder dit loop, en die toestandsverandering wat dit veronderstel is om te produseer. Toets dan die verbinding, ’n herverbinding en die opruimingspad, want ’n haak wat toestand lek by herverbinding is erger as een wat nooit geloop het nie.

Toets onder die rekening wat dit werklik sal uitvoer, op die oomblik wat dit werklik sal uitvoer. Die openvpn(8)-handleiding dokumenteer beide haakfamilies en die push-beperkings; die platform waarop jy ontplooi, dokumenteer of dit dit hoegenaamd blootstel. ’n Skrip wat in ’n interaktiewe administrateur-terminaal slaag, is ’n hipotese, nie ’n verifikasie nie.