Użytkownik bramy w Access Server: routing LAN oddziału klienta

Możesz pingować adres tunelu klienta OpenVPN i nadal nie dotrzeć do żadnego hosta w sieci LAN za nim. Access Server przydziela klientowi adres z puli VPN, a adres puli to wszystko, co serwer uznaje za swoje. Prefiks oddziału jest osobnym faktem, który trzeba zadeklarować, a nawet wtedy oddział potrzebuje przekazującego, a centrala trasy powrotnej. Trasa wpisana w złym miejscu wygląda jak rozwiązanie i niczego nie zmienia.

Dwa adresy, dwa różne roszczenia własności

Gdy klient się łączy, Access Server przydziela mu adres ze skonfigurowanej puli VPN, na przykład 10.90.0.0/24. To przydzielenie jest dzierżawą dla jednego hosta. Nic w połączeniu nie mówi, że ten sam klient stoi także przed 10.60.0.0/24, a serwer nie będzie zgadywał: prefiks LAN jest osiągalny przez konkretnego klienta tylko wtedy, gdy administrator go zadeklaruje.

Dlatego trasa statyczna na innym komputerze nie pomaga. Trasa mówi wyślij 10.60.0.0/24 na ten adres, ale jeśli adres należy do klienta, który nigdy nie został oznaczony jako brama, serwer nie ma powodu dostarczać tam tych pakietów, a stos klienta może je odrzucić. Deklaracja i trasa to dwie połowy jednego mechanizmu.

Co właściwie instaluje ustawienie bramy

W Admin Web UI deklaracja jest właściwością użytkownika: włącz Configure VPN gateway u użytkownika łącznika i wpisz rzeczywisty prefiks oddziału w Network on the VPN client side. Ten użytkownik uwierzytelnia się jak każdy inny, więc potrzebuje polityki poświadczeń odpowiedniej dla urządzenia bez nadzoru, a jego profil automatycznego logowania jest tajemnicą, nie plikiem wygody.

Za tym polem serwer traktuje prefiks jako osiągalny przez adres puli tego klienta, a konfiguracja routingu w Access Controls decyduje, co ogłasza się innym klientom: trasy wysyłane zwykłym klientom i reguły dostępu zezwalające na ruch z sieci centrali do adresów i podsieci klientów. Włącz routing dla sieci, które mają docierać do oddziału, i utrzymuj listę dozwolonych krótką.

Dyrektywa w stylu Community wklejona do generowanego pliku nie bierze udziału w tym modelu. Produkt jest właścicielem tabeli routingu, którą wysyła; ręcznie edytowana linia zostaje nadpisana lub zignorowana.

Uzupełnij obie trasy powrotne sieci

Konkretny plan: centrala 10.40.0.0/24, oddział 10.60.0.0/24, pula VPN 10.90.0.0/24, a Access Server osiągalny pod prywatnym adresem po stronie centrali. Router centrali potrzebuje tras do prefiksu oddziału i do puli, obu prowadzących do Access Server. Bez nich tunel niesie żądanie, a odpowiedź wychodzi przez bramę domyślną, co daje klasyczne połączenie na wpół otwarte.

W oddziale łącznik musi przekazywać pakiety nieadresowane do niego: przekazywanie IP w systemie operacyjnym plus zezwolenie ograniczone do interfejsów tunelu i LAN; w Linuksie to net.ipv4.ip_forward=1 razem z regułami łańcucha forward, w Windows to routing and remote access. Następnie hosty oddziału potrzebują trasy powrotnej: albo łącznik jest ich bramą domyślną, albo istniejąca brama niesie konkretne trasy do prefiksów centrali i puli.

Tabela routingu łącznika nie rekonfiguruje każdego hosta w sieci LAN oddziału. Jeśli hosty wskazują inny router, trasy powrotne należą tam, a on musi zaakceptować, że widziany adres źródłowy nie jest sąsiadem w lokalnej podsieci.

Czytaj awarię jako ścieżkę, nie jako uprawnienie

Testuj w ustalonej kolejności. Najpierw dozwolona usługa z Access Server do hosta w oddziale, potem ta sama usługa ze zwykłego hosta centrali, potem kierunek odwrotny, jeśli polityka pozwala. Jeśli pierwszy przejdzie, a drugi nie, problemem są wysłane trasy lub reguły dostępu. Jeśli oba przejdą, ale odpowiedzi nie wracają, sprawdź przekazywanie w oddziale i trasę powrotną w centrali.

Zapora hosta to następny podejrzany, bo przy dostępie routowanym cel widzi jako źródło adres centrali lub puli. Reguła napisana dla lokalnej podsieci nie będzie pasować i pakiet zostanie odrzucony.

Dwa projekty wymagają więcej. Nakładające się prefiksy między lokalizacjami czynią cel niejednoznacznym i wymagają przenumerowania lub translacji, a klastrowy Access Server wymaga, aby każdy węzeł miał działającą ścieżkę do łącznika oddziału, a nie jeden węzeł trzymający trasę. Wprowadzaj zmiany zwykłą ścieżką zapisu i aktualizacji, połącz łącznik ponownie i zweryfikuj z obu stron; pełny restart każdej maszyny nie jest częścią procedury.

Samouczek site-to-site Access Server wymienia te same ustawienia w kolejności produktu; warto go raz przejść, zanim dostosujesz projekt do własnych prefiksów.