Jedno logowanie VPN na współdzielonym komputerze: kto jeszcze dostaje trasę?
Logowanie VPN uwierzytelnia jedną osobę; instalowana trasa to inny zakres. Porównaj tunele dla całego hosta, dla użytkownika i dla aplikacji na współdzielonej maszynie.
Współdzielenie stacji roboczej rodzi pytanie, na które laptop jednego użytkownika nigdy nie musi odpowiadać: gdy jedna osoba uwierzytelni tunel, kto jeszcze może go użyć? Logowanie identyfikuje podmiot, a instalowana trasa opisuje zakres, i te dwie rzeczy nie są tym samym obiektem. Między nimi znajduje się system operacyjny, konfiguracja klienta i to, czego prywatna usługa wymaga sama z siebie. Porównanie punktów egzekwowania to jedyny sposób, by odpowiedzieć bez zgadywania.
Jedno logowanie, kilka zakresów
Uwierzytelnianie odpowiada, kto został wpuszczony. Trasa odpowiada, które pakiety mogą wyjść przez tunel. Autoryzacja odpowiada, która usługa przyjmie powstałe połączenie, i żadne z tych trzech nie wynika z następnego.
Tunel obejmujący cały host jest zwykłym ustawieniem domyślnym i czyni lukę oczywistą. Trasa leży w tablicy jądra, więc każdy proces korzystający z tej tablicy może dotrzeć do sieci prywatnej, w tym ten uruchomiony przez użytkownika, który nigdy nie widział okna VPN. To nie jest wada tunelu; to właśnie znaczy trasa systemowa. Usługa prywatna nadal może odrzucić połączenie, dlatego osiągalność i zezwolenie wymagają osobnych odpowiedzi.
Zapisanie czterech pytań przed testem nie pozwala, by przegląd sprowadził się do jednego z nich.
Gdzie naprawdę leży granica
Cztery układy obejmują większość maszyn: tunel dla całego hosta, połączenie dla użytkownika, lista dozwolonych aplikacji i osobna przestrzeń nazw sieci lub maszyna wirtualna.
Każdy umieszcza punkt egzekwowania gdzie indziej, a różnice znaczą więcej niż etykiety. Połączenie dla użytkownika egzekwują uprawnienia profilu, a nie ekran logowania pulpitu. Lista dozwolonych aplikacji jest egzekwowana wewnątrz klienta, który decyduje, co przetransportuje. Przestrzeń nazw lub VM egzekwuje na granicy interfejsu, więc proces w środku w ogóle nie widzi trasy hosta. Liczba ekranów logowania na maszynie nie mówi nic o żadnym z nich.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
Czytanie tablicy wiersz po wierszu pokazuje, że prawdziwe pytanie nie dotyczy istnienia izolacji, lecz miejsca jej implementacji.
Porównaj cztery punkty egzekwowania
W Linuksie tablica tras jest pierwszą rzeczą do sprawdzenia, ponieważ tunel dla całego hosta pojawia się tam, a przestrzeń nazw nie. Uruchomienie wyszukiwania jako drugi użytkownik to krok, który ludzie pomijają; odpowiedź różni się od tej, którą uzyskali jako oni sami, i to wyjaśnia raport.
Dwie następne kontrole patrzą na politykę, a nie na routing. Reguła zapory zgodna z UID dotyczy ruchu generowanego lokalnie, więc może rozdzielić dwóch użytkowników na jednym hoście nawet wtedy, gdy obaj dzielą trasę. Profil połączenia z jawną listą uprawnień jest egzekwowany przez menedżera sieci przy aktywacji. Żadna kontrola nie wymaga zmiany tunelu, dlatego warto je wykonać przed jakimkolwiek przeprojektowaniem.
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid
Jeśli drugie wyszukiwanie pokaże trasę tunelu, granica nie leży tam, gdzie zakładał projekt.
Reguły sesji równoległych to osobna kontrola
Bramy często ograniczają liczbę sesji, które może utrzymać jedno konto, i ten limit nie ma nic wspólnego z lokalnymi użytkownikami. Ogranicza konto, więc druga osoba logująca się tymi samymi danymi może zakończyć tunel pierwszej.
Przeczytaj błąd, zanim założysz lokalny problem z izolacją. Limit sesji powoduje rozłączenie na bramie, natomiast problem zakresu daje działający tunel, który po prostu nie przenosi ruchu drugiego użytkownika. Te dwa objawy prowadzą do zupełnie różnych poprawek. Zachowaj dokładny komunikat klienta, bo zwykle nazywa regułę. Poproś właściciela profilu o zatwierdzony przepływ pracy zamiast obchodzić limit.
Maszyna wirtualna nikogo nie zwalnia z tej reguły i dodaje własny projekt sieci oraz danych logowania.
Testuj kontekst, na którym ci zależy
Przetestuj zamierzonego użytkownika i aplikację, a potem kontekst, który powinien zostać odrzucony. Przegląd, który tylko dowodzi, że pierwotne hasło działa, przetestował uwierzytelnianie i nic więcej.
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'
Zapisz punkt egzekwowania obok każdego wyniku: tablicę tras, regułę UID, uprawnienie profilu albo politykę sesji bramy. Taki zapis czyni następną zmianę weryfikowalną. Zapobiega też ponownemu otwieraniu tego samego pytania za każdym razem, gdy ktoś zauważy drugi ekran logowania. Osiągalność nie jest autoryzacją i żadne z nich nie jest izolacją.