Vopred vytvorený tun v OpenVPN: porovnanie dvoch modelov vlastníctva

Niekto vopred vytvoril tun1, profil hovorí dev tun1, a pripojenie sa stále nepripája. Samotná existencia názvu na hostiteľovi nehovorí takmer nič, pretože pripojenie závisí od menného priestoru, typu zariadenia, od toho, kto vlastní prepojenie a čo je démonovi dovolené. Opätovné použitie zariadenia tiež vynucuje rozhodnutie, ktoré predvolená konfigurácia skrýva: ktorý komponent zapisuje adresy a trasy. Režimy zlyhania oboch usporiadaní sa líšia oveľa viac ako riadky konfigurácie, preto sa rozhodnite pred úpravou profilu.

Názov nie je pripojenie

dev tun1 žiada OpenVPN o toto pomenované rozhranie a tradičné zostavy v používateľskom priestore sa ho pokúsia otvoriť. Ak názov nenasleduje zvyčajný vzor tun alebo tap, profil potrebuje aj zodpovedajúci dev-type, pretože typ sa nikdy neodvodzuje z reťazca. Zariadenie TAP nie je zariadenie TUN s inou etiketou: pripojenie nesprávneho buď okamžite zlyhá, alebo vytvorí prepojenie prenášajúce rámce, ktoré nikto neočakáva. Skontrolujte typ pred všetkým ostatným, pretože každá ďalšia kontrola predpokladá, že obe strany sa na ňom zhodujú. Potom potvrďte, že proces dokáže zariadenie skutočne otvoriť, a nielen ho vidieť.

dev tun1
dev-type tun

Sieťové rozhranie a /dev/net/tun sú rozdielne objekty: jedno je prepojenie v mennom priestore, druhé je znakové zariadenie, ktoré program v používateľskom priestore používa na pripojenie. Dokumentácia Linux TUN/TAP opisuje túto cestu pripojenia a pravidlá vlastníctva trvalých zariadení. Root shell, ktorý dokáže spustiť ip link, dokazuje len to, že shell má oprávnenia, nie že ich má démon. Vlastníctvo uzla zariadenia, množina schopností služby a používateľ, pod ktorým beží sa musia všetky zhodovať, aby otvorenie uspelo.

Zariadenie, ktoré existuje a nedá sa otvoriť, je problém vlastníctva, nie problém smerovania. Tak ho aj berte pri ladení, inak popoludnie prejde čítaním smerovacích tabuliek, ktoré nikdy neboli problémom.

Kto konfiguruje prepojenie: dva modely vlastníctva

V prvom modeli OpenVPN konfiguruje adresy a trasy ako súčasť zdvíhania pripojenia. Je to predvolené správanie a najľahšie na uvažovanie, pretože jeden komponent vytvára stav a potom ho odstraňuje. V druhom modeli rozhranie vlastní externý správca a ifconfig-noexec bráni OpenVPN vykonávať jeho príkazy konfigurácie adries a odovzdáva parametre skriptom. Správca potom musí sám aplikovať správnu lokálnu konfiguráciu a konfiguráciu partnera, čo je viac práce, než naznačuje názov možnosti. Výber medzi nimi je otázka, kto môže meniť prepojenie, kým je zdvihnuté.

ifconfig-noexec pokrýva iba adresy: smerovacia tabuľka zostáva nedotknutá a konfigurácia trás patrí route-noexec. Berte obe direktívy ako samostatné ovládania so samostatnými vlastníkmi, pretože nastavenie jednej a predpoklad druhej je častým zdrojom polovične nakonfigurovaných prepojení. Vyberte presne jedného vlastníka na vrstvu, adresy na jednom mieste a trasy na jednom mieste. Správca siete a pomocník VPN, ktorí obaja zapisujú adresy, je spôsob, akým odpojenie maže stav, od ktorého druhá strana ešte závisí.

Prezrite zariadenie z menného priestoru, na ktorom záleží

