OpenVPN valdymo lizdas: valdymo kanalas, o ne metrikos

Vieną kartą paprašykite valdymo sąsajos būsenos ir ji pradeda atrodyti kaip būsenos prievadas. Bet tai ne ji. Kai klientas priimamas, jis gali siųsti protokolo valdymo komandas, o paskyra, kuri vykdo tą klientą, paveldi viską, ką tos komandos gali padaryti demonui. Traktuoti tai kaip tik skaitymo srautą yra klaida, kuri stebėjimo integraciją paverčia neautentifikuota konsole.

Įsitikinimas ir kiek jis kainuoja

Įsitikinimas yra tas, kad valdymo klausytojas prilygsta metrikų galiniam taškui: prijunkite rinkėją, perskaitykite skaitiklius, eikite toliau. Iš tikrųjų rinkėjas atidaro sesiją su valdymo galimybėmis, ir kiekviena kita jūsų prielaida apie diegimą dabar priklauso nuo to, ar tas rinkėjas elgsis tinkamai.

Nieko sąsajoje nereklamuoja tik skaitymo režimo. Nėra stebėtojo vaidmens, kurį būtų galima pasirinkti, o vartotojo vardas konfigūracijoje jo nesukuria.

Ką iš tikrųjų turi priimtas klientas

Bendruomenės demonas priima tik vieną aktyvų valdymo klientą vienu metu. Viena vieta reiškia, kad GUI, scenarijus ir stebėjimo agentas negali prisijungti visi; antrasis laukia arba nepavyksta, kol pirmasis laiko sesiją. Jei jūsų projektas numato vienu metu veikiančius skaitytojus, jis jau neteisingas.

Kur pakanka periodinės momentinės kopijos, būsenos failo išvestis duoda tuos pačius skaičius be gyvos sesijos. To failo rašymas intervalais ir skaitymas įprastomis failų teisėmis visiškai laiko rinkėją už valdymo plokštumos, ir tai yra tvarka, kurios daugumai stebėjimo iš tikrųjų reikia.

Nuosavas lizdas, o ne atviras

Unix domeno lizdas laiko valdymo kelią už tinklo, o tai pašalina iš problemos kintantį tunelio adresą. Tai nepašalina leidimų klausimo. Pirminis katalogas turi būti įrašomas paslaugos paskyros ir pasiekiamas valdiklio paskyros, ir tai yra du atskiri leidimai:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

Slaptažodžio faile pirmoje eilutėje saugoma valdymo paslaptis. Saugokite tą failą kaip bet kuriuos kitus prisijungimo duomenis ir laikykite jo turinį atokiau nuo žurnalų ir palaikymo bilietų. Vartotojo ir grupės apribojimai yra lygiaverčio patikros Unix lizde, o ne failų sistemos leidimai, todėl numatytam procesui reikia ir failo prieigos, ir atitinkamos tapatybės.

Padaryti lizdą prieinamą visam pasauliui, kad išnyktų leidimų klaida, yra vienintelė pataisa, kurios reikia vengti. Ji vietinį valdymo kanalą paverčia kažkuo, ką gali valdyti bet kuris pagrindinio kompiuterio procesas.

Paskelbimas per TCP nėra tas pats projektas

Klausytojo perkėlimas į TCP prievadą nepadaro jo saugesnio ar patogesnio. Valdymo slaptažodis siunčiamas atviru tekstu, todėl TCP klausytojas atskleidžia ir prisijungimo duomenis, ir sesiją kiekvienam, kas gali stebėti kelią. Pasiekti jį iš kito pagrindinio kompiuterio reikia įgalioto administravimo kanalo arba mažo vietinio agento, kuris atskleidžia tik reikiamus stebėjimus.

Slaptažodis atviro teksto transportu yra autentifikacija be konfidencialumo, ir šis derinys yra blogesnis, nei atrodo, nes jaučiasi apsaugotas.

Paleidimo priklausomybės, kurių neprašėte

Keli valdymo parametrai keičia demono gyvavimo ciklą. Paleidimo sulaikymas, kol prisijungs valdiklis, arba nutraukimas, kai valdiklis dingsta, paverčia pasirenkamą stebėtoją kieta priklausomybe. Tada lūžtantis stebėjimo agentas nusineštų ir tunelį.

Peržiūrėkite tuos parametrus prieš įjungdami ką nors, išskyrus patį lizdą. Pasirenkamas stebėjimas turėtų likti pasirenkamas, o perkrovimo politika neturėtų būti susieta su rinkėju, pridėtu grafikams.

Lizdo failas, likęs po nepavykusio proceso, nėra įrodymas, kad klausytojas egzistuoja. Prieš pašalindami nustatykite, kuri instancija valdo kelią, ir naudokite paslaugos atkūrimo eigą, o ne trinkite failus veikiančio demono viduje.

Kaip atrodo priėmimas

Projektą apima keturios patikros: numatyta valdiklio tapatybė prisijungia, procesas be tos tapatybės atmetamas, demonas išgyvena valdiklį, kuris atsijungia be įspėjimo, ir tunelis vis tiek perduoda srautą po kontroliuojamo perkrovimo. Sėkmingas valdymo ryšys įrodo tik valdymo plokštumą. Jis nieko nesako apie tai, ar veikia privačių programų srautas, todėl tai išbandykite atskirai. Užrašykite keturis rezultatus ten, kur juos ras kitas operatorius.

Valdymo sąsajos dokumentacija aprašo vieno kliento modelį ir privilegijuotą protokolo pobūdį, ir tai yra dalis, kurią verta perskaityti prieš nukreipiant į ją prietaisų skydelį.