Dlaczego trasa hosta /32 utrzymuje punkt końcowy VPN osiągalny

Otwierasz tabelę routingu po połączeniu i znajdujesz jeden adres kierowany przez tunel, podczas gdy otaczająca go podsieć nadal idzie do lokalnej bramy. Ten wpis to trasa hosta: jeden adres, dopasowany przez prefiks z samych jedynek. Ma to znaczenie, bo decyzje routingu używają najdłuższego pasującego prefiksu, więc /32 może przesłonić /24 lub trasę domyślną bez zmiany którejkolwiek z nich. To, czy jest to staranny wyjątek, czy przyszła awaria, zależy od tego, który adres nazywa i kto ją utrzymuje.

Jeden adres, jeden wpis w tabeli

Trasa hosta IPv4 ma prefiks /32, a trasa hosta IPv6 — /128, co oznacza, że wpis może pasować dokładnie do jednego adresu docelowego. Nic innego w tabeli się nie przesuwa: podsieć obejmująca i trasa domyślna zostają tam, gdzie były. Wąski wpis wygrywa dla tego adresu, bo jego prefiks jest dłuższy, a nie dlatego, że dodano go później.

Ta właściwość czyni trasę hosta dobrym wyjątkiem i złym nawykiem. Dwa wpisy /32 nazywające frontowe drzwi usługi nie obejmują jej drugiego adresu, jej adresu IPv6 ani adresu, na który przeniesie się w przyszłym miesiącu. Tabela pełna niewyjaśnionych wpisów jednego adresu zwykle oznacza, że ktoś ciągle łatał wokół decyzji o podsieci, zamiast ją podjąć. Najpierw przeczytaj długość prefiksu, a potem zapytaj, czego wpis ma bronić.

Czytaj wpis od klienta na zewnątrz

Zacznij od maszyny z problemem, bo ten sam adres może być kierowany inaczej na laptopie i na bramie przed nim. Zapytaj jądro, którą drogę wybrałoby dla dokładnego adresu, którego używa aplikacja, zamiast czytać tabelę od góry. Odpowiedź zawiera interfejs i następny skok, które razem są decyzją.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Powtórz zapytanie dla rodziny adresów, którą aplikacja faktycznie wybiera, bo klient może preferować IPv6 i po cichu ominąć wyjątek IPv4. Porównaj wynik przed i po podniesieniu tunelu i zachowaj oba wyjścia. To porównanie pokazuje, czy klient dodał wpis przy połączeniu, czy był już wcześniej.

Trwały wpis i wpis czasu wykonania zawodzą różnie. Wpis czasu wykonania znika z sesją, a trwały przeżywa restart i nadal wysyła ruch do bramy, której już nie ma.

Wyjątek punktu końcowego i pułapka rekurencji

Klienci VPN zwykle instalują trasę hosta do zewnętrznego adresu serwera przez pierwotną bramę, zanim przekierują trasę domyślną. Bez tego wpisu zaszyfrowane pakiety trafiłyby do tunelu, który próbują zbudować, a połączenie zapętliłoby się, aż upłynąłby czas.

Pułapka pojawia się, gdy akceptowane podsieci tunelu przypadkiem obejmują ten adres punktu końcowego albo gdy drugi profil doda później szerszą trasę. Wtedy wpis punktu końcowego przegrywa z dłuższym prefiksem i sesja się rozpada, gdy tylko zaczyna przepuszczać ruch. Zapisanie adresu punktu końcowego obok akceptowanych podsieci to najtańszy sposób zauważenia kolizji przed użytkownikami. Wyjaśnia to też, dlaczego ten sam profil działa z jednej sieci, a z innej zawodzi.

Sprawdź ścieżkę, której aplikacja naprawdę używa

Udany ping do nazwy hosta to słaby dowód, gdy aplikacja łączy się z innym adresem lub inną rodziną. Sprawdź dokładną kombinację adresu, rodziny, portu i interfejsu na maszynie, która uruchamia klienta.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Jeśli ścieżka jest zła, zdecyduj, czy wymaganie to sieć, czy jeden adres, zanim cokolwiek zmienisz. Wymaganie jednego adresu uzasadnia trasę hosta z komentarzem i właścicielem; usługa z rotującymi adresami potrzebuje routingu opartego na domenie albo uczciwej decyzji o podsieci.

Usuwaj wpisy, które nie odpowiadają już rzeczywistemu celowi, i notuj te, które zachowujesz. Niewyjaśnione /32 po trzech miesiącach nie różni się od błędu, a następna osoba usunie je, nie wiedząc, co od niego zależało.