Przenośny klient VPN bez uprawnień administratora: co nadal się psuje

Przenośny opisuje instalator, nie jądro. Klient może przyjść jako jeden plik wykonywalny na pendrivie i mimo to potrzebować urządzenia tunelowego, wpisu w tabeli tras i zapisu w resolverze, zanim ruszy pierwszy pakiet. To, którego z tych trzech rzeczy docelowa maszyna pozwoli ci dotknąć, decyduje, czy ta kompilacja w ogóle tam działa. Poniższe testy odpowiadają na pytanie w kolejności, w jakiej klient na nie trafi.

Przenośność obejmuje trzy różne obietnice, a tylko jedna jest darmowa

Brak instalatora oznacza, że dostawca nie zarejestrował usługi, nie dostarczył deinstalatora i nie dodał wpisu w menu. Brak administratora oznacza, że zwykłe konto może uruchomić klienta i zakończyć połączenie. Brak zmian w hoście oznacza, że maszyna wygląda identycznie po wyjściu. Strony pobierania, które mówią przenośny, zwykle obiecują tylko pierwszą z tych rzeczy, a pozostałe dwie to miejsce, w którym wdrożenia zawodzą. Kompilacja może być przenośna także w wąskim sensie: działa z nośnika tylko do odczytu bez żadnych zapisów plików kropkowych, co nadal nic nie mówi o stosie sieciowym.

Drogie obietnice to druga i trzecia. Jeden plik wykonywalny, który potrzebuje adaptera, trasy lub zapisu w resolverze, prosi system operacyjny o uprawnienie, którego etykieta przenośny nigdy nie obejmowała.

Znajdź uprzywilejowanego pomocnika, którego wywoła klient

Prawie żaden klient VPN nie przenosi pakietów sam. W Windows ścieżka danych przechodzi przez filtry WFP i Base Filtering Engine, w macOS przez dostawcę NetworkExtension, którego użytkownik zatwierdza w Ustawieniach systemowych, a w Linuxie przez urządzenie tun oraz stos routingu. Skopiowany plik binarny jest powierzchnią sterowania tymi komponentami, nie ich zamiennikiem. Zapytaj, jakiego komponentu oczekuje klient, a następnie potwierdź, że jest zainstalowany, działa i jest dostępny dla twojego konta.

Linux to najłatwiejsze miejsce, by to udowodnić, ponieważ test to jedno wywołanie systemowe. Otwarcie /dev/net/tun i poproszenie jądra o urządzenie wymaga CAP_NET_ADMIN, a dokumentacja jądra dotycząca TUN/TAP podaje zarówno zasadę własności, jak i możliwość. Uruchom test na koncie, które uruchomi klienta, a nie jako root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

Błąd uprawnień w środkowej linii to odpowiedź, której szukałeś: to konto nie może utworzyć interfejsu tunelowego, więc każdy klient w przestrzeni użytkownika, który go potrzebuje, zawodzi przy połączeniu, a nie przy pobieraniu. Ostatnia linia usuwa urządzenie testowe i nic nie wypisuje, gdy działa. Jeśli obie linie się powiodą, host nie zmienił niczego trwale.

Przetestuj zmiany trasy i resolvera przed pierwszym połączeniem

Tunel dzielony zamienia połączenie w decyzję routingu, a pełny tunel zamienia je w zastąpienie trasy domyślnej. Oba są zapisami do stosu sieciowego hosta i oba zawodzą dla konta bez uprawnień, nawet gdy sam klient startuje czysto. Resolver to trzeci zapis, a na hostach systemd zwykle to on psuje się ostatni. Ta kolejność ma znaczenie, gdy decydujesz, gdzie wydać podniesioną instalację.

Test trasy potrzebuje celu, na którym naprawdę ci zależy, więc zamiast poniższego symbolu zastępczego wstaw podsieć z własnego profilu. Nazwa urządzenia musi istnieć, aby trasa mogła się do czegokolwiek przyczepić.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Jeśli pierwsza linia zwróci RTNETLINK answers: Operation not permitted, konto nie może zainstalować prywatnej trasy wymaganej przez profil. Druga linia dowodzi tego samego prawa odwrotnie, co ma znaczenie, ponieważ klient, który potrafi dodawać trasy, ale nie usuwać ich, zostawia po sobie zepsutą tabelę. Potem zapytanie do resolvera pokazuje, czy prywatne nazwy są rozwiązywane przez tunel, czy wyciekają do resolvera, któremu host już ufa.

Uruchom wszystkie trzy, dopóki urządzenie testowe jeszcze istnieje, a potem je usuń. Trasa wskazująca na nieistniejące urządzenie to najczęstszy powód utraty łączności przez laptopa po nieudanym połączeniu.

Zdecyduj, co musi przetrwać sesję

Usunięcie folderu nie jest planem sprzątania. Adaptery, trasy, ustawienia resolvera, zaufane certyfikaty i zapisane dane logowania mogą każde przetrwać proces, a usługa przy starcie może niektóre z nich przywrócić bez pytania. Zapisz, co klientowi wolno zostawić po sobie przed uruchomieniem, a nie po pierwszym nieudanym rozłączeniu.

Praktyczna zasada to zrobienie migawki trzech powierzchni, które zamierzasz zmienić, i porównanie ich potem. Przed pierwszym połączeniem zapisz interfejsy, główną tabelę routingu i stan resolvera, a następnie powtórz te same trzy odczyty, gdy klient zakończy pracę.

ip -brief addr show
ip route show table main
resolvectl status

Wszystko, co jest w drugim przechwyceniu, a czego nie ma w pierwszym, potrzebuje właściciela. Albo klient to usuwa przy wyjściu, albo usuwasz to ty tymi samymi poleceniami, które to stworzyły, i to usunięcie należy do notatek wdrożeniowych, a nie do czyjejś pamięci o tym, co się stało. W Windows odpowiednie odczyty to Get-NetAdapter, Get-NetRoute i Get-DnsClientServerAddress, które nie wymagają podniesienia, ale pokazują te same pozostałości.