Czy klient VPN na serwerze WWW psuje jego odpowiedzi?

Witryna ładuje się z laptopa w tej samej sieci, a z każdego innego miejsca kończy się przekroczeniem czasu, a host uruchamia też klienta VPN dla własnego ruchu wychodzącego. Ta kombinacja daje konkretną awarię: połączenie przychodzące dociera, odpowiedź wychodzi złą ścieżką, a klient na zewnątrz nigdy nie widzi odpowiedzi. Obie połowy widać w tym samym przechwyceniu pakietów, więc kolejność zdarzeń to ta część, którą warto przeczytać.

Reguła routingu oparta na źródle często naprawia objaw. Zwykle zwalnia też więcej ruchu niż witryna, która ją spowodowała, i to jest ta część, którą warto zrozumieć przed zapisaniem reguły.

Objaw: odpowiada lokalnie, a nie z zewnątrz

Wewnątrz sieci odpowiedź nie musi przechodzić przez tunel, więc strona się ładuje, a usługa wygląda na zdrową. Z zewnątrz żądanie dociera do hosta, a odpowiedź jest kierowana do VPN, gdzie drugi koniec nie ma powodu jej przyjąć. Przeglądarka widzi przekroczenie czasu zamiast odmowy, co jest cechą ścieżki jednokierunkowej, a nie zamkniętego portu.

Potwierdź kształt, zanim zmienisz routing: nasłuch działa, lokalne żądanie się udaje, a żądanie zewnętrzne nie daje żadnej odpowiedzi. Te trzy obserwacje razem wskazują na ścieżkę powrotną, a nie na konfigurację serwera WWW. Tak czysta asymetria jest użyteczniejsza niż jakikolwiek wiersz logu, bo wyklucza nasłuch, zanim przeczytasz choć jeden komunikat błędu.

Podczas pracy trzymaj otwartą niezależną ścieżkę administracyjną. Reguła, która psuje twoją własną sesję SSH, zamienia dziesięciominutową poprawkę w fizyczną wizytę.

Co naprawdę dopasowuje selektor źródła

W routingu polityki Linuksa reguła taka jak from 192.168.50.2 dopasowuje pakiety, których źródłem jest ten adres. Nie koduje faktu, że pakiet kontynuuje rozmowę, która weszła przez domowy router, i nie wie, który proces go utworzył. Adres w tym przykładzie jest ilustracyjny; zastąp go adresem, którego twój host naprawdę używa. Traktuj tę linię jako stwierdzenie o adresach i nic więcej.

Jeśli wybrana tabela dostarcza zwykłą trasę domyślną, każdy pakiet z tym źródłem może skorzystać z tego samego wyjątku. Inna usługa przypisana do tego samego adresu dziedziczy go, a aplikacja, która celowo wiąże się z tym adresem, również go dziedziczy. Dokumentacja reguł polityki wymienia źródło, cel, protokół, port, znacznik i priorytet jako osobne selektory, co przypomina, że samo źródło jest najgrubszym dostępnym.

Priorytet decyduje o wyniku. Wyszukiwania przebiegają w kolejności i pierwsza tabela, która daje wynik, może zakończyć wyszukiwanie, więc reguła umieszczona zbyt wcześnie może ukryć bardziej konkretną trasę, którą dostarczyłaby późniejsza tabela. Czytaj całą uporządkowaną listę, a nie tylko wiersz, który dodałeś. Reguła, która nigdy nie pasuje, nic nie kosztuje, a ta, która pasuje zbyt wcześnie, po cichu zmienia wszystko za sobą.

Sprawdź ścieżkę powrotną i ruch, którego nie zamierzałeś

Przeczytaj reguły i tabele, a potem zapytaj jądro, którą trasę wybrałaby konkretna para źródła i celu. Testowanie z samego hosta to nie to samo co testowanie z zewnątrz, więc zrób jedno i drugie.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Następnie przyjmij nowe połączenie zewnętrzne i osobno żądanie, które nadal musi wyjść przez VPN. Jeśli drugie wychodzi teraz bezpośrednio, wyjątek jest szerszy niż rozwiązywany problem, a testem, który się liczy, jest ten, którego nie zamierzałeś zmieniać.

Sprawdzenie publicznego adresu w przeglądarce raportuje tylko żądania wykonane przez tę przeglądarkę. Nie mówi nic o odpowiedziach serwera WWW, o wyborze źródła przez inną lokalną aplikację ani o tym, co dzieje się z ruchem administracyjnym po następnym ponownym połączeniu VPN.

Zdecyduj, jak wąski może być wyjątek

Dwa projekty są obronne i należy je wybrać świadomie. Jeśli host istnieje po to, by publikować tę usługę, a jego ruch wychodzący nie ma znaczenia, dedykowany adres lokalny z polityką tylko dla WAN jest rozsądnym rozwiązaniem, pod warunkiem że akceptujesz cały zakres. Jeśli kwalifikować mają się tylko określone połączenia przychodzące, wybór adresu jest zbyt gruby i przed nim powinien stać projekt świadomy połączeń.

Zapisz umowę, na której się opierasz: publiczne mapowanie, adres hosta, na który dostarczane jest żądanie, i ścieżkę, którą powinna przejść odpowiedź. Usługa przychodząca publikowana przez dostawcę VPN to inna umowa niż publikowana przez domowy router, a wyjątek skopiowany z jednego przykładu często jest błędny dla drugiego.

Przechowuj politykę w komponencie, który zarządza routingiem, zamiast wklejać polecenie do pliku startowego. Kolejność reguł, sprzątanie po zmianie sieci i powtórzenie po restarcie muszą przetrwać, a niesprawdzony plik startowy zwykle zawodzi w momencie, gdy nie patrzysz. Zakończ wynikiem akceptacji, którego możesz bronić: jedna opublikowana witryna przywrócona i jeden niepowiązany przepływ bez zmian.