Jūsų .ovpn failas gali vykdyti kodą, o ne tik maršrutizuoti srautą

Dauguma žmonių .ovpn failą skaito taip, kaip skaito maršrutizatoriaus nustatymų puslapį: adresai, maršrutai, šifrų sąrašas. Kodą vykdanti dalis yra netoli apačios, šalia instrukcijų, kurios atrodo kaip santechnikos darbai, ir veikia su tomis teisėmis, kurias klientas jau turi. Tai spraga, kurią išnaudoja nerūpestingas ar piktybinis profilis, ir tai taip pat spraga, kuri naudingą DNS pagalbininką po trijų savaičių paverčia palaikymo problema. Įvykio direktyva, saugumo lygis ir failo nuosavybė lemia, kas gali nutikti; scenarijaus turinys lemia, kas iš tikrųjų nutinka. Perskaitykite visus keturis prieš prisijungdami.

Profilis, paleidžiantis pagalbininką, yra programa, o ne nustatymų failas

Direktyvos, tokios kaip route ir dhcp-option, aprašo būseną, kurią klientas turėtų sukurti, o klientas jas traktuoja kaip duomenis. up scenarijus yra kitoks: klientas paleidžia jį kaip procesą ir duoda jam aplinką, pilną ryšio detalių, todėl viskas, ką parašė jo autorius, veikia su jūsų paskyros teisėmis. Nešiojamajame kompiuteryje, kur naudotojas yra administratorius, tai plačios durys failui, atėjusiam kaip priedas ar įklijuotam iš forumo gijos. Skirtumas ne stilistinis, tai skirtumas tarp konfigūracijos ir kodo.

Mitas, kurio verta atsisakyti, yra tas, kad profilis gali tik peradresuoti srautą. Pagalbininkas, vykdantis ip route add, ir tas, kuris vykdo curl prieš nuotolinį hostą, yra tas pats mechanizmas, o profilis iš išorės atrodo vienodai. Niekas failo išvaizdoje nepasako, kurį turite, todėl patikra turi pasiekti patį scenarijų.

Kas iš tikrųjų lemia vykdymą ir kaip atrodo tai leidžiančios eilutės

Pagalbininką valdo trys dalykai: jį įvardijanti įvykio direktyva, jį leidžiantis script-security lygis ir pačios kliento platformos įgyvendinimas. Profilis gali paprašyti kablio ir vis tiek nieko nepamatyti, nes mobilusis klientas arba apkarpytas darbalaukio rinkinys gali visiškai neįgyvendinti to įvykio. Taip pat profilis, prašantis daugiau leidimo, nei reikia jo funkcijai, kai ką pasako apie savo kilmę. Leidimo lygis yra galimybė, o ne patvirtinimas. Tai leidžiančios eilutės atrodo taip, o kelias stoja už jūsiškį.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

0 lygis atsisako išorinių programų, o 1 lygis, numatytasis, leidžia tik įtaisytus kliento vykdomuosius failus, todėl kabliui reikia 2 arba daugiau; 3 lygis egzistuoja daugiausia seniems slaptažodžiams perduoti ir jo geriau vengti. Profilis, pateikiamas su kabliu, turi turėti ir direktyvą, ir tą lygį, todėl viena eilutė netoli failo apačios nusipelno tokio patikrinimo kaip sertifikato blokas. OpenVPN vadove išvardijami leidimų lygiai, ir jo formuluotę verta skaityti šalia to, ko profilis iš tikrųjų prašo.

Nuosavybė, kelias ir kuo maitinamas pagalbininkas

Profilis, kuriuo pasitikite, bet kuris nurodo scenarijų, kurį gali perrašyti kita paskyra, nėra patikimas susitarimas, nes vakarykštė patikra nebeaprašo, kas veikia šiandien. Patikrinkite pagalbininko savininką ir režimą bei įsitikinkite, kad sukonfigūruotas kelias veda prie failo, kurį tikrinote, o ne prie pavadinimo, kurį gali nustelbti kažkas kita. Argumentai ir aplinka nusipelno to paties žvilgsnio: klientas perduoda ryšio detales kabliui, o pagalbininkas, registruojantis visą savo aplinką, gali rašyti prisijungimo duomenis į palaikymo bilietą. Pirmenybę teikite dokumentuotai operatoriaus ar platformos integracijai, o ne DNS scenarijui, nukopijuotam iš nesusijusio įrašo, nes dvi sprendiklių tvarkyklės, besiginčijančios dėl to paties failo, sukelia gedimą, kuris atrodo kaip sugedęs VPN.

Kai pranešate apie nepavykusį kablį, redaguokite aplinką prieš kurdami ją bet kur. Derinimui padedantis išrašas taip pat gali nešti prieigos raktą, kuris jus autentifikuoja.

Valymo gedimai pasirodo po to, kai tunelis dingsta

up pagalbininkas prideda maršrutus ir sprendiklio nustatymus, o down pagalbininkas turėtų juos vėl pašalinti. Kai down kablio nėra, jis tyliai nepavyksta arba niekada nevykdomas, nes klientas buvo užmuštas, likučiai pergyvena sesiją. Tada srautas eina keliu, kurio niekas neplanavo, o vardai sprendžiami per sprendiklį, kuris turėjo būti pašalintas, nors pats tunelis atrodo sveikas. Tie simptomai ateina po atsijungimo, todėl kaltinamas tinklas, o ne profilis.

Išbandykite išardymą kaip atskirą žingsnį: pakelkite tunelį, užsirašykite maršrutus ir sprendiklį, nuleiskite jį, tada patvirtinkite, kad abu dingo. Profilis, kuris jungiasi švariai, vis tiek gali palikti būseną, o nulinis pagalbininko išėjimo kodas neįrodo, kad sprendiklis atsidūrė ten, kur manote.

Pagalbininko peržiūra ir išėjimo išsaugojimas

Perskaitykite scenarijų nuo pradžios iki pabaigos, ieškodami trijų dalykų: komandų, kurioms reikia teisių, kietai užkoduotų kelių, kurių jūsų sistemoje gali nebūti, ir bet kokio tinklo iškvietimo, kurį jis atlieka. Tada pažiūrėkite, kaip jis nepavyksta, nes klaidas praryjantis pagalbininkas konfigūracijos klaidą paverčia mįsle. Jei negalite vienu sakiniu pasakyti, ką daro scenarijus ir kas gali jį pakeisti, nesate pasiruošę jį įjungti. Profilis, prašantis daugiau teisių, nei reikalauja tas sakinys, yra sustojimo ženklas.

Laikykite paskutinį veikiantį profilį ir jo nurodytą pagalbininką apsaugotoje saugykloje, pažymėję abi versijas, kad atsukimas būtų kopija, o ne atstatymas blogiausiu momentu. Jei pagalbininkas egzistuoja tik distribucijai ar kliento versijai, kuriai jo nebereikia, atsisakykite jo konfigūracijoje, kuri valdo nustatymą, o ne kelkite teises, kol klaidos nesiliaus. Tai ir yra išėjimas: mažiau judančių dalių, o ne daugiau leidimų.