Asiakkaan vai palvelimen koukku? Missä OpenVPN-skripti suoritetaan

Tehtävä on selvä: kun kannettava yhdistää, jotain kannettavassa pitäisi muuttua. Konfiguraatio, jota muokataan, kuuluu palvelimelle, ja juuri siinä oletus hajoaa. Polku palvelimen tiedostossa nimeää tiedoston sillä palvelimella, eikä mikään määrä pushia muuta sitä, kenen prosessi sen suorittaa. Kahden koukun välillä valitseminen on lähinnä päätös siitä, mikä kone omistaa työn, ja siitä seuraavien rajojen hyväksymistä.

Kaksi konetta, kaksi kysymystä joihin vastataan ensin

Kysy, missä tilamuutoksen on tapahduttava, ja kysy sitten, mikä tapahtuma vastaa sitä. Jos muutos on käyttäjäkohtainen valtuutus tai asiakaskohtainen konfiguraatiopäätös, se kuuluu sinne, missä käyttäjäluettelo tunnetaan: palvelimelle. Jos muutos on reitti, resolver-asetus tai paikallinen apuri päätepisteessä, se kuuluu päätepisteelle, ja vain päätepiste voi tehdä sen.

Näihin kahteen kysymykseen vastaaminen päinvastaisessa järjestyksessä on se, miten ihmiset päätyvät yrittämään työntää erätiedoston Windows-kannettavaan. Palvelin tietää, kuka yhdisti; kannettava tietää, miltä sen oma verkkopino näyttää. Kummallakaan ei ole toisen tietoja, ja yritys epäonnistuu yleensä hiljaa selkeän virheen sijaan.

Ennen kumpaakin kannattaa kysyä kolmas kysymys: tarjoaako alusta ylipäänsä sen koukun, jonka haluat? Laite, joka tuottaa oman konfiguraationsa, ei välttämättä tarjoa samoja tapahtumanimiä, eikä .ovpn-tiedoston tuova työpöytäasiakas ole välttämättä sama asiakas, jolle tiedosto kirjoitettiin. Alustan vahvistaminen ensin säästää sinut suunnittelemasta sellaisen koukun ympärille, jota siellä ei ole. Se kertoo myös, mitkä dokumentit todella koskevat edessäsi olevaa konetta.

Palvelinpuolen vaihtoehto: tapahtuma yhteyttä kohden

client-connect-skripti suoritetaan palvelimen prosessikontekstissa, kun todennettu asiakas yhdistää, ja se vastaanottaa dokumentoituja yhteystietoja, kuten common name ja määritetty osoite. Se on oikea paikka kirjoittaa asiakaskohtainen konfiguraatiokatkelma, panna täytäntöön käytäntöpäätös tai tallentaa tilaa, jonka palvelin omistaa.

Ero, jonka ihmiset jättävät huomaamatta, on ero tuon koukun ja palvelimen up-koukun välillä. up-koukku laukeaa, kun palvelin avaa tunnelilaitteensa, mikä tapahtuu usean asiakkaan palvelimella kerran daemonin käynnistyessä. Se ei ole kirjautumiskohtainen tapahtuma, ja sinne sijoitettu koodi suoritetaan palvelun käynnistyessä, ei käyttäjien yhdistäessä.

Verkkoliittymällä varustetussa laitteessa käytä tuettua laajennusmekanismia sen sijaan, että muokkaisit luotuja daemon-tiedostoja. Luodut tiedostot kirjoitetaan uudelleen seuraavassa tallennuksessa, ja uudelleenkirjoitus poistaa muutoksesi hiljaa kaikkein huonoimmalla hetkellä. Pidä kopio laajennustekstistä laitteen ulkopuolella, jotta laiteohjelmiston päivitys ei kadottaisi myös aikomusta.

Asiakaspuolen vaihtoehto: työ, jonka on pakko suorittaa paikallisesti

Yhteisön asiakas voi suorittaa paikallisen skriptin, kun tunnelilaite nousee, ja uudelleen, kun reitit asennetaan. Ne ovat kaksi eri hetkeä, ja väärän valitseminen tuottaa klassisen kilpailun, jossa apuri käynnistyy ennen kuin reitti, josta se riippuu, on olemassa.

Apurin on oltava olemassa siinä asiakkaassa, luettavissa ja suoritettavissa sen tilin toimesta, joka ajaa asiakasta, ja sallittava nimenomaisella script-security-asetuksella. Skripti, joka toimii, kun käynnistät asiakkaan järjestelmänvalvojana, ei kerro sinulle mitään ennen kirjautumista toimivasta palvelusta tai toisen käyttäjän istunnosta.

Nimeäminen on myös tärkeää. up-koukku vastaa laitteen luontia ja route-up reittien asennusta, mutta tehtävän, joka vaatii yksityisverkon saavutettavuutta, pitäisi varmistaa saavutettavuus sen sijaan, että olettaisi laitteen luonnin tarkoittavan jokaisen reitin, resolver-merkinnän ja sovelluksen olevan valmiina.

Miksi suoritettavan koodin työntäminen ei ole valikoimassa

Pushilla työnnetyt asetukset ovat tarkoituksella rajoitettuja, ja skriptejä suorittavat asetukset kuuluvat niihin luokkiin, joita palvelin ei saa välittää. Rajoitus on olemassa siksi, että vaihtoehto antaisi vaarantuneen tai väärin konfiguroidun palvelimen suorittaa mielivaltaisia komentoja jokaisessa asiakkaassa, joka koskaan yhdistää.

Skriptien suorittamisen salliminen paikallisesti ei muuta sitä. script-security-asetuksesi sallii paikalliset skriptit, jotka sinä valitsit; se ei valtuuta palvelinta toimittamaan uusia.

Jos tavoitteena on vain asentaa VPN-reittejä, käytä tuettua reittikonfiguraatiota sen sijaan, että keksit etäsuoritusjärjestelmän. Jos tavoite todella vaatii paikallista koodia, jaa se organisaation päätepisteiden hallintatyökalujen kautta ja tarkastele sitä kuin mitä tahansa muuta ohjelmistoa, joka toimii käyttäjän oikeuksilla.

Mitä varmistaa ennen kuin luotat kumpaankaan koukkuun

Kirjoita kullekin koukulle neljä asiaa: kone, tapahtuman nimi, tili jonka alla se toimii, ja tilamuutos, jonka se on tarkoitus tuottaa. Testaa sitten yhteys, uudelleenyhdistäminen ja siivouspolku, koska koukku, joka vuotaa tilaa uudelleenyhdistäessä, on huonompi kuin sellainen, joka ei koskaan toiminut.

Testaa sen tilin alla, joka sen todella suorittaa, hetkellä, jolloin se todella suoritetaan. openvpn(8)-käsikirja dokumentoi molemmat koukkoperheet ja pushin rajoitukset; alusta, jolle otat käyttöön, dokumentoi, tarjoaako se niitä lainkaan. Skripti, joka onnistuu vuorovaikutteisessa järjestelmänvalvojan päätteessä, on hypoteesi, ei varmistus.