Iš anksto sukurtas tun OpenVPN: dviejų nuosavybės modelių palyginimas

Kažkas iš anksto sukūrė tun1, profilyje nurodyta dev tun1, o ryšys vis tiek neprisijungia. Vardo buvimas hoste beveik nieko nesako, nes prisijungimas priklauso nuo vardų erdvės, įrenginio tipo, nuo to, kas valdo saitą, ir nuo to, ką leidžiama daryti tarnybai. Įrenginio pakartotinis naudojimas taip pat primeta sprendimą, kurį numatytoji konfigūracija slepia: kuris komponentas rašo adresus ir maršrutus. Dviejų išdėstymų gedimo būdai skiriasi daug labiau nei konfigūracijos eilutės, todėl nuspręskite prieš redaguodami profilį.

Vardas nėra prisijungimas

dev tun1 prašo OpenVPN to vardinės sąsajos, ir tradiciniai naudotojo erdvės rinkiniai bandys ją atidaryti. Jei vardas neatitinka įprasto tun arba tap šablono, profiliui taip pat reikia atitinkamo dev-type, nes tipas niekada neišvedamas iš eilutės. TAP įrenginys nėra TUN įrenginys su kita etikete: netinkamo prijungimas arba iškart nepavyksta, arba sukuria saitą, kuris perduoda kadrus, kurių niekas nesitiki. Patikrinkite tipą prieš visa kita, nes kiekviena vėlesnė patikra daro prielaidą, kad abi pusės dėl jo sutaria. Tada įsitikinkite, kad procesas iš tiesų gali atidaryti įrenginį, o ne tik jį matyti.

dev tun1
dev-type tun

Tinklo sąsaja ir /dev/net/tun yra skirtingi objektai: vienas yra saitas vardų erdvėje, kitas – simbolinis įrenginys, kurį naudotojo erdvės programa naudoja prisijungimui. Linux TUN/TAP dokumentacija aprašo tą prisijungimo kelią ir nuolatinių įrenginių nuosavybės taisykles. Root apvalkalas, galintis paleisti ip link, įrodo tik tai, kad apvalkalas turi privilegijų, o ne kad jų turi tarnyba. Įrenginio mazgo nuosavybė, tarnybos galimybių rinkinys ir naudotojas, kuriuo ji veikia – viskas turi sutapti, kad atidarymas pavyktų.

Įrenginys, kuris egzistuoja ir neatsidaro, yra nuosavybės problema, o ne maršrutizavimo. Taip ir traktuokite jį derindami, kitaip popietė nueis skaitant maršrutų lenteles, kurios niekada nebuvo problema.

Kas konfigūruoja saitą: du nuosavybės modeliai

Pirmajame modelyje OpenVPN konfigūruoja adresus ir maršrutus kaip ryšio kėlimo dalį. Tai numatytasis elgesys ir lengviausiai suprantamas, nes vienas komponentas sukuria būseną ir paskui ją pašalina. Antrajame modelyje sąsają valdo išorinis valdytojas, o ifconfig-noexec neleidžia OpenVPN vykdyti adresų konfigūravimo komandų ir perduoda parametrus scenarijams. Tada valdytojas turi pats pritaikyti teisingą vietinę ir partnerio konfigūraciją, o tai daugiau darbo, nei rodo parinkties pavadinimas. Rinktis tarp jų – klausimas, kas gali keisti saitą, kol jis pakeltas.

ifconfig-noexec apima tik adresus: maršrutų lentelė lieka nepaliesta, o maršrutų konfigūracija priklauso route-noexec. Traktuokite abi direktyvas kaip atskiras valdymo priemones su atskirais savininkais, nes vienos nustatymas ir kitos prielaida yra įprastas pusiau sukonfigūruotų saitų šaltinis. Pasirinkite tiksliai vieną savininką kiekvienam sluoksniui: adresai vienoje vietoje, maršrutai vienoje vietoje. Tinklo valdytojas ir VPN pagalbininkas, abu rašantys adresus, – štai kaip atjungimas ištrina būseną, nuo kurios kita pusė dar priklauso.

Tikrinkite įrenginį iš tos vardų erdvės, kuri svarbi

