Előre létrehozott tun az OpenVPN-ben: a két tulajdonosi modell összevetése

Valaki előre létrehozta a tun1-t, a profil dev tun1-t mond, és a kapcsolat mégsem csatlakozik. A név jelenléte a gazdagépen szinte semmit nem mond, mert a csatlakozás a névtértől, az eszköz típusától, a kapcsolat birtokosától és attól függ, mit tehet a démon. Az eszköz újrafelhasználása olyan döntést is kikényszerít, amelyet az alapértelmezett konfiguráció elrejt: melyik összetevő írja a címeket és az útvonalakat. A két elrendezés hibamódjai sokkal jobban különböznek, mint a konfigurációs sorok, ezért döntsön a profil szerkesztése előtt.

A név nem csatlakozás

dev tun1 azt a megnevezett interfészt kéri az OpenVPN-től, és a hagyományos felhasználói térben futó buildek megpróbálják megnyitni. Ha a név nem követi a szokásos tun vagy tap mintát, a profilnak megfelelő dev-type is kell, mert a típust soha nem egy karakterláncból következtetik ki. A TAP-eszköz nem más címkével ellátott TUN-eszköz: a rossz eszköz csatlakoztatása vagy azonnal meghiúsul, vagy olyan kapcsolatot hoz létre, amely olyan kereteket szállít, amelyekre senki nem számít. Minden más előtt ellenőrizze a típust, mert minden későbbi ellenőrzés feltételezi, hogy a két fél egyetért benne. Utána erősítse meg, hogy a folyamat valóban meg tudja nyitni az eszközt, nem csak látja.

dev tun1
dev-type tun

A hálózati interfész és a /dev/net/tun különböző objektumok: az egyik névtéren belüli kapcsolat, a másik az a karakteres eszköz, amelyet a felhasználói térben futó program a csatlakozáshoz használ. A Linux TUN/TAP dokumentáció leírja ezt a csatlakozási útvonalat és az állandó eszközök tulajdonlási szabályait. Egy root héj, amely képes a ip link futtatására, csak azt bizonyítja, hogy a héjnak vannak jogosultságai, nem azt, hogy a démonnak is. Az eszközcsomópont tulajdonlása, a szolgáltatás képességkészlete és a felhasználó, akinek a nevében fut mindegyikének össze kell hangolódnia, mielőtt a megnyitás sikerül.

Az az eszköz, amely létezik és nem nyitható meg, tulajdonlási probléma, nem útvonalválasztási. A hibakeresés során úgy is kezelje, különben a délután olyan útvonaltáblák olvasásával telik el, amelyek soha nem voltak a probléma.

Ki konfigurálja a kapcsolatot: két tulajdonosi modell

Az első modellben az OpenVPN a kapcsolat felhozatalának részeként konfigurálja a címeket és az útvonalakat. Ez az alapértelmezett viselkedés és a legkönnyebben átgondolható, mert egyetlen összetevő hozza létre az állapotot, majd megint eltávolítja. A második modellben egy külső kezelő birtokolja az interfészt, és a ifconfig-noexec megakadályozza, hogy az OpenVPN lefuttassa a címkonfigurációs parancsait, és a paramétereket szkripteknek adja át. Ekkor a kezelőnek magának kell alkalmaznia a helyes helyi és partnerkonfigurációt, ami több munka, mint amit az opció neve sugall. A kettő közötti választás arról szól, ki változtathatja meg a kapcsolatot, amíg az fel van hozva.

A ifconfig-noexec csak a címekre terjed ki: az útvonaltábla érintetlen marad, az útvonalak konfigurációja pedig a route-noexec-hez tartozik. Kezelje a két utasítást külön vezérlőként, külön tulajdonosokkal, mert az egyik beállítása és a másik feltételezése a félkész kapcsolatok gyakori forrása. Rétegenként pontosan egy tulajdonost válasszon, a címeket egy helyen és az útvonalakat egy helyen. Egy hálózatkezelő és egy VPN-segéd, amelyek mindketten címeket írnak, az az út, ahogyan egy bontás töröl egy állapotot, amelyre a másik fél még támaszkodik.

Vizsgálja meg az eszközt abból a névtérből, amely számít