Prezrite zariadenie z menného priestoru, v ktorom beží proces VPN, nie z toho, v ktorom sa náhodou nachádza váš shell. Dva nižšie uvedené príkazy odpovedajú na rôzne otázky a rozdiel sa prejaví, keď hostiteľ vidí rozhranie, ktoré kontajner nevidí. Spustite ich v uvedenom poradí, pretože druhý má zmysel až vtedy, keď viete, či prepojenie vôbec existuje.

ip -details link show dev tun1
ip tuntap show

Prvý príkaz vypíše prepojenie tak, ako ho vidí jadro, vrátane príznakov a typu rozhrania, a tak potvrdíte, že ide o zamýšľané zariadenie. Druhý vypisuje trvalé záznamy tun/tap, ktoré existujú bez toho, aby ich držal akýkoľvek proces. Rozhranie, ktoré čaká na svojho určeného vlastníka, je iná situácia ako živý tunel pripojený k inej VPN, a iba druhý vysvetľuje, prečo vaše vlastné pripojenie zlyháva. Nájdite proces, ktorý zariadenie drží, skôr než čokoľvek zmeníte, pretože trvalý záznam a obsadené rozhranie majú rôzne riešenia.

Podpora viacerých frontov je konkrétne usporiadanie ovládača s vlastnými požiadavkami, nie povolenie nesúvisiacim procesom zdieľať jedno rozhranie. Živá relácia iného vlastníka je problém koordinácie a žiadna úprava profilu ju nerieši.

Dva druhy trvalosti

Trvalosť jadra a persist-tun opisujú životnosti, ktoré sa ľahko zamieňajú a draho pletú. Trvalé zariadenie existuje nezávisle od akéhokoľvek procesu, takže prežije zastavenie a nasledujúce spustenie ho môže znova použiť. persist-tun zachováva zdroje cez podporované mäkké reštarty v rámci jedného procesu OpenVPN, oveľa kratší horizont. Ani jedno nesľubuje, že zastavenie služby ponechá trasy a adresy na mieste, a rozhranie, ktoré zostane viditeľné, nie je dôkazom fungujúcej šifrovanej relácie.

Potvrďte aj backend, pretože vopred vytvorené rozhranie nič nehovorí o tom, ktorá implementácia ho otvorí. Komunitné zostavy s priamou dátovou cestou sa ho pokúsia použiť, ak dizajn nehovorí inak. Tam, kde verzia podporuje prepínač, disable-dco namiesto toho vyberie cestu v používateľskom priestore; staršie motory a iní klienti takú direktívu nemajú, preto držte podmienku verzie vedľa možnosti a nepredpokladajte, že platí.

Čo sa pokazí, keď sa testuje iba spustenie

Dohoda o vlastníctve môže prejsť prvým testom a zlyhať na poslednom, čo robí samotné spustenie slabou kontrolou. Sledujte namiesto toho dva prechody: mäkký reštart a úplné zastavenie, po ktorom nasleduje spustenie.

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

Spustenie je ľahký prípad: jednotka sa zdvihne, prepojenie sa objaví a výstup stavu pomenuje načítaný profil. Pripojenie je moment, keď démon otvorí zariadenie, preto kontrolu prepojenia spustite po tom, ako jednotka oznámi, že je aktívna, a nie predtým. Ak prepojenie existuje, kým sa stav ešte aktivuje, pozeráte sa na trvalé zariadenie, ku ktorému sa ešte nikto nepripojil, nie na fungujúci tunel. Prepustite cez prepojenie skutočnú prevádzku, skôr než budete pokračovať, pretože pripojené rozhranie bez použiteľnej trasy je stále zlyhanie.

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

Mäkký reštart by mal nechať reláciu použiteľnú a zdroje neporušené, a práve tú prácu vykonáva persist-tun. Úplné zastavenie je miesto, kde sa externý správca prezradí: ak prepojenie alebo jeho adresy prežijú zastavenie, vlastní ich niekto iný, a to je buď stav, ktorý ste zdokumentovali, alebo chyba, ktorú ste práve našli. Zaznamenajte obe pozorovania vedľa profilu, aby nasledujúca zmena začala od dôkazov a nie od diagramu.