SoftEther SecureNAT: DHCP i NAT to dwie decyzje

SecureNAT uruchamia wirtualny DHCP i wirtualny NAT, a każde z nich może zawieść samodzielnie. Sprawdź dzierżawę, potem drogę na zewnątrz i resolver, zanim obwinisz koncentrator.

SecureNAT to jedno pole wyboru, które włącza dwie usługi, i stąd bierze się większość nieporozumień wokół niego. Wirtualny serwer DHCP daje klientowi adres, maskę, bramę i często resolver. Wirtualny NAT przekazuje pakiety poza tę bramę, korzystając z własnego stosu sieciowego hosta serwera. Oba stoją obok siebie w konfiguracji i zawodzą niezależnie: klient może mieć doskonałą dzierżawę i żadnej działającej drogi albo działającą drogę z ustawieniami wskazującymi na niewłaściwy resolver. Sprawdź je jako dwie decyzje, a diagnoza stanie się krótka.

Dwie usługi za jednym polem wyboru

Strona wirtualnego DHCP odpowiada na pytanie o konfigurację: jakie ustawienia otrzymuje ten klient wewnątrz tego wirtualnego koncentratora. Strona wirtualnego NAT odpowiada na pytanie o przekazywanie: gdy klient wysyła pakiet na adres poza koncentratorem, czy serwer go tłumaczy i przekazuje. Pierwsze jest lokalne dla koncentratora i nie wymaga sieci powyżej. Drugie zależy całkowicie od hosta.

Wirtualny interfejs hosta należy do pierwszej decyzji, a nie do drugiej. Jego adres, często domyślnie coś w rodzaju 192.168.30.1, jest bramą oferowaną przez usługę DHCP. To nie jest publiczny adres nasłuchu serwera, a mieszanie obu tworzy reguły zapory i ustawienia klienta wymierzone w maszynę, której w tej sieci nie ma.

Decyzja 1: kto dostarcza adres

Jeśli wirtualny DHCP jest włączony, klienci powinni otrzymać dzierżawę z puli, którą skonfigurowałeś, z wirtualnym interfejsem hosta jako bramą i resolverem, który podałeś. Oglądaj dzierżawę, a nie tekst stanu klienta, ponieważ „połączono” opisuje tunel, a nie przydział adresu:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Dwa tryby awarii warto znać, zanim zaczniesz debugować cokolwiek innego. Klient z pozostałym statycznym adresem z wcześniejszego projektu zachowa go i zignoruje dzierżawę, co wygląda tak, jakby DHCP odmawiał odpowiedzi. A drugie źródło DHCP w segmencie z mostem będzie konkurować o tych samych klientów, co daje przerywane adresy i kolejkę wsparcia, która nie potrafi odtworzyć problemu.

Nakładające się pule też tu należą. Jeśli pula wirtualnego DHCP nakłada się na podsieć LAN hosta lub pulę innego koncentratora, klient dostaje adres trasowany niejednoznacznie i każdy późniejszy test jest niekonkluzywny.

Decyzja 2: kto przekazuje poza wirtualną bramę

Przy włączonym wirtualnym NAT serwer tłumaczy ruch wychodzący z koncentratora i wysyła go przez tablicę routingu hosta. Oznacza to, że łańcuch przekazywania to: klient do wirtualnej bramy, wirtualny NAT do stosu hosta, stos hosta do jego trasy domyślnej. Każde ogniwo może zawieść, nie dotykając pozostałych, a sygnatury awarii się różnią.

Sprawdź drugą decyzję czymś, co musi opuścić koncentrator, a nie czymś dla niego lokalnym. Ping do wirtualnej bramy dowodzi tylko pierwszego ogniwa i niczego więcej:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Jeśli rozwiązywanie nazw działa, ale połączenia z publicznym adresem zawodzą, jesteś w łańcuchu przekazywania, a nie w DHCP. Jeśli zawodzi oba, sprawdź najpierw resolver, ponieważ resolver podany jako nieosiągalny adres wewnętrzny sprawi, że działająca droga będzie wyglądać na całkowicie zepsutą.

Przekazywanie SecureNAT realizuje proces serwera, a nie ścieżka przekazywania w jądrze, której użyłbyś z mostem. To wygodne i wolniejsze niż mostkowanie, a także oznacza, że własne reguły zapory i decyzje routingu hosta nadal dotyczą przetłumaczonego ruchu. Wirtualny NAT nie omija polityki hosta; korzysta z niej.

Własna droga hosta to trzecia rzecz

Wszystko powyżej zakłada, że host serwera może dotrzeć do celu. Host bez działającej trasy w górę, z restrykcyjną polityką wyjściową lub z rodziną adresów, której nie ma, zawiedzie w drugiej decyzji, niezależnie od poprawności konfiguracji koncentratora. Sprawdź host osobno, poza tunelem, zanim przypiszesz jego awarię SoftEtherowi.

SecureNAT nie jest też upoważnieniem do dotarcia do każdej sieci podłączonej do serwera. Tłumaczy i przekazuje ruch, który do niego dociera; decydowanie, do czego host może dotrzeć, wciąż jest zadaniem zapory i routingu hosta, a projekt, który polega na tunelu przy udzielaniu dostępu, jest o jedną złą regułę od udzielenia zbyt wiele.

Rodziny adresów zasługują na własne sprawdzenie. Działający przykład DHCP dla IPv4 nie dowodzi, że w twojej kompilacji jest każda możliwość IPv6, więc przeczytaj podręcznik dla wersji, którą naprawdę uruchamiasz, zanim obiecasz zachowanie podwójnego stosu. Sekcja SecureNAT w podręczniku omawia funkcje wirtualnego NAT i DHCP dla bieżącego wydania.

Sprawdź każdą decyzję jej własnym testem

Przyjmij pierwszą decyzję po sprawdzeniu dzierżawy: adres w puli, brama równa wirtualnemu interfejsowi hosta, resolver ten, który skonfigurowałeś. Przyjmij drugą na podstawie żądania wychodzącego od klienta i spojrzenia na tablicę NAT na serwerze, ponieważ rosnąca liczba sesji to jedyny bezpośredni dowód, że tłumaczenie następuje, a nie tylko że jest włączone.

Potem zapisz podział w notatce projektowej: który komponent dostarcza adres, który przekazuje i przez który interfejs hosta ruch wychodzi. Gdy restart zmieni zachowanie, ta notatka powie ci, który z trzech sprawdzić, zamiast restartować wszystko i mieć nadzieję, że objaw się przesunie.

Jeszcze jedna decyzja należy do zapisu, nawet jeśli nie podejmujesz jej dzisiaj: SecureNAT i most lokalny to różne projekty dla tego samego koncentratora, a koncentrator, który potrzebuje obu, to koncentrator, który potrzebuje innego planu. Wybierz świadomie, zapisz dlaczego, a następna osoba nie będzie musiała odtwarzać tego wstecz z działającej konfiguracji.

Powiązane artykuły