Dlaczego trasa pełnego tunelu odcina serwer, który ją przenosi

Włącz pełny tunel, a każde miejsce docelowe należy teraz do interfejsu VPN, łącznie z maszyną, która go kończy. Zewnętrzne pakiety niosące tunel są adresowane do tej maszyny, więc trasa ostatecznie zużywa transport, od którego zależy. Jedna dodatkowa konkretna trasa to rozwiązuje, a powód warto zrozumieć. Bez tego powodu następna przebudowa ponownie wprowadzi usterkę.

Trasa, która zjada własny transport

Enkapsulacja owija każdy pakiet w drugi nagłówek. Zewnętrzny jest adresowany od lokalnego adresu fizycznego do publicznego adresu serwera i musi przejść przez łącze fizyczne, zanim może istnieć jakikolwiek tunel.

Teraz pozwól, aby wyszukanie tego publicznego adresu wybrało tunel. Aby wysłać pakiet, maszyna musi go enkapsulować, co wymaga trasy do tego samego adresu, a ta zwraca tunel. Klienci radzą sobie z tym na jeden z dwóch sposobów. Ostrożny odmawia zainstalowania trasy domyślnej i zgłasza błąd, a mniej ostrożny zgłasza sukces i potem niczego nie przesuwa. Cicha awaria jest tą, która kosztuje popołudnie.

Dopasowanie najdłuższego prefiksu rozstrzyga wyszukanie, zanim spojrzy się na jakąkolwiek metrykę, więc trasa do jednego adresu przewyższa każdą trasę domyślną na maszynie. To cały mechanizm stojący za naprawą.

Zainstaluj wyjątek przed trasą domyślną

Utwórz trasę do jednego adresu dla serwera, z fizyczną bramą jako następnym skokiem, zanim przesunie się trasa domyślna. Kolejność ma znaczenie: instalacja później oznacza życie z zepsutym tunelem podczas pisania.

Większość klientów robi to bez proszenia. OpenVPN wyszukuje zdalny adres i przypina go przed przepisaniem bramy domyślnej, a jego opcja route-delay istnieje dla platform, na których ta sekwencja ściga się. wg-quick wybiera zupełnie inną drogę, oznaczając pakiety i konsultując regułę polityki zamiast dodawać wyjątek. Różne mechanizmy, ten sam wymóg: zewnętrzny pakiet musi uciec z tunelu, który tworzy.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Wynik wyszukania jest testem akceptacyjnym. Musi wskazać urządzenie fizyczne i fizyczny następny skok. Urządzenie tunelowe w tej odpowiedzi oznacza, że brakuje wyjątku albo został umieszczony po czymś, co go przewyższa.

Odbicie lustrzane na serwerze

Ta sama pułapka czeka po drugiej stronie, odwrócona. Daj serwerowi trasę domyślną przez inny tunel albo wepchnij mu trasę obejmującą publiczne adresy klientów, a jego odpowiedzi nabiorą nawyku złego kierunku.

Wyobraź sobie klienta, który się łączy i wysyła żądanie. Odpowiedź jest adresowana do publicznego adresu tego klienta, który teraz pasuje do trasy tunelu, więc wychodzi z innego interfejsu, niosąc źródło, którego klient nigdy nie wybrał. Klient może odebrać ten pakiet i mimo to go odrzucić, bo nic nie wiąże go z wysłanym żądaniem. Zacznij od decyzji routingu serwera, a nie od limitu czasu klienta, ponieważ tylko jedna z nich pokazuje rzeczywisty wybór.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Istnieją trzy naprawy i nie są równe. Przypięcie usługi do adresu fizycznego albo tłumaczenie źródła oba ukrywają decyzję routingu zamiast ją poprawiać. Wysyłanie ruchu odpowiedzi dla puli tunelu przez dedykowaną tabelę naprawia przyczynę, a pozostałe dwie są dopuszczalne tylko dopóki projekt routingu jest zamrożony.

Wyjątki, które tunel wciąż kradnie

Garść zadań potrzebuje otwartego internetu nawet wtedy, gdy tunel posiada trasę domyślną, i każde potrzebuje własnego wyjątku. Aktualizator dynamicznego DNS zwykle psuje się pierwszy.

Rozwiązuje dostawcę, otwiera połączenie i odkrywa, że jego własne pakiety podróżują przez tunel, którego adres zmienił się kilka sekund temu, więc aktualizacja kończy się niepowodzeniem albo publikuje zły adres. Trzy wyjścia: przypnij dostawcę trasą do hosta przez fizyczną bramę, uruchom aktualizację, zanim tunel wstanie, albo daj aktualizatorowi tabelę polityki, której tunel nigdy nie dotyka. Synchronizacja czasu ma tę samą ekspozycję na urządzeniu, które startuje bez resolvera, a punkty walidacji certyfikatów należą do listy z tego samego powodu.

Wyjątek, którego nikt nie zapisał, to wyjątek, który następna przebudowa po cichu pominie.

Udowodnij to po ponownym połączeniu, nie przed

Przetestuj trzy cele, nie jeden: punkt końcowy, prywatny adres za tunelem i publiczny adres poza nim. Jedno udane wyszukanie nie mówi prawie nic o pozostałych dwóch.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Potem zrestartuj połączenie, ponieważ klient, który przy ponownym połączeniu odbudowuje swoją tabelę, wyrzuci trasę wpisaną ręcznie. Jeśli działa kill switch, sprawdź, czy punkt końcowy jest dozwolony, inaczej tunel nie wróci po zmianie sieci, a objaw wygląda jak awaria. Przechowuj wyjątek w profilu albo w pliku unit, a nie w historii shella, żeby ponowne połączenie odtworzyło go zamiast go usunąć.