Serwer WWW znika, gdy klient VPN się łączy

Usługa, która znika w chwili połączenia klienta VPN, zwykle nie jest blokowana, tylko odpowiada przez niewłaściwy interfejs. Żądanie przychodzi na fizyczną kartę sieciową, demon zapisuje odpowiedź, a tablica routingu przekazuje tę odpowiedź tunelowi, ponieważ tunel przejął trasę domyślną. Zdalny klient nigdy nie widzi odpowiedzi na połączenie, które otworzył, więc czeka, a potem zgłasza przekroczenie limitu czasu. Żadna reguła zapory nie bierze w tym udziału.

Objaw: żądania do środka, odpowiedzi przez niewłaściwe drzwi

Sygnałem jest połączenie przychodzące, które zawodzi, podczas gdy wszystko inne na hoście działa. Innym sygnałem jest host osiągalny z LAN, ale nie z internetu, albo taki, który działa do ponownego połączenia tunelu, a potem się zatrzymuje. W każdym przypadku kierunek na zewnątrz zachowywał się poprawnie, a powrotny nie, co wskazuje na asymetrię routingu, a nie na politykę.

Potwierdź to, obserwując, dokąd trafia odpowiedź, a nie obserwując, jak przychodzi żądanie.

Przechwytuj jednocześnie na interfejsie fizycznym i na urządzeniu tunelu. Jeśli żądanie pojawia się na interfejsie fizycznym, a odpowiedź na tunelu, diagnoza jest gotowa. Odpowiedź, która nie pojawia się nigdzie, oznacza, że usługa nigdy nie przyjęła połączenia, co jest osobnym śledztwem z osobną przyczyną.

Dwie trasy domyślne i jedna decyzja routingu

Klient, który instaluje trasę domyślną, dodaje drugi wpis z lepszą metryką niż brama LAN. Niektórzy klienci instalują zamiast tego dwie trasy połowy zakresu, które pokrywają tę samą przestrzeń dokładniej i wygrywają wyszukiwanie w ten sam sposób. Obie techniki pozostawiają zwykłym pakietom wychodzącym wybór interfejsu tunelu.

Ten wybór odbywa się wyłącznie według celu. Jądro nie pyta, skąd przyszedł pakiet, chyba że reguła polityki mu to nakazuje. Odpowiedź na publiczny adres klienta jest więc przekazywana tunelowi, którego drugi koniec otrzymuje pakiet z adresem źródłowym, którego nie posiada, i odrzuca go albo przekazuje gdzieś bezużytecznie. W Linuksie ścisłe filtrowanie odwrotnej ścieżki może też odrzucić pierwotne żądanie, zanim twoja usługa je w ogóle zobaczy, co z zewnątrz wygląda identycznie. Oba objawy pochodzą z tego samego brakującego powiązania między przepływem przychodzącym a jego odpowiedzią.

Tunel zachowuje się poprawnie przez cały czas. Kazano mu nieść trasę domyślną i robi dokładnie to.

Napraw ścieżkę powrotną, nie psując tunelu

Istnieją trzy trwałe formy naprawy, a wybór zależy od tego, jak dużo własnego ruchu hosta ma pozostać w tunelu. Wykluczenie celu lub portu usługi to najmniejsza zmiana. Routing polityki według źródła lub znacznika jest najprecyzyjniejszy. Tłumaczenie źródła jest najgrubsze i najłatwiejsze do wyjaśnienia dwa lata później.

Wybieraj według tego, co host musi robić, a nie według tego, który fragment znalazłeś pierwszy.

Wykluczenie celu pasuje do usługi ze stabilnym publicznym adresem, a przypisanie demona do adresu fizycznego, a nie do każdego adresu, czyni to wykluczenie bezpieczniejszym. Reguła polityki, która wybiera tablicę według źródła, utrzymuje własne połączenia hosta w tunelu i jednocześnie zwraca odpowiedzi usługi przez bramę WAN. Maskowanie odpowiedzi na interfejsie WAN dociera tą samą drogą za cenę ukrycia adresu klienta w dziennikach usługi. Doraźna zmiana trasy domyślnej jest diagnostyką, a nie konfiguracją, ponieważ klient przepisuje trasy przy każdym ponownym połączeniu.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Gdy host routuje także dla sieci LAN za sobą

Jeden skok dalej ta sama asymetria wraca z większą liczbą ruchomych części. Ruch dociera do routera z internetu, jest przekazywany do urządzenia wewnętrznego, a jedyną drogą powrotną tego urządzenia jest tunel, więc odpowiedź dociera do pierwotnego klienta z adresu samego dostawcy. Śledzenie połączeń napotyka wtedy odpowiedź dla przepływu, którego początku nie widziało, i ją odrzuca. Klient tymczasem nie widzi zupełnie nic.

Dwie zmiany to naprawiają: tłumaczenie celu, aby połączenie przychodzące dotarło do urządzenia wewnętrznego, oraz tłumaczenie źródła, aby odpowiedź tego urządzenia wyglądała, jakby pochodziła od samego routera.

W oprogramowaniu routera zwykłym wyrazem jest reguła polityki, która przypina przekierowanie portów do strony WAN, podczas gdy własny ruch routera jedzie tunelem. Bez tłumaczenia źródła ta odpowiedź jest adresowana do klienta zewnętrznego, a urządzenie wewnętrzne po prostu nie ma do niej trasy. Przetestuj trzy rzeczy osobno, ponieważ zawodzą z różnych powodów: połączenie przychodzące z zewnątrz, takie, które inicjuje sam host, oraz wyszukiwanie nazwy.