Vizsgálja meg az eszközt abból a névtérből, amelyben a VPN-folyamat fut, nem abból, amelyben a héja véletlenül van. A két alábbi parancs különböző kérdésekre válaszol, és a különbség akkor látszik, amikor a gazdagép olyan interfészt lát, amelyet egy konténer nem lát. A megadott sorrendben futtassa őket, mert a másodiknak csak akkor van értelme, ha tudja, létezik-e egyáltalán a kapcsolat.

ip -details link show dev tun1
ip tuntap show

Az első parancs úgy nyomtatja ki a kapcsolatot, ahogy a kernel látja, a jelzőkkel és az interfész típusával együtt, és így erősíti meg, hogy ez a szándékolt eszköz. A második az állandó tun/tap bejegyzéseket listázza, amelyek anélkül léteznek, hogy bármely folyamat tartaná őket. Az az interfész, amely a kijelölt tulajdonosára vár, más helyzet, mint egy másik VPN-hez csatlakoztatott élő alagút, és csak a második magyarázza meg, miért hiúsul meg a saját csatlakoztatása. Keresse meg az eszközt tartó folyamatot, mielőtt bármit változtat, mert az állandó bejegyzésnek és a foglalt interfésznek más a javítása.

A többsoros támogatás egy adott illesztőprogram-elrendezés a saját követelményeivel, nem engedély arra, hogy nem kapcsolódó folyamatok egy interfészt osszanak meg. Egy másik tulajdonos élő munkamenete koordinációs probléma, és semmilyen profilszerkesztés nem oldja meg.

Kétféle állandóság

A kernel állandósága és a persist-tun olyan élettartamokat írnak le, amelyeket könnyű összekeverni és drága összetéveszteni. Az állandó eszköz bármely folyamattól függetlenül létezik, ezért túléli a leállítást, és a következő indítás újra használhatja. A persist-tun az erőforrásokat egyetlen OpenVPN-folyamaton belüli támogatott puha újraindításokon át őrzi meg, sokkal rövidebb távon. Egyik sem ígéri, hogy a szolgáltatás leállítása helyben hagyja az útvonalakat és a címeket, és a láthatóan maradó interfész nem bizonyítéka egy működő titkosított munkamenetnek.

A hátteret is erősítse meg, mert az előre létrehozott interfész semmit nem mond arról, melyik megvalósítás nyitja meg. A közvetlen adatútvonalat hordozó közösségi buildek megpróbálják használni, hacsak a tervezés mást nem mond. Ahol a verzió támogatja a kapcsolót, a disable-dco inkább a felhasználói tér útvonalát választja; a régebbi motoroknak és más klienseknek nincs ilyen utasításuk, ezért tartsa a verziófeltételt az opció mellett, ahelyett hogy feltételezné az alkalmazhatóságát.

Mi törik el, ha csak az indítást teszteljük

Egy tulajdonlási megállapodás átmehet az első teszten és elbukhat az utolsón, ami az indítást önmagában gyenge ellenőrzéssé teszi. Nézzen inkább két átmenetet: egy puha újraindítást és egy teljes leállítást, amelyet indítás követ.

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

Az indítás a könnyű eset: az egység feljön, a kapcsolat megjelenik, és az állapotkimenet megnevezi a betöltött profilt. A csatlakozás az a pillanat, amikor a démon megnyitja az eszközt, ezért a kapcsolatellenőrzést azután futtassa, hogy az egység aktívnak jelenti magát, nem előtte. Ha a kapcsolat létezik, miközben az állapot még aktiválódik, egy olyan állandó eszközt lát, amelyhez még senki nem csatlakozott, nem egy működő alagutat. Engedjen valódi forgalmat a kapcsolaton, mielőtt továbblép, mert a használható útvonal nélküli csatlakoztatott interfész is még kudarc.

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

A puha újraindításnak használható munkamenetet és sértetlen erőforrásokat kell hagynia, és ezt a munkát végzi a persist-tun. A teljes leállítás az a pont, ahol egy külső kezelő leleplezi magát: ha a kapcsolat vagy annak címei túlélik a leállítást, valaki más birtokolja őket, és ez vagy az a dokumentált állapot, vagy az a hiba, amelyet épp most talált. Jegyezze fel mindkét megfigyelést a profil mellé, hogy a következő változtatás bizonyítékból induljon ki, ne egy diagramból.