Czy trasy DHCP mogą skierować Twój ruch wokół tunelu VPN?

Szyfrowanie zaczyna się na granicy, a tą granicą jest decyzja routingu podejmowana przez punkt końcowy, zanim jakikolwiek pakiet zostanie enkapsulowany. Sieć, która nigdy nie widzi Twoich kluczy, wciąż może podsunąć Twojej maszynie trasę, która podoba jej się bardziej niż trasa tunelu. Mylone są tu dwa błędy: odczyt pakietu już znajdującego się w tunelu oraz skierowanie pakietu, który nigdy się tam nie znalazł.

To rozróżnienie ma znaczenie, bo drugi błąd jest tańszy do zorganizowania i znacznie łatwiejszy do przeoczenia. Objawia się jako żądanie, które wyszło niewłaściwym interfejsem, podczas gdy klient wciąż zgłaszał zdrowe połączenie.

Dwa sposoby, w jakie sieć może na Ciebie wpłynąć

Pakiet, który dociera do tunelu, ma ładunek ukryty przed każdym przeskokiem, który pokonuje, i ta ochrona trzyma się nawet wtedy, gdy droga Cię zaskoczy. Pakiet, który nigdy nie dociera do tunelu, jest zwykłym żądaniem z Twojego adresu, wysłanym tam, gdzie wskazywała tablica routingu. Pierwszy błąd wymaga złamanego szyfru lub przejętego peera, a drugi potrzebuje tylko komunikatu konfiguracyjnego, któremu Twoja maszyna postanowiła zaufać. Ta asymetria jest powodem, dla którego routingu należy się osobny przegląd.

Sprzęt na drodze nie potrzebuje Twoich kluczy, by wpłynąć na drugi przypadek. Wystarczy mu, że Twój punkt końcowy przyjmie trasę, resolver albo regułę polityki, która taką tworzy.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Skąd może pochodzić trasa, zanim tunel powstanie

DHCP rozdaje więcej niż dzierżawę adresu. Opcja bezklasowych tras statycznych może nieść prefiksy docelowe i następne przeskoki, a RFC 3442 omawia konsekwencje bezpieczeństwa błędnego adresu routera: ruch skierowany w złą stronę, odmowę usługi albo obserwatora siedzącego na drodze. Klient, który przyjmie te trasy, zanim tunel wstanie, może skończyć z preferowaną drogą niemającą nic wspólnego z Twoim dostawcą.

Nic z tego nie czyni wstrzykiwania tras uniwersalnym. Klient musi przyjąć opcję, prefiks musi obejmować ruch, na którym Ci zależy, wybrany następny przeskok musi być osiągalny, a polityka egzekwowania musi pozwolić pakietowi wyjść tą drogą. Usuń którykolwiek z tych warunków, a ta sama odpowiedź jest nieszkodliwa. To także dlatego dwie maszyny w jednej sieci mogą zachowywać się różnie, bo nie uruchamiają tego samego klienta, tej samej polityki ani nawet tej samej rodziny adresów.

IPv6 zasługuje na osobne przejście, bo reklamy routera niosą trasę domyślną innym kodem niż opcja DHCPv4. Test, który sprawdza tylko tablicę v4, tego nie obejmuje.

Sprawdź drogę, którą jądro faktycznie wybiera

Wyszukiwania tras da się odpytać, więc pytaj je, zamiast wnioskować z lampki statusu. Poniższe polecenia pokazują wybraną trasę i źródło dla jednego celu oraz reguły, które mogą nadpisać główną tablicę. Uruchom je po połączeniu i ponownie po ponownym połączeniu, bo odnowienie dzierżawy może zmienić odpowiedź.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Czytaj wynik pod dwoma kątami: interfejsu wymienionego w trasie i wybranego adresu źródłowego. Trasa tunelowa wskazuje urządzenie tunelu, trasa wyciekła wskazuje fizyczne, a różnicę widać bez odszyfrowywania czegokolwiek. Jeśli odpowiedź zmienia się między uruchomieniami, zachowaj oba wyniki i porównaj reguły, które je wytworzyły.

Nie poprzestawaj na trasie domyślnej. Wyjątek aplikacji, prefiks tunelu dzielonego albo druga reguła polityki mogą poprowadzić konkretny cel wokół tunelu, gdy domyślna wciąż wskazuje do środka.

Zdecyduj, gdzie ma mieszkać egzekwowanie

Trzy warunki decydują, czy egzekwowanie po stronie klienta wystarczy, czy potrzebujesz czegoś poza nim. Jeśli klient instaluje i broni tras dla każdej używanej przez Ciebie rodziny adresów, tunel posiadający trasę domyślną zwykle wystarcza. Jeśli maszyna musi docierać do zasobów lokalnych, gdy wszystko inne zostaje w tunelu, te wyjątki trzeba wyliczyć i objąć własnością, a nie zostawiać temu, co rozgłosiła sieć dostępowa. A jeśli platforma potrafi przypiąć ruch do interfejsu per aplikacja, to przypięcie jest mocniejszą gwarancją niż trasa, którą cokolwiek może nadpisać.

Cokolwiek wybierzesz, zapisz decyzję tam, gdzie mieszka konfiguracja. Reguła, która istnieje, bo ktoś ją wpisał w trakcie incydentu, nie przetrwa następnego restartu, więc trzymaj wyjątki lokalne i startowe wąsko i notuj, dlaczego każdy istnieje.

Uruchamiaj polecenia wyszukiwania ponownie po każdej aktualizacji klienta i każdej zmianie sieci, i porównuj z ostatnio zapisanym wynikiem. Tablica routingu jest granicą egzekwowania, więc traktuj ją jak granicę.