Tikrinkite įrenginį iš vardų erdvės, kurioje veikia VPN procesas, o ne iš tos, kurioje atsitiktinai yra jūsų apvalkalas. Dvi žemiau esančios komandos atsako į skirtingus klausimus, o skirtumas pasirodo, kai hostas mato sąsają, kurios konteineris nemato. Vykdykite jas nurodyta tvarka, nes antroji prasminga tik tada, kai žinote, ar saitas apskritai egzistuoja.

ip -details link show dev tun1
ip tuntap show

Pirmoji komanda atspausdina saitą taip, kaip jį mato branduolys, įskaitant vėliavas ir sąsajos tipą, ir taip patvirtinate, kad tai tas įrenginys, kurį turėjote omenyje. Antroji išvardija nuolatinius tun/tap įrašus, kurie egzistuoja be jokio juos laikančio proceso. Sąsaja, laukianti paskirto savininko, yra kita situacija nei gyvas tunelis, prijungtas prie kitos VPN, ir tik antroji paaiškina, kodėl jūsų pačių prisijungimas nepavyksta. Prieš ką nors keisdami raskite įrenginį laikantį procesą, nes nuolatinis įrašas ir užimta sąsaja turi skirtingus sprendimus.

Daugiaeiliškumo palaikymas yra konkretus tvarkyklės išdėstymas su savo reikalavimais, o ne leidimas nesusijusiems procesams dalytis viena sąsaja. Kito savininko gyva sesija yra koordinavimo problema, ir joks profilio pakeitimas jos neišsprendžia.

Dvi skirtingos patvarumo rūšys

Branduolio patvarumas ir persist-tun apibūdina gyvavimo trukmes, kurias lengva supainioti ir brangu sumaišyti. Nuolatinis įrenginys egzistuoja nepriklausomai nuo jokio proceso, todėl išgyvena sustabdymą ir kitas paleidimas gali jį naudoti iš naujo. persist-tun išsaugo išteklius per palaikomus minkštus perkrovimus viename OpenVPN procese, daug trumpesnis horizontas. Nė vienas nežada, kad sustabdžius tarnybą maršrutai ir adresai liks vietoje, o sąsaja, kuri lieka matoma, nėra veikiančios šifruotos sesijos įrodymas.

Patvirtinkite ir backend, nes iš anksto sukurta sąsaja nieko nesako apie tai, kuri realizacija ją atidarys. Bendruomenės rinkiniai, turintys tiesioginį duomenų kelią, bandys ją naudoti, jei dizainas nenumato kitaip. Ten, kur versija palaiko jungiklį, disable-dco vietoj to pasirenka naudotojo erdvės kelią; senesni varikliai ir kiti klientai tokios direktyvos neturi, todėl laikykite versijos sąlygą šalia parinkties, o ne manykite, kad ji taikoma.

Kas sugenda, kai tikrinamas tik paleidimas

Nuosavybės susitarimas gali praeiti pirmąjį bandymą ir nepraeiti paskutinio, todėl paleidimas vienas yra silpna patikra. Stebėkite du perėjimus: minkštą perkrovimą ir visišką sustabdymą, po kurio seka paleidimas.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Paleidimas yra lengvas atvejis: vienetas pakyla, saitas atsiranda, o būsenos išvestis įvardija įkeltą profilį. Prisijungimas yra momentas, kai tarnyba atidaro įrenginį, todėl saito patikrą vykdykite po to, kai vienetas praneša esąs aktyvus, o ne prieš tai. Jei saitas egzistuoja, kol būsena dar aktyvuojama, matote nuolatinį įrenginį, prie kurio dar niekas neprisijungė, o ne veikiantį tunelį. Praleiskite tikrą srautą per saitą prieš eidami toliau, nes prijungta sąsaja be naudojamo maršruto vis tiek yra nesėkmė.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Minkštas perkrovimas turėtų palikti sesiją naudojamą, o išteklius sveikus, ir būtent tą darbą atlieka persist-tun. Visiškas sustabdymas yra vieta, kur išorinis valdytojas atsiskleidžia: jei saitas ar jo adresai išgyvena sustabdymą, juos valdo kažkas kitas, ir tai yra arba jūsų dokumentuota būsena, arba klaida, kurią ką tik radote. Užrašykite abu pastebėjimus šalia profilio, kad kitas pakeitimas prasidėtų nuo įrodymų, o ne nuo diagramos.