Zwykła aplikacja Linux korzysta z VPN bez dotykania TUN

Przeglądarka korzystająca z ustanowionego połączenia Linux VPN nie otwiera /dev/net/tun. Otwiera gniazdo, a jądro decyduje, przez który interfejs wychodzą pakiety tego gniazda. Proces, który utworzył tunel, wykonuje inną pracę niż proces, którego ruch przewozi. Rozdzielenie tych dwóch ról odpowiada na większość pytań o uprawnienia, zanim zostaną zadane.

Prześledź jeden pakiet od gniazda do tunelu

Zwykła aplikacja wywołuje connect lub send, a jądro szuka trasy do celu. Jeśli wybrana trasa wskazuje interfejs tunelu, pakiet trafia do kolejki urządzenia, z którego czyta demon VPN. Demon szyfruje go i wysyła przez interfejs fizyczny. Każda strzałka w tym opisie to miejsce, w którym można odpowiedzieć na pytanie o uprawnienia.

Nic na tej drodze nie wymaga, aby aplikacja znała urządzenie. Demon trzyma deskryptor pliku i wykonuje operacje na interfejsie, podczas gdy aplikacja widzi tylko zwykłe API sieciowe.

Narysuj obie połowy raz, a pytania o uprawnienia łatwiej będzie umiejscowić. Górna połowa to świat aplikacji, a dolna należy do demona.

Zdecyduj, kto potrzebuje urządzenia, a kto nie

Utworzenie interfejsu TUN lub dołączenie do niego wymaga dostępu do urządzenia oraz możliwości skonfigurowania go, dlatego obsługiwana usługa VPN zaczyna od uprawnień administracji siecią albo korzysta z uprzywilejowanego pomocnika. To wymaganie należy do demona. Nie mówi nic o przeglądarce, kliencie bazy danych ani narzędziu do przesyłania plików. Usługa, która potrzebuje tej możliwości, potrzebuje jej na własny etap konfiguracji, a nie dla swoich klientów.

Gdy trasa i polityka są na miejscu, zwykły proces korzysta z wynikowej ścieżki przez swoje zwykłe wywołania gniazd. Nie potrzebuje węzła urządzenia ani roota.

Zmiana uprawnień urządzenia nie jest sposobem przyznania aplikacji dostępu do celu. Przesuwa jedynie granicę urządzenia gdzie indziej.

Sprawdź przestrzeń nazw, w której aplikacja naprawdę działa

Kontener lub druga przestrzeń nazw sieci daje swoim procesom osobny zestaw interfejsów i tabelę tras. Tunel na hoście nie pojawia się tam automatycznie i żadna zmiana uprawnień urządzenia tego nie zmieni. Aplikacja po prostu będzie kierować ruch przez to, co zapewnia ta przestrzeń nazw. Dlatego obraz kontenera nie może przypadkiem odziedziczyć tunelu hosta.

Sprawdź za pomocą ip netns list i ip -n NAME route, albo oglądając dowiązanie przestrzeni nazw procesu. Odpowiedź zwykle widać w jednym poleceniu.

Dwóm użytkownikom na tym samym hoście można też nadać różne ścieżki przez politykę. To decyzja sieciowa, a nie dowód własności urządzenia.

Oddziel możliwości od polityki sieciowej

Niektóre narzędzia potrzebują więcej niż gniazda. Przechwytywanie pakietów wymaga surowego gniazda, a zmiana tras wymaga uprawnień administracyjnych. To osobne operacje z osobnymi nadaniami, a przyznanie jednego nie powinno być czytane jako ogólny wymóg korzystania z VPN.

Program, który sam implementuje tunel, jest trzecim przypadkiem. Naprawdę otwiera TUN, bo przejmuje rolę demona, dlatego potrzebuje jego uprawnień.

Nazwij operację, zanim nazwiesz uprawnienie. Zwykle łatwiej je rozdzielić, niż się wydaje.

Zweryfikuj podział dwoma kontami

Podłącz tunel jako usługę, następnie uruchom aplikację jako zwykłego użytkownika i potwierdź, że dociera do zasobu prywatnego. Sprawdź ip route get dla celu z powłoki tego użytkownika, aby zobaczyć, który interfejs został wybrany. Jeśli trasa jest poprawna, a połączenie nadal zawodzi, problemem jest polityka, a nie uprawnienie.

Wynikowy projekt to minimalne uprawnienia z jawną granicą: jeden komponent posiada konfigurację i zasoby tunelu, obciążenia zachowują swoje zwykłe konta, a polityka sieciowa decyduje, co może przejść. Uruchamianie wszystkiego jako root załamuje te role, niczego nie wyjaśniając.