Dlaczego klienci Access Server są nieosiągalni z sieci LAN

Laptop się łączy, tunel działa, a żądania do wewnętrznej usługi zawieszają się na etapie połączenia. W samej usłudze żądanie przychodzi z adresu takiego jak 10.90.0.25, odpowiedź wychodzi w stronę bramy domyślnej i nic nie wraca, bo ta brama nie ma pojęcia, gdzie znajduje się 10.90.0.25. Z drugiej strony ten sam błąd wygląda jak wewnętrzny host, który nie potrafi pingować podłączonego klienta. Oba to jeden brakujący obiekt: trasa powrotna do puli klientów VPN, którą może dodać tylko sieć prywatna.

Przeczytaj adres źródłowy widziany przez usługę

To jedno pole decyduje o całej reszcie. Jeśli wewnętrzna usługa widzi adres puli, Access Server trasuje, a nie ukrywa ruchu klientów, i każda odpowiedź musi być trasowana z powrotem do puli. Jeśli zamiast tego widzi własny prywatny adres serwera, serwer maskuje i ścieżka powrotna już działa, ale kosztem utraty wszelkiej tożsamości pojedynczego klienta w logach i regułach dostępu usługi.

Porównaj oba końce, zanim cokolwiek zmienisz. Na serwerze wylistuj interfejsy tunelu i ich adresy; na kliencie potwierdź, który z tych adresów faktycznie posiada; na wewnętrznym hoście obejrzyj aktywne połączenie.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Ostatnie polecenie to właśnie to, które zawodzi w zepsutym przypadku: albo zgłasza prefiks tunelu jako nieosiągalny, albo, co gorsza, zwraca twoją bramę domyślną, i tak odpowiedzi trafiają do internetu.

Nie zakładaj tylko jednej puli. Serwer może mieć zakres dynamiczny oraz statyczne przypisania dla poszczególnych użytkowników, a adres statyczny może leżeć całkowicie poza prefiksem dynamicznym. Jeśli trasujesz tylko zakres, który pamiętasz, użytkownicy z adresami stałymi pozostają zepsuci, a wszyscy inni zgłaszają problem jako rozwiązany.

Dodaj trasę tam, gdzie zapada decyzja o odpowiedzi

Trasa należy do bramy, której wewnętrzna usługa już używa, a nie do usługi, chyba że sama trasuje swój ruch. Wskaż ją na osiągalny prywatny adres Access Server, który różni się od adresu tunelu posiadanego przez klienta.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

W sieci chmurowej to samo stwierdzenie staje się wpisem tabeli tras, którego celem jest instancja lub interfejs sieciowy, na którym działa serwer, z wyłączoną kontrolą źródła i miejsca docelowego na tym interfejsie. Zwróć uwagę, czego ten wpis nie robi: trasa nie jest nadaniem dostępu, więc grupy zabezpieczeń, ACL sieciowe i firewall hosta nadal muszą przepuszczać ruch.

Uczyń ją trwałą i utrzymuj uczciwe rozmiary pul. Dwie nieprzyległe pule wymagają dwóch tras, a pula, która wyrasta poza skonfigurowany prefiks, po cichu tworzy klientów, których odpowiedzi nie mają gdzie trafić. Jeśli kontrolujesz zakresy pul, wybierz podsumowanie, które możesz trasować raz i zostawić.

Przekazywanie i filtry muszą się zgadzać z trasą

Trasowanie to tylko połowa drogi. Serwer musi mieć pozwolenie na przekazywanie między tunelem a interfejsem prywatnym, co w Linuksie oznacza net.ipv4.ip_forward plus łańcuch przekazywania zezwalający parze interfejsów, a na utwardzonym hoście zwykle osobną jawną regułę dla każdego kierunku.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Filtrowanie stanowe wyjaśnia objaw, który prowadzi ludzi na złą drogę. Odpowiedź wewnątrz ustanowionego przepływu nie potrzebuje nowej reguły wejściowej, więc połączenie, które wisi po SYN-ACK, nie jest blokowane przez brakującą regułę akceptacji; jest odrzucane lub źle trasowane. Zachowaj to rozróżnienie, bo oddziela zmianę trasowania od zmiany firewalla.

Asymetryczne ścieżki powrotne to cichsza wersja tego samego problemu. Jeśli do puli prowadzą dwie trasy i odpowiedź wybiera tę, która wychodzi innym interfejsem niż ten, na który przyszło żądanie, ścisłe filtrowanie ścieżki powrotnej ją odrzuca i przepływ zawodzi tylko u niektórych klientów.

Trasowany czy maskowany: wybierz świadomie

Tryb trasowany zachowuje adres puli klienta w usłudze, co umożliwia logowanie i politykę dla poszczególnych klientów, a w zamian każda sieć wewnętrzna, która ma odpowiedzieć klientowi, potrzebuje trasy puli. Tryb maskowany usuwa ten wymóg, bo odpowiedzi wracają do serwera, ale usługa nie odróżnia już jednego klienta od drugiego i nie może nic zainicjować w stronę konkretnego klienta.

Zmiana tego zachowania na działającym serwerze zrywa istniejące sesje, więc najpierw przetestuj z jednym klientem i jednym przepływem. Jeśli przełączenie jest właściwą odpowiedzią, to decyzja konfiguracyjna na serwerze, a nie coś, co obchodzi się, dodając trasy, które później staną się zbędne.

Podsieć za klientem to osobne zadanie

Dotarcie do urządzenia w sieci LAN samego laptopa to nie to samo co dotarcie do adresu tunelu laptopa. Wymaga, aby klient działał jako brama podsieci: zadeklarowana sieć po stronie klienta, włączone przekazywanie w systemie operacyjnym klienta oraz trasa w tej sieci LAN z powrotem do klienta. Dodanie trasy sieci prywatnej dla domowego zakresu laptopa tego nie robi i tworzy konflikty, gdy dwóch użytkowników ma ten sam zakres domowy.

Kierunek też jest kwestią polityki. Zezwolenie klientowi na otwarcie połączenia do wewnętrznej usługi nie pozwala automatycznie wewnętrznemu hostowi otworzyć połączenia do tego klienta. Sprawdź politykę dostępu serwera i firewall hosta klienta, zanim uznasz, że ścieżka jest zepsuta.

Zweryfikuj jednym przepływem i jednym zrzutem

Udowodnij ścieżkę jednym połączeniem zamiast ogólnym testem osiągalności. Obserwuj ten sam przepływ po obu stronach: żądanie docierające do usługi i odpowiedź ją opuszczającą.

tcpdump -ni any host 10.90.0.25 and port 443

Przed poprawką zrzut pokazuje odpowiedź wychodzącą w stronę bramy, która jej nie strasuje. Po poprawce odpowiedź wychodzi w stronę serwera i przepływ się kończy. Następnie potwierdź trasę, której brama użyłaby dla drugiego adresu klienta, aby nieobjęta pula ujawniła się teraz, a nie za tydzień.

Zakończ czterema kontrolami, które to zamykają: adres źródłowy w usłudze odpowiada zamierzonemu trybowi, brama ma trasę do każdej używanej puli, przekazywanie i filtry pozwalają na oba kierunki, a jeden rzeczywisty przepływ przechodzi od początku do końca. Najczęstsze pytania o trasowanie Access Server podaje tę samą zasadę dla zainstalowanej wersji, której obsługiwany interfejs konfiguracji może różnić się od starszych przewodników.