Bezeroaren kakoa ala zerbitzariaren kakoa? Non exekutatzen da OpenVPN script bat

Zeregina argia da: ordenagailu eramangarri bat konektatzen denean, zerbait aldatu beharko litzateke ordenagailuan bertan. Editatu ari den konfigurazioa zerbitzariarena da, eta hor bertan hausten da suposizioa. Zerbitzariko fitxategi bateko bide batek zerbitzari horretako fitxategi bat izendatzen du, eta push kopuruak ez du aldatzen zein prozesuk exekutatzen duen. Bi kakuen artean aukeratzea, batez ere, zein makina lanaren jabe den erabakitzea eta hortik datozen mugak onartzea da.

Bi makina, lehenago erantzun beharreko bi galdera

Galdetu non gertatu behar duen egoera-aldaketak, eta gero galdetu zein gertaerari dagokion. Aldaketa erabiltzaile bakoitzeko baimena edo bezero bakoitzeko konfigurazio-erabakia bada, erabiltzaile-direktorioa ezagutzen den lekura dagokio: zerbitzarira. Aldaketa bide bat bada, resolver ezarpena edo muturreko laguntzaile lokala bada, muturrera dagokio, eta muturrak soilik egin dezake.

Bi galdera horiei alderantzizko ordenean erantzutea da jendeak Windows ordenagailu eramangarri batera batch fitxategi bat bidaltzen saiatzen amaitzeko duen modua. Zerbitzariak badaki nortzuk konektatu diren; ordenagailuak badaki nolakoa den bere sare pila. Batek ez du bestearen informaziorik, eta saiakera isilean huts egiten du normalean, errore argi baten ordez.

Biak baino lehen, hirugarren galdera bat egitea merezi du: plataformak eskaintzen al du, behintzat, nahi duzun kakua? Bere konfigurazioa sortzen duen gailu batek agian ez ditu gertaera-izen berak eskaintzen, eta .ovpn fitxategia inportatzen duen mahaigaineko bezeroa ez da nahitaez fitxategia idatzi zeneko bezeroa. Plataforma lehenago baieztatzeak han existitzen ez den kaku baten inguruan diseinatzetik salbatzen zaitu. Aurretik duzun makinari zein dokumentazio dagokion ere esaten dizu.

Zerbitzariaren aldeko aukera: konexio bakoitzeko gertaera

client-connect script bat zerbitzariaren prozesuaren testuinguruan exekutatzen da bezero autentifikatu bat konektatzen denean, eta dokumentatutako konexio-xehetasunak jasotzen ditu, hala nola common name eta esleitutako helbidea. Toki egokia da bezero bakoitzeko konfigurazio-zati bat idazteko, politika-erabaki bat betearazteko edo zerbitzariaren jabegoko egoera erregistratzeko.

Jendeak ahazten duen bereizketa kaku horren eta zerbitzariko up kakuaren arteko aldea da. up kakua zerbitzariak bere tunel-gailua irekitzen duenean abiarazten da, eta bezero anitzeko zerbitzari batean behin gertatzen da daemona hastean. Ez da saioa hasteko gertaera bat, eta han jarritako kodea zerbitzua hastean exekutatzen da, ez erabiltzaileak konektatzen direnean.

Web interfazea duen gailu batean, erabili onartutako luzapen-mekanismoa, daemon fitxategi sortuak editatu beharrean. Fitxategi sortuak hurrengo gordetzean berridazten dira, eta berridazketak isilean kentzen du zure aldaketa une okerrenean. Gorde luzapen-testuaren kopia bat gailutik kanpo, firmware eguneratze batek asmoa ere gal ez dezan.

Bezeroaren aldeko aukera: lokalki exekutatu behar den lana

Komunitateko bezero batek script lokal bat exekuta dezake tunel-gailua altxatzen denean eta berriro bideak instalatzen direnean. Bi une desberdin dira, eta okerra aukeratzeak lasterketa klasikoa sortzen du: laguntzailea mendeko duen bidea existitu baino lehen hasten da.

Laguntzaileak bezero horretan egon behar du, bezeroa exekutatzen duen kontuak irakurgarri eta exekutagarri izan behar du, eta script-security ezarpen esplizitu batek baimendu behar du. Administratzaile gisa bezeroa abiaraztean funtzionatzen duen script batek ez dizu ezer esaten saioa hasi aurreko zerbitzu bati buruz edo beste erabiltzaile baten sesioari buruz.

Izenek ere garrantzia dute. up kakua gailua sortzeari dagokio eta route-up bideak instalatzeari, baina sare pribatu bat irisgarria izatea behar duen zereginak irisgarritasuna egiaztatu behar du, gailua sortzeak bide, resolver sarrera eta aplikazio guztiak prest daudela esan nahi duela suposatu beharrean.

Zergatik ez den kode exekutagarria bidaltzea aukeren artean

Pushatutako aukerak nahita mugatuta daude, eta scriptak exekutatzen dituzten aukerak zerbitzariak ezin dituen kategorien artean daude. Muga hori existitzen da, alternatibak zerbitzari konprometitu edo gaizki konfiguratu batek inoiz konektatzen den bezero bakoitzean komando arbitrarioak exekutatzeko aukera emango liokeelako.

Script exekuzioa lokalki gaitzeak ez du hori aldatzen. Zure script-security ezarpenak zuk aukeratutako script lokalak baimentzen ditu; ez dio zerbitzariari berriak emateko baimenik ematen.

Helburua VPN bideak instalatzea bada soilik, erabili onartutako bide-konfigurazioa, urruneko exekuzio-eskema bat asmatu beharrean. Helburuak benetan kode lokala behar badu, banatu erakundearen mutur-kudeaketarako tresnen bidez, eta berrikusi erabiltzailearen pribilegioekin exekutatzen den beste edozein software bezala.

Zer egiaztatu bi kakuetan fidatu aurretik

Idatzi lau gauza kaku bakoitzeko: makina, gertaeraren izena, zein konturekin exekutatzen den, eta sortu behar duen egoera-aldaketa. Gero probatu konexioa, berrikonexioa eta garbiketa-bidea, berrikonexioan egoera isurtzen duen kaku bat inoiz exekutatu ez zen bat baino okerragoa delako.

Proba ezazu benetan exekutatuko duen kontuarekin, benetan exekutatuko den unean. openvpn(8) eskuliburuak bi kaku familiak eta push murrizketak dokumentatzen ditu; hedatu zaren plataformak dokumentatzen du ea horiek eskaintzen dituen. Administratzaile terminal interaktibo batean arrakasta duen script bat hipotesi bat da, ez egiaztapena.