Pełny tunel czy trasa do punktu końcowego: utrzymanie dostępności serwera VPN

Tunel podróżuje przez sieć, którą zastępuje. Porównaj wyjątek trasy hosta ze znacznikiem gniazda na poziomie aplikacji i dowiedz się, kiedy każdy z nich zawodzi.

Dodaj trasę domyślną przez tunel, a pakiety samego tunelu pójdą za nią. Tabela zawiera wtedy regułę, która sama siebie obala. Zaszyfrowane połączenie z serwerem próbuje podróżować wewnątrz połączenia, które próbuje ustanowić.

Dwa mechanizmy zapobiegają tej pętli. Jeden jest widoczny w tabeli routingu, drugi żyje wewnątrz aplikacji.

Ruch wewnętrzny i zewnętrzny to różne decyzje

Pakiet aplikacji wchodzi do interfejsu wirtualnego i zostaje enkapsulowany. Wynikiem jest nowy pakiet zaadresowany do publicznego adresu serwera. Ten pakiet potrzebuje trasy w sieci fizycznej, ponieważ nic z niego nie może wejść do tunelu.

Oba są decyzjami routingu i tylko pierwsza należy do tunelu. Gdy klient instaluje trasę domyślną obejmującą także serwer, pakiet zewnętrzny również zostaje przechwycony.

Objawy są natychmiastowe i całkowite. Uścisk dłoni się kończy i potem nic nie płynie, albo połączenie pada w chwili instalacji trasy. W obu przypadkach keepalive nie może już wyjść.

Opcja pierwsza: trasa hosta do punktu końcowego

Podejście bezpośrednie dodaje trasę do adresu serwera przez pierwotną bramę. Wymaga jednej linii. Jest widoczna dla każdego, kto czyta tabelę. Łatwo ją też wyjaśnić w zapisie zmian.

Jej słabość ujawnia się, gdy zmienia się ścieżka bazowa. Zapisana trasa wskazuje bramę i interfejs ze starej sieci. Po przełączeniu Wi-Fi ta brama może nie istnieć, a trasa zostaje, wygląda poprawnie i nic nie robi.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Nazwa hosta to utrudnia. Jeśli punkt końcowy jest nazwą rozwiązywaną na kilka adresów, wyjątek musi obejmować adres faktycznie używany. Późniejsze zapytanie może zwrócić coś, czego trasa nigdy nie obejmowała.

Opcja druga: chronić gniazdo

Drugie podejście nigdy nie dotyka tabeli routingu. Klient oznacza lub chroni gniazdo, które niesie tunel, więc system operacyjny wysyła ruch tego gniazda poza tunel zgodnie z polityką. Android udostępnia ten mechanizm bezpośrednio aplikacjom VPN. Klienci desktopowi implementują odpowiedniki za pomocą znaczników zapory lub wywołań przypisania do urządzenia.

Zaletą jest to, że wyjątek podąża za połączeniem, a nie za zapisaną bramą. Zmiana sieci przepisuje ścieżkę bazową, a chronione gniazdo przesuwa się razem z nią, bo nigdy nie było przypięte do adresu. Tabela routingu pozostaje czysta.

Kosztem jest widoczność. Nic w tabeli routingu nie pokazuje wyjątku, więc recenzent szukający trasy hosta nic nie znajdzie i może uznać, że projekt jest niebezpieczny. Ochrona żyje w kodzie klienta i w regułach polityki, które ten kod instaluje.

Wybór między nimi

Wybierz mechanizm na poziomie gniazda, gdy klient go obsługuje, ponieważ przetrwa zmiany sieci, które psują przypiętą trasę. Wybierz trasę hosta, gdy wyjątek musi być widoczny dla innych narzędzi albo gdy klient nie oferuje nic lepszego.

Żaden z mechanizmów nie usuwa potrzeby, by adres serwera był w ogóle osiągalny. Prywatna brama ma publiczny adres nasłuchu i to ten adres musi pozostać poza tunelem. Wewnętrzne sieci za nią stają się osiągalne dopiero, gdy tunel istnieje.

Cokolwiek wybierzesz, trzymaj to przy komponencie, który posiada tunel. Zbłąkana trasa hosta dodana ręcznie działa do następnej sieci, a potem staje się tajemniczą awarią jutra.

Powiązane artykuły