pfSense OpenVPN: dotarcie do sieci za innym routerem

Twój laptop dociera do sieci LAN pfSense przez VPN i nadal nie potrafi dotrzeć do usługi dwa skoki głębiej, a różnicą jest jedna decyzja routingu na właściciela. Trzy urządzenia muszą się zgodzić, zanim pakiet ukończy podróż tam i z powrotem: klient, zapora i router, który faktycznie posiada sieć docelową. Pominięcie któregokolwiek z nich daje identyczny objaw.

Przed zmianą reguły prześledź jeden pakiet przez te trzy decyzje, bo każdy właściciel ma inną kontrolę i inny tryb awarii.

Jeden pakiet, trzy decyzje routingu

Klient decyduje, czy cel należy do tunelu, i może decydować wyłącznie na podstawie tego, co wie: wypchniętej trasy, trasy lokalnej lub trasy domyślnej, która już obejmuje wszystko. pfSense decyduje, gdzie wysłać pakiet dalej, co dla sieci za innym routerem oznacza trasę statyczną przez osiągalną bramę na właściwym interfejsie. Router poniżej decyduje, czy zna drogę powrotną do puli VPN, a jeśli nie zna, odpowiedź jest odrzucana lub wysyłana w bezużyteczne miejsce. Każda decyzja jest niezależna od dwóch pozostałych.

Awaria którejkolwiek z nich daje ten sam raport użytkownika. Dlatego kolejność debugowania jest ważniejsza niż narzędzia.

Daj klientowi prefiks, nie domysł

Na serwerze pfSense SSL/TLS z siecią tunelu IPv4 większą niż /30 pole IPv4 Local network(s) rozdziela trasy do klientów podczas połączenia. Dodaj tam dolny prefiks, zamiast liczyć na to, że klient go wymyśli. Następnie po połączeniu odczytaj rzeczywistą tabelę klienta, bo profil z route-nopull lub filtr tras może zignorować to, co wysłał serwer. Serwer może być całkowicie poprawny, podczas gdy klient nic nie instaluje.

Inne tryby serwera i topologie mają inne ograniczenia, a polityka dla klienta lub połączenia może zmienić to, co otrzymuje konkretny klient. Sprawdzaj na kliencie, który ma znaczenie, a nie na tym, który przypadkiem przetestowałeś pierwszy.

Skieruj pfSense na wewnętrzny router

Trasa statyczna w pfSense wymaga zdefiniowanej i osiągalnej bramy, a interfejs wybrany dla tej bramy musi być tym, który faktycznie do niej dociera, jak opisuje przewodnik Netgate po trasach statycznych. W układzie ilustracyjnym łącze tranzytowe to 192.168.77.1 na zaporze i 192.168.77.2 na wewnętrznym routerze, a sieć usług to 172.16.30.0/25 za nim. Trasa podaje wtedy prefiks i następny skok, a nie adres usługi. Użycie adresu z odległej sieci jako bramy to częsty sposób zbudowania trasy, która wygląda poprawnie i nigdzie nie przekazuje.

Nadanie interfejsowi nazwy nie opisuje sieci za nim. Trasa statyczna jest tym opisem.

Druga strona musi znać pulę

Router poniżej potrzebuje trasy powrotnej dla puli, w tym przykładzie 10.55.0.0/24 przez 192.168.77.1, chyba że trasa domyślna lub protokół dynamiczny już ją zapewnia. Brama samego hosta usługi musi prowadzić do tego routera, co zwykle jest prawdą, gdy router jest jego bramą domyślną, a fałszem, gdy host skonfigurowano ręcznie. Routing polityczny na zaporze może też nadpisać tabelę dla określonego ruchu, więc sprawdź, czy reguła wybiera inną bramę, zanim uznasz trasę za błędną.

Ten projekt nie wymaga tłumaczenia, a pozostawienie widocznego adresu źródłowego klienta pozwala sieci poniżej stosować własną politykę.

Do odbioru prześledź jedno nowe żądanie przez wejście tunelu, wewnętrzne wyjście zapory i odpowiedź z celu. Jeśli zamiast tego świadomie stosuje się tłumaczenie, zapisz, jakie źródło widzi sieć poniżej i jak ma wracać odpowiedź.

Zapisz plan trzech właścicieli obok dozwolonej aplikacji, aby następny administrator mógł odtworzyć ścieżkę, a nie odkrywać ją od nowa.