NAT na VPN serveru, nebo na routeru? Obojí může fungovat

Označit připojení jako výchozí trasu na notebooku je krok, který si všichni pamatují, a právě on nic nezmění na bráně. Klient nyní posílá internetové požadavky do tunelu; zda opustí budovu, závisí na předávání, překladovém bodě a zpětné cestě, která se dostane na privátní adresu klienta. Dvě uspořádání mohou dodat všechny tři, kladou práci na různá místa a obě selhávají stejným tichým způsobem, když nikdo nevlastní směr odpovědi. Volba mezi nimi je otázka, kdo má vidět klientský pool.

Mýtus: klientská trasa vytváří výstup

Vynucené tunelování je politika na straně klienta: rozhoduje, že provoz půjde na VPN adaptér místo fyzického. Dokumentace Microsoftu k VPN směrování popisuje toto rozdělení a vynucené chování a je to tvrzení o směrovací tabulce klienta, nikoli o pravidlech předávání serveru. Z pohledu klienta je tunelem místo, kde žije internet; z pohledu brány přišel paket z adresy, o které nikdo výše nikdy neslyšel. Ani jedna strana není sama o sobě špatně nakonfigurovaná, a proto selhání vypadá pro člověka u notebooku jako rozbitý server.

Tento nesoulad je celý problém, který zbytek článku řeší. Něco musí udělat privátní adresu klienta vratnou, a volba je kde.

Nejprve nakreslete zpětnou cestu

Zapište cestu se skutečnými adresami, než se dotknete jakéhokoli nastavení, a označte na ní dva kandidátské překladové body. Tato laboratoř používá VPN pool 10.70.0.0/24 s jedním klientem na 10.70.0.37, LAN adresu serveru 172.16.40.10, router na 172.16.40.1 a veřejný výstup 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?)

Server, který už prohlíží internet, dokazuje jen svou vlastní cestu. Paket předaný jménem klienta je jiné rozhodnutí, které činí politika předávání na stejném stroji, a obvykle chybí právě ona. Označení tří rozhodovacích bodů na diagramu udržuje rozhovor vždy o jednom z nich.

Možnost A: překlad na VPN serveru

Zde server přeloží zdroj klienta na svou vlastní LAN adresu, než paket předá routeru, a router na cestě ven použije své obvyklé překládání. Na odpovědi mapování routeru obnoví adresu serveru a mapování serveru obnoví adresu klienta. Dvě stavové překlady v sérii jsou normální a proveditelné, pokud jsou obě zaznamenané; router nikdy nepotřebuje trasu k poolu, což je přitažlivost tohoto uspořádání.

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

Pomocí těchto čtení zjistěte, co server už má, místo abyste předpokládali, že NAT je na místě. Pravidlo masquerade v Linuxu zkopírované z blogu není konfigurace Windows a povolení v hostitelském firewallu pro VPN posluchač není stejná politika jako povolení předat klientský požadavek dál. Potvrďte roli předávání serveru z jeho vlastního rozhraní pro správu, potom se podívejte na překlad zvlášť, protože obojí často zapínají různé části nasazení.

Možnost B: přenést pool na router

V druhém uspořádání server předává skutečnou zdrojovou adresu klienta a router ji překládá. To udržuje klientský pool viditelný na hraně, což pomáhá, pokud je router místem, kde žije provozní politika, logování nebo inspekce. Znamená to také, že router potřebuje zpětnou trasu pro 10.70.0.0/24 ukazující na 172.16.40.10, plus internetovou politiku, která tento prefix skutečně zahrnuje; pravidlo napsané pro LAN podsíť se na pool tiše nerozšiřuje.

Zvolte to, když je hraniční zařízení zamýšleným vlastníkem politiky a může přijmout další prefix ve svých směrovacích a překladových tabulkách. Zvolte překlad na straně serveru, když má pool zůstat výše neviditelný a router nespravuje stejný tým. Ani jednu možnost neimplikuje žádné zaškrtávací pole na klientovi a ani jedna není obecně bezpečnější; umisťují viditelnost a údržbu na různá místa.

Udělejte DNS, IPv6 a přijetí explicitními

Překlad adres neopravuje překlad jmen. Klient může použít resolver dodaný s profilem VPN, privátní resolver pro konkrétní jmenné prostory nebo schválený veřejný, a nedostupný resolver pod touto politikou bude selhávat dál, i když směrování funguje. Testujte jméno a adresu odděleně, aby se obě selhání nikdy nesloučila do jednoho hlášení.

IPv6 potřebuje v návrhu vlastní odstavec. Fungující překlad IPv4 nic neříká o tom, zda klienti IPv6 mají trasu, platný veřejný zdroj nebo politiku, která je zablokuje, když tunel spadne. Nechat to nevyslovené znamená, že polovina klientů tiše obchází bránu, zatímco druhá polovina funguje.

Pro přijetí sledujte jeden povolený klientský požadavek a jeho odpověď přes obě hranice a zapište adresu, kterou má každá hranice v tu chvíli vidět. Právě tento záznam dělá z příští změny poolu pětiminutovou úpravu místo hádky o to, kdo vlastní chybějící zpětnou trasu. Uchovávejte záznam u klientského profilu, ne v tiketu, protože profil je to, co příští inženýr najde první.