Co robi TUN i co nadal musi robić protokół VPN

Traktowanie tun0 i protokołu VPN jako jednej rzeczy prowadzi ludzi do niewłaściwego dziennika. Interfejs jest lokalną granicą, na której program w przestrzeni użytkownika wymienia pakiety IP z jądrem. Protokół to to, co ten program robi z pakietami, gdy już je ma: transport, uwierzytelnianie, szyfrowanie i partner. Utworzenie urządzenia nie wybiera żadnego z nich.

Dwa komponenty, jedna ścieżka pakietu

Jądro zapisuje pakiet IP do urządzenia, a program odczytuje go z deskryptora pliku. W drugą stronę program zapisuje pakiet z powrotem, a jądro kieruje go tak, jakby dotarł na rzeczywisty interfejs. TUN przenosi IP, natomiast TAP przenosi ramki Ethernet. Odczyt pakietu na tej granicy pokazuje ramkowanie, i właśnie do tego służy urządzenie.

Wszystko poza tą granicą jest sprawą programu. Dwa programy mogą używać tej samej koncepcji interfejsu i robić z pakietami zupełnie różne rzeczy. Samo urządzenie nie ma zdania na temat tego, co będzie dalej. Deskryptor pliku to jedyny uchwyt, jaki program ma po stronie jądra.

Utwórz urządzenie, a potem obserwuj granicę

Utwórz urządzenie celowo, gdy testujesz granicę. Trwałe urządzenie przeżywa proces, który je utworzył, co jest przydatne w eksperymentach i bywa później częstym źródłem zamieszania. Sprawdź flagi i właściciela, zanim obwinisz VPN.

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

Szczegóły łącza pokazują typ urządzenia i przypisanego właściciela. Jeśli żaden proces nie trzyma go otwartego, pakiety do niego zapisane donikąd nie trafiają. Urządzenie bez przypisanego procesu może wyglądać zdrowo na liście łączy, a mimo to niczego nie przepuszczać.

Czego nie może obiecać nazwa interfejsu

Nazwa interfejsu nie mówi nic o szyfrowaniu ani uwierzytelnianiu. Program może opakować pakiety w TLS, we własny protokół, w IPsec albo w nic. Wybór TUN zamiast TAP zmienia ramkowanie na granicy, a nie projekt bezpieczeństwa. Wybór ramkowania jest realny i jest znacznie mniejszy niż pytanie o bezpieczeństwo.

Wykrywanie działa tak samo: obserwator widzi protokół zewnętrzny na przewodzie, a nie etykietę mówiącą, które lokalne urządzenie go wytworzyło. Tunel, który wygląda jak coś innego, robi to z powodu swojego protokołu zewnętrznego, a nie nazwy interfejsu. Obserwator nie może zobaczyć, które lokalne urządzenie wytworzyło pakiet, tylko jak pakiet wygląda. Trzymaj te dwa pytania osobno, gdy porównujesz produkty, bo jedna odpowiedź nigdy nie implikuje drugiej.

Dopasuj naprawę do etapu, który zawodzi

Gdy coś się psuje, rozdziel etapy awarii. Brakujące urządzenie, błąd uprawnień i odrzucone logowanie dają różne dowody i różne naprawy. Najpierw czytaj stan lokalny, potem dziennik samego programu, potem spojrzenie partnera. Przeczytaj wszystkie trzy, zanim cokolwiek zmienisz.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

Jeśli urządzenie istnieje i proces je trzyma, lokalna granica działa, a problem jest dalej. Jeśli urządzenia brakuje, żadne sprawdzanie danych logowania nie pomoże. Etap, który potrafisz nazwać, to etap, który potrafisz przetestować. Dokumentacja TUN/TAP opisuje granicę i model urządzenia.