Wstępnie utworzony tun w OpenVPN: porównanie dwóch modeli własności

Ktoś wstępnie utworzył tun1, profil mówi dev tun1, a połączenie nadal się nie podłącza. Sama obecność nazwy na hoście nie mówi prawie nic, bo podłączenie zależy od przestrzeni nazw, typu urządzenia, tego kto posiada łącze i co wolno demonowi. Ponowne użycie urządzenia wymusza też decyzję, którą ukrywa konfiguracja domyślna: który komponent zapisuje adresy i trasy. Sposoby awarii obu układów różnią się znacznie bardziej niż linie konfiguracji, więc zdecyduj przed edycją profilu.

Nazwa nie jest podłączeniem

dev tun1 prosi OpenVPN o ten nazwany interfejs, a tradycyjne kompilacje w przestrzeni użytkownika spróbują go otworzyć. Jeśli nazwa nie podąża za zwykłym wzorcem tun lub tap, profil potrzebuje też pasującego dev-type, bo typ nigdy nie jest wnioskowany z ciągu znaków. Urządzenie TAP nie jest urządzeniem TUN z inną etykietą: podłączenie niewłaściwego albo od razu zawodzi, albo tworzy łącze niosące ramki, których nikt się nie spodziewa. Sprawdź typ przed wszystkim innym, bo każde późniejsze sprawdzenie zakłada, że obie strony się co do niego zgadzają. Następnie potwierdź, że proces naprawdę może otworzyć urządzenie, a nie tylko je widzieć.

dev tun1
dev-type tun

Interfejs sieciowy i /dev/net/tun to różne obiekty: jeden jest łączem wewnątrz przestrzeni nazw, drugi to urządzenie znakowe, którego program w przestrzeni użytkownika używa do podłączenia. Dokumentacja Linux TUN/TAP opisuje tę ścieżkę podłączenia i zasady własności trwałych urządzeń. Powłoka root, która może uruchomić ip link, dowodzi tylko, że powłoka ma uprawnienia, a nie że ma je demon. Własność węzła urządzenia, zbiór zdolności usługi i użytkownik, pod którym działa muszą się wszystkie zgadzać, zanim otwarcie się powiedzie.

Urządzenie, które istnieje i nie daje się otworzyć, to problem własności, a nie routingu. Traktuj je tak podczas debugowania, bo inaczej popołudnie zejdzie na czytaniu tabel routingu, które nigdy nie były problemem.

Kto konfiguruje łącze: dwa modele własności

W pierwszym modelu OpenVPN konfiguruje adresy i trasy jako część podnoszenia połączenia. To zachowanie domyślne i najłatwiejsze do przemyślenia, bo jeden komponent tworzy stan, a potem go usuwa. W drugim modelu interfejsem zarządza zewnętrzny menedżer, a ifconfig-noexec powstrzymuje OpenVPN przed uruchamianiem jego poleceń konfiguracji adresów i przekazuje parametry skryptom. Wtedy menedżer musi sam zastosować poprawną konfigurację lokalną i drugiej strony, co jest większą pracą, niż sugeruje nazwa opcji. Wybór między nimi to pytanie o to, kto może zmieniać łącze, gdy jest podniesione.

ifconfig-noexec obejmuje tylko adresy: tabela routingu pozostaje nietknięta, a konfiguracja tras należy do route-noexec. Traktuj obie dyrektywy jako osobne mechanizmy z osobnymi właścicielami, bo ustawienie jednego i założenie drugiego to częste źródło połowicznie skonfigurowanych łączy. Wybierz dokładnie jednego właściciela na warstwę, adresy w jednym miejscu i trasy w jednym miejscu. Menedżer sieci i pomocnik VPN, którzy obaj zapisują adresy, to sposób, w jaki rozłączenie usuwa stan, od którego druga strona wciąż zależy.

Sprawdź urządzenie z tej przestrzeni nazw, która ma znaczenie

Sprawdź urządzenie z przestrzeni nazw, w której działa proces VPN, a nie z tej, w której przypadkiem jest twoja powłoka. Dwa poniższe polecenia odpowiadają na różne pytania, a różnica ujawnia się, gdy host widzi interfejs, którego nie widzi kontener. Uruchom je w podanej kolejności, bo drugie ma sens dopiero wtedy, gdy wiesz, czy łącze w ogóle istnieje.

ip -details link show dev tun1
ip tuntap show

Pierwsze polecenie wypisuje łącze tak, jak widzi je jądro, wraz z flagami i typem interfejsu, i w ten sposób potwierdzasz, że to właściwe urządzenie. Drugie wymienia trwałe wpisy tun/tap, które istnieją bez żadnego procesu, który by je trzymał. Interfejs czekający na swojego docelowego właściciela to inna sytuacja niż żywy tunel podłączony do innej VPN, i tylko drugie wyjaśnia, dlaczego twoje własne podłączenie zawodzi. Znajdź proces trzymający urządzenie, zanim cokolwiek zmienisz, bo trwały wpis i zajęty interfejs mają różne rozwiązania.

Obsługa wielu kolejek to konkretny układ sterownika z własnymi wymaganiami, a nie pozwolenie, by niepowiązane procesy dzieliły jeden interfejs. Żywa sesja innego właściciela to problem koordynacji i żadna edycja profilu go nie rozwiązuje.

Dwa rodzaje trwałości

Trwałość jądra i persist-tun opisują czasy życia, które łatwo pomylić i drogo pomieszać. Trwałe urządzenie istnieje niezależnie od dowolnego procesu, więc przeżywa zatrzymanie i następny start może je ponownie wykorzystać. persist-tun zachowuje zasoby przez obsługiwane miękkie resety w obrębie jednego procesu OpenVPN, znacznie krótszy horyzont. Żadne z nich nie obiecuje, że zatrzymanie usługi pozostawi trasy i adresy na miejscu, a interfejs, który pozostaje widoczny, nie jest dowodem działającej zaszyfrowanej sesji.

Potwierdź też backend, bo wstępnie utworzony interfejs nic nie mówi o tym, która implementacja go otworzy. Kompilacje społeczności z bezpośrednią ścieżką danych spróbują go użyć, chyba że projekt mówi inaczej. Tam, gdzie wersja obsługuje przełącznik, disable-dco wybiera zamiast tego ścieżkę w przestrzeni użytkownika; starsze silniki i inni klienci nie mają takiej dyrektywy, więc trzymaj warunek wersji obok opcji, zamiast zakładać, że obowiązuje.

Co się psuje, gdy testuje się tylko uruchamianie

Porozumienie o własności może przejść pierwszy test i zawieść na ostatnim, co czyni samo uruchamianie słabym sprawdzeniem. Obserwuj zamiast tego dwa przejścia: miękki reset oraz pełne zatrzymanie, po którym następuje start.

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

Uruchamianie to łatwy przypadek: jednostka wstaje, łącze się pojawia, a wyjście stanu podaje nazwę wczytanego profilu. Podłączenie to moment, w którym demon otwiera urządzenie, więc sprawdzenie łącza uruchom po tym, jak jednostka zgłosi aktywność, a nie przedtem. Jeśli łącze istnieje, gdy stan wciąż się aktywuje, patrzysz na trwałe urządzenie, do którego nikt się jeszcze nie podłączył, a nie na działający tunel. Przepuść prawdziwy ruch przez łącze, zanim przejdziesz dalej, bo podłączony interfejs bez użytecznej trasy nadal jest porażką.

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

Miękki reset powinien pozostawić sesję użyteczną, a zasoby nietknięte, i właśnie tę pracę wykonuje persist-tun. Pełne zatrzymanie to miejsce, w którym zewnętrzny menedżer się ujawnia: jeśli łącze lub jego adresy przetrwają zatrzymanie, posiada je ktoś inny, i jest to albo stan, który udokumentowałeś, albo błąd, który właśnie znalazłeś. Zapisz obie obserwacje obok profilu, aby następna zmiana zaczynała się od dowodów, a nie od diagramu.