Kliento kablys ar serverio kablys? Kur vykdomas OpenVPN scenarijus

Užduotis aiški: kai nešiojamasis kompiuteris prisijungia, kažkas jame turėtų pasikeisti. Konfigūracija, kuri redaguojama, priklauso serveriui, ir būtent čia prielaida lūžta. Kelias serverio faile nurodo failą tame serveryje, ir joks push kiekis nekeičia, kurio procesas jį vykdo. Pasirinkimas tarp dviejų kablių iš esmės yra sprendimas, kuri mašina valdo darbą, ir su tuo susijusių apribojimų priėmimas.

Dvi mašinos, du klausimai, į kuriuos reikia atsakyti pirmiausia

Paklauskite, kur turi įvykti būsenos pokytis, tada paklauskite, kuris įvykis jį atitinka. Jei pokytis yra kiekvieno naudotojo autorizacija arba kiekvieno kliento konfigūracijos sprendimas, jis priklauso ten, kur žinomas naudotojų katalogas: serveriui. Jei pokytis yra maršrutas, resolver nustatymas arba vietinė pagalbinė priemonė galiniame taške, jis priklauso galiniam taškui, ir tik galinis taškas gali tai padaryti.

Atsakyti į šiuos du klausimus atvirkštine tvarka yra būdas, kuriuo žmonės galiausiai bando įstumti paketinį failą į Windows nešiojamąjį kompiuterį. Serveris žino, kas prisijungė; nešiojamasis kompiuteris žino, kaip atrodo jo paties tinklo dėklas. Nė vienas neturi kito informacijos, ir bandymas paprastai nepavyksta tyliai, o ne su aiškia klaida.

Prieš abu verta užduoti trečią klausimą: ar platforma apskritai siūlo norimą kablį? Įrenginys, kuris pats generuoja savo konfigūraciją, gali nesiūlyti tų pačių įvykių pavadinimų, o darbalaukio klientas, importuojantis .ovpn failą, nebūtinai yra tas pats klientas, kuriam failas buvo parašytas. Iš anksto patvirtinus platformą, išvengsite projektavimo aplink kablį, kurio ten nėra. Tai taip pat pasako, kuri dokumentacija iš tikrųjų taikoma priešais esančiai mašinai.

Serverio pusės variantas: įvykis kiekvienam ryšiui

client-connect scenarijus vykdomas serverio proceso kontekste, kai prisijungia autentifikuotas klientas, ir gauna dokumentuotą ryšio informaciją, pavyzdžiui, common name ir priskirtą adresą. Tai tinkama vieta rašyti kiekvieno kliento konfigūracijos fragmentą, vykdyti politikos sprendimą arba įrašyti serveriui priklausančią būseną.

Skirtumas, kurį žmonės praleidžia, yra skirtumas tarp to kablio ir serverio up kablio. up kablys suveikia, kai serveris atidaro savo tunelio įrenginį, o tai daugelio klientų serveryje įvyksta vieną kartą paleidžiant demoną. Tai nėra kiekvieno prisijungimo įvykis, ir ten patalpintas kodas vykdomas paleidžiant paslaugą, o ne tada, kai naudotojai prisijungia.

Įrenginyje su žiniatinklio sąsaja naudokite palaikomą plėtinio mechanizmą, o ne redaguokite sugeneruotus demono failus. Sugeneruoti failai perrašomi kitą kartą išsaugant, ir perrašymas tyliai pašalina jūsų pakeitimą pačiu blogiausiu momentu. Laikykite plėtinio teksto kopiją už įrenginio ribų, kad programinės įrangos naujinimas neprarastų ir ketinimo.

Kliento pusės variantas: darbas, kuris turi būti atliktas vietoje

Bendruomenės klientas gali paleisti vietinį scenarijų, kai atsiranda tunelio įrenginys, ir vėl, kai įdiegiami maršrutai. Tai du skirtingi momentai, ir netinkamo pasirinkimas sukuria klasikines lenktynes, kai pagalbinė priemonė paleidžiama anksčiau, nei atsiranda maršrutas, nuo kurio ji priklauso.

Pagalbinė priemonė turi egzistuoti tame kliente, turi būti skaitoma ir vykdoma paskyros, kuri paleidžia klientą, ir turi būti leidžiama aiškiu script-security nustatymu. Scenarijus, kuris veikia, kai klientą paleidžiate kaip administratorius, nieko nepasako apie paslaugą prieš prisijungimą ar kito naudotojo sesiją.

Pavadinimai taip pat svarbūs. up kablys atitinka įrenginio sukūrimą, o route-up maršrutų įdiegimą, tačiau užduotis, kuriai reikia pasiekiamo privataus tinklo, turėtų tikrinti pasiekiamumą, o ne manyti, kad įrenginio sukūrimas reiškia, jog kiekvienas maršrutas, resolver įrašas ir programa yra paruošti.

Kodėl vykdomojo kodo push nėra pasirinkimuose

Push siunčiami nustatymai yra sąmoningai apriboti, o scenarijus vykdantys nustatymai priklauso kategorijoms, kurių serveris neturi teisės perduoti. Šis apribojimas egzistuoja todėl, kad alternatyva leistų sukompromituotam ar neteisingai sukonfigūruotam serveriui vykdyti savavališkas komandas kiekviename kliente, kuris kada nors prisijungia.

Scenarijų vykdymo įjungimas vietoje to nekeičia. Jūsų script-security nustatymas leidžia vietinius scenarijus, kuriuos pasirinkote jūs; jis nesuteikia serveriui teisės tiekti naujų.

Jei tikslas yra tiesiog įdiegti VPN maršrutus, naudokite palaikomą maršrutų konfigūraciją, o ne kurkite nuotolinio vykdymo schemą. Jei tikslas iš tikrųjų reikalauja vietinio kodo, platininkite jį per organizacijos galinių taškų valdymo priemones ir peržiūrėkite jį kaip bet kurią kitą programinę įrangą, veikiančią su naudotojo teisėmis.

Ką patikrinti prieš pasitikint bet kuriuo iš dviejų kablių

Užsirašykite keturis dalykus kiekvienam kabliui: mašiną, įvykio pavadinimą, paskyrą, kuria jis vykdomas, ir būsenos pokytį, kurį jis turėtų sukurti. Tada išbandykite ryšį, prisijungimą iš naujo ir valymo kelią, nes kablys, kuris prisijungiant iš naujo praranda būseną, yra blogesnis už tą, kuris niekada nebuvo paleistas.

Išbandykite su paskyra, kuri iš tikrųjų jį vykdys, tuo momentu, kai jis iš tikrųjų bus vykdomas. openvpn(8) vadove dokumentuojamos abi kablių šeimos ir push apribojimai; platforma, kurioje diegiate, dokumentuoja, ar ji juos apskritai teikia. Scenarijus, kuris pavyksta interaktyviame administratoriaus terminale, yra hipotezė, o ne patikrinimas.