NAT na serwerze VPN czy na routerze? Oba rozwiązania mogą działać

Oznaczenie połączenia jako trasy domyślnej na laptopie to krok, który wszyscy pamiętają, i właśnie on niczego nie zmienia na bramie. Klient wysyła teraz żądania internetowe do tunelu; to, czy opuszczą budynek, zależy od przekazywania dalej, punktu tłumaczenia i drogi powrotnej, która dociera do prywatnego adresu klienta. Dwa układy mogą dostarczyć wszystkie trzy elementy, umieszczają pracę w różnych miejscach i oba zawodzą w ten sam cichy sposób, gdy nikt nie odpowiada za kierunek odpowiedzi. Wybór między nimi to pytanie o to, kto powinien widzieć pulę klientów.

Mit: trasa klienta buduje wyjście

Wymuszone tunelowanie to polityka po stronie klienta: decyduje, że ruch trafia do adaptera VPN, a nie do fizycznego. Dokumentacja Microsoftu dotycząca routingu VPN opisuje ten podział i wymuszone zachowanie, i jest to stwierdzenie o tablicy tras klienta, a nie o regułach przekazywania serwera. Z punktu widzenia klienta tunel to miejsce, w którym mieszka internet; z punktu widzenia bramy pakiet przyszedł z adresu, o którym nikt wyżej nigdy nie słyszał. Żadna ze stron nie jest sama w sobie źle skonfigurowana, i dlatego awaria wygląda dla osoby przy laptopie jak zepsuty serwer.

Ta niezgodność to cały problem, który rozwiązuje reszta artykułu. Coś musi uczynić prywatny adres klienta zwrotnym, a wybór dotyczy tego, gdzie.

Najpierw narysuj drogę powrotną

Zapisz drogę z rzeczywistymi adresami, zanim dotkniesz jakiegokolwiek ustawienia, i zaznacz na niej dwa możliwe punkty tłumaczenia. To laboratorium używa puli VPN 10.70.0.0/24 z jednym klientem pod 10.70.0.37, adresu LAN serwera 172.16.40.10, routera pod 172.16.40.1 i publicznego wyjścia 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Serwer, który już przegląda internet, dowodzi tylko własnej drogi. Pakiet przekazany w imieniu klienta to inna decyzja, podejmowana przez politykę przekazywania na tej samej maszynie, i zwykle brakuje właśnie jej. Oznaczenie trzech punktów decyzyjnych na diagramie utrzymuje rozmowę o jednym z nich naraz.

Opcja A: tłumaczenie na serwerze VPN

Tutaj serwer tłumaczy źródło klienta na własny adres LAN, zanim przekaże pakiet routerowi, a router stosuje swoje zwykłe tłumaczenie na wyjściu. W odpowiedzi mapowanie routera przywraca adres serwera, a mapowanie serwera przywraca adres klienta. Dwa stanowe tłumaczenia szeregowo są normalne i wykonalne, pod warunkiem że oba są zapisane; router nigdy nie potrzebuje trasy do puli, i to jest zaleta tego układu.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Użyj tych odczytów, aby zobaczyć, co serwer już ma, zamiast zakładać, że NAT jest na miejscu. Reguła masquerade w Linuksie skopiowana z bloga nie jest konfiguracją Windows, a zezwolenie w zaporze hosta dla nasłuchu VPN nie jest tą samą polityką co pozwolenie na przekazanie żądania klienta dalej. Potwierdź rolę przekazywania serwera w jego własnym interfejsie zarządzania, a następnie przyjrzyj się tłumaczeniu osobno, ponieważ obie rzeczy są często włączane przez różne części wdrożenia.

Opcja B: przenieść pulę na router

W drugim układzie serwer przekazuje prawdziwy adres źródłowy klienta, a router go tłumaczy. To utrzymuje pulę klientów widoczną na krawędzi, co pomaga, jeśli router jest miejscem, w którym żyje polityka ruchu, logowanie lub inspekcja. Oznacza to również, że router potrzebuje trasy powrotnej dla 10.70.0.0/24 wskazującej na 172.16.40.10, a także polityki internetowej, która rzeczywiście obejmuje ten prefiks; reguła napisana dla podsieci LAN nie rozszerza się cicho na pulę.

Wybierz to, gdy urządzenie brzegowe jest zamierzonym właścicielem polityki i może przyjąć kolejny prefiks w swoich tablicach routingu i tłumaczenia. Wybierz tłumaczenie po stronie serwera, gdy pula ma pozostać niewidoczna wyżej, a router nie jest administrowany przez ten sam zespół. Żadna z opcji nie wynika z żadnego pola wyboru na kliencie i żadna nie jest ogólnie bezpieczniejsza; umieszczają widoczność i utrzymanie w różnych miejscach.

Uczyń DNS, IPv6 i akceptację jawnymi

Tłumaczenie adresów nie naprawia rozwiązywania nazw. Klient może używać resolvera dostarczonego z profilem VPN, prywatnego resolvera dla określonych przestrzeni nazw lub zatwierdzonego publicznego, a nieosiągalny resolver w ramach tej polityki będzie nadal zawodził po uruchomieniu routingu. Testuj nazwę i adres osobno, aby obie awarie nigdy nie stopiły się w jeden raport.

IPv6 potrzebuje własnego akapitu w projekcie. Działające tłumaczenie IPv4 nic nie mówi o tym, czy klienci IPv6 mają trasę, ważne publiczne źródło lub politykę, która blokuje ich, gdy tunel padnie. Pozostawienie tego niewypowiedzianym oznacza, że połowa klientów po cichu omija bramę, podczas gdy druga połowa działa.

W celu akceptacji prześledź jedno dozwolone żądanie klienta i jego odpowiedź przez obie granice i zapisz, jaki adres każda granica powinna w tym momencie widzieć. Ten zapis sprawia, że następna zmiana puli to pięciominutowa edycja, a nie spór o to, kto posiada brakującą trasę powrotną. Przechowuj zapis przy profilu klienta, a nie w zgłoszeniu, ponieważ profil jest tym, co następny inżynier znajdzie pierwsze.