Ta sama podsieć po obu stronach: zmapuj zdalny LAN na wolny zakres

Dom i biuro używają obu 192.168.1.0/24, więc żądanie do 192.168.1.1 ma dwie możliwe odpowiedzi i klient wybiera jedną bez pytania. Przenumerowanie działającej sieci biurowej rzadko bywa popularne, a adresy routera są często wpisane w drukarki, kamery i dokumentację. Mapowanie adresów po stronie klienta może zamiast tego przedstawić sieć zdalną pod wolnym zakresem, a część hosta może pozostać taka sama, dzięki czemu 192.168.1.20 pojawia się jako 10.203.41.20. Haczyk polega na tym, że implementują je tylko niektóre klienty i że nie robi ono nic dla ścieżki powrotnej.

Dwa widoki tego samego hosta

Mapowanie zachowuje część hosta i zmienia tylko część sieciową. Ta sama maszyna odpowiada wtedy pod dwoma adresami w zależności od tego, gdzie stoisz. Zapisanie obu kolumn przed konfiguracją czegokolwiek zapobiega późniejszemu błędnemu odczytowi logów i reguł zapory.

Lokalne urządzenia w domu zachowują własne adresy 192.168.1.x i o to chodzi w ćwiczeniu. Drukarka w sąsiednim pokoju pozostaje osiągalna, a biuro pojawia się pod zakresem, który nie koliduje.

Kolejność argumentów to cała sztuczka

Opcja przyjmuje kierunek, sieć i maskę oraz alias: pierwsza sieć to to, co widzi klient, alias to to, co widzi serwer. Dla zasobów żyjących za zdalną bramą kierunkiem jest forma celu. Zamiana obu sieci dlatego, że ostatni argument nazywa się alias, to błąd, który tworzy tunel łączący się i niczego nie mapujący.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Trasa to to, co wysyła pakiety klienta dla nowego zakresu do tunelu; tłumaczenie przepisuje cel po drodze. Odpowiedź z 192.168.1.20 jest przepisywana z powrotem na 10.203.41.20, aby gniazdo po stronie klienta pozostało spójne. Pojedynczy host działa tak samo z maską pełnej długości, o ile trasa i mapowanie opisują ten sam adres.

To mapowanie adresów, nie mapowanie portów. Dwóch usług na jednym hoście nie da się nim rozdzielić, a protokół, który osadza adresy IP w swojej ładowności, nadal będzie widział prawdziwe.

Mapowanie nie tworzy ścieżki powrotnej

Tłumaczenie odbywa się po stronie klienta, więc serwer nadal musi kierować odpowiedzi do tunelu, a jego zapora nadal musi je przepuszczać. Jeśli zdalna brama nie wie, jak dotrzeć do podsieci tunelu, żądanie nadchodzi, a odpowiedź wychodzi złymi drzwiami; mapowanie tylko sprawia, że awaria wygląda jak problem klienta.

Reguły po stronie serwera powinny opisywać adresy, które istnieją na serwerze po tłumaczeniu, a nie zakres widoczny dla klienta. Kopiowanie aliasu do reguły zezwalającej marnuje popołudnie, bo żaden pakiet po tej stronie go nie niesie.

Wybierz zakres aliasu, który nie koliduje z niczym innym, co klient trasuje: inny VPN, sieć kontenerów, drugie biuro. Kolizja tutaj ponownie wprowadza pierwotną niejednoznaczność pod innym numerem i trudniej ją zauważyć, bo adresy wyglądają nieznajomo.

Nazwy i ładowności przeżywają tłumaczenie

Nazwa hosta, która rozwiązuje się na prawdziwy 192.168.1.20, wysyła przeglądarkę do urządzenia lokalnego zamiast zdalnego, niezależnie od tego, co mówi tabela trasowania. Odpowiedź prywatnego DNS musi wskazywać zakres widoczny dla klienta, podczas gdy certyfikat TLS nadal niesie nazwę, której oczekuje aplikacja. Testuj nazwą, a nie adresem, bo adres może działać, gdy nazwa cicho rozwiązuje się w złym kierunku. Gdy zdalna brama obsługuje także tę strefę, jej własne rekordy również potrzebują zakresu widocznego dla klienta.

Przekierowania, osadzone URL i aplikacje, które podają własny adres w ładowności, mogą się zepsuć w sposób, którego żadne mapowanie pakietów nie naprawi. Traktuj je jako problem aplikacji i oszacuj wysiłek odpowiednio, zanim obiecasz, że przenumerowanie nie jest konieczne.

Trzy kontrole przed zobowiązaniem

Po pierwsze, potwierdź implementację klienta. Community OpenVPN obsługuje tę opcję; baza kodu OpenVPN 3 wymienia ją wśród nieobsługiwanych funkcji, więc profil wysłany do klienta w stylu Connect może ją po prostu zignorować. Dyrektywa, która jest akceptowana i nigdy nie stosowana, jest gorsza od błędu, bo tunel wygląda zdrowo.

Po drugie, sprawdź trasę i tłumaczenie osobno za pomocą krótkiego okna diagnostycznego przy wysokiej szczegółowości, a następnie przetestuj rzeczywistą usługę zamiast ping. Po trzecie, potwierdź, że lokalny router i zdalny zasób pozostają rozróżnialne od klienta, bo to był pierwotny cel.

Jeśli klient nie potrafi wykonać tłumaczenia, poproś o pomoc po stronie bramy lub zaakceptuj przenumerowanie. Dodawanie kolejnych tras dla tego samego adresu nie jest projektem.