NAT na serveri VPN alebo na routeri? Obe riešenia môžu fungovať

Označiť pripojenie ako predvolenú trasu na notebooku je krok, ktorý si všetci pamätajú, a práve on nič nezmení na bráne. Klient teraz posiela internetové požiadavky do tunela; či opustia budovu, závisí od preposielania, prekladového bodu a spätnej cesty, ktorá sa dostane na privátnu adresu klienta. Dve usporiadania môžu dodať všetky tri, kladú prácu na rôzne miesta a obe zlyhávajú rovnakým tichým spôsobom, keď nikto nevlastní smer odpovede. Voľba medzi nimi je otázka, kto má vidieť klientsky pool.

Mýtus: klientská trasa vytvára výstup

Vynútené tunelovanie je politika na strane klienta: rozhoduje, že prevádzka pôjde na adaptér VPN namiesto fyzického. Dokumentácia Microsoftu k VPN smerovaniu opisuje toto rozdelenie a vynútené správanie, a je to tvrdenie o smerovacej tabuľke klienta, nie o pravidlách preposielania servera. Z pohľadu klienta je tunel miesto, kde žije internet; z pohľadu brány prišiel paket z adresy, o ktorej nikto vyššie nikdy nepočul. Ani jedna strana nie je sama o sebe zle nakonfigurovaná, a preto zlyhanie vyzerá pre človeka pri notebooku ako pokazený server.

Tento nesúlad je celý problém, ktorý rieši zvyšok článku. Niečo musí urobiť privátnu adresu klienta vratnou, a voľba je kde.

Najprv nakreslite spätnú cestu

Zapíšte cestu so skutočnými adresami, skôr než sa dotknete akéhokoľvek nastavenia, a označte na nej dva kandidátske prekladové body. Toto laboratórium používa VPN pool 10.70.0.0/24 s jedným klientom na 10.70.0.37, LAN adresu servera 172.16.40.10, router na 172.16.40.1 a verejný 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, ktorý už prehliada internet, dokazuje len svoju vlastnú cestu. Paket preposlaný v mene klienta je iné rozhodnutie, ktoré prijíma politika preposielania na tom istom stroji, a zvyčajne chýba práve ona. Označenie troch rozhodovacích bodov na diagrame udržiava rozhovor vždy o jednom z nich.

Možnosť A: preklad na serveri VPN

Tu server preloží zdroj klienta na svoju vlastnú LAN adresu, skôr než paket odovzdá routeru, a router na ceste von použije svoje obvyklé prekladanie. Na odpovedi mapovanie routera obnoví adresu servera a mapovanie servera obnoví adresu klienta. Dva stavové preklady v sérii sú normálne a uskutočniteľné, ak sú oba zaznamenané; router nikdy nepotrebuje trasu k poolu, a to je príťažlivosť tohto usporiadania.

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

Pomocou týchto čítaní zistite, čo server už má, namiesto toho, aby ste predpokladali, že NAT je na mieste. Pravidlo masquerade v Linuxe skopírované z blogu nie je konfigurácia Windows a povolenie v hostiteľskom firewalle pre VPN poslucháča nie je tá istá politika ako povolenie poslať klientsku požiadavku ďalej. Potvrďte rolu preposielania servera z jeho vlastného rozhrania správy, potom sa pozrite na preklad oddelene, pretože obe často zapínajú rôzne časti nasadenia.

Možnosť B: preniesť pool na router

V druhom usporiadaní server preposiela skutočnú zdrojovú adresu klienta a router ju prekladá. To udržiava klientsky pool viditeľný na okraji, čo pomáha, ak je router miestom, kde žije prevádzková politika, logovanie alebo inšpekcia. Znamená to tiež, že router potrebuje spätnú trasu pre 10.70.0.0/24 ukazujúcu na 172.16.40.10, plus internetovú politiku, ktorá tento prefix skutočne zahŕňa; pravidlo napísané pre LAN podsieti sa na pool ticho nerozširuje.

Zvoľte to, keď je hraničné zariadenie zamýšľaným vlastníkom politiky a môže prijať ďalší prefix vo svojich smerovacích a prekladových tabuľkách. Zvoľte preklad na strane servera, keď má pool zostať vyššie neviditeľný a router nespravuje ten istý tím. Ani jednu možnosť nenaznačuje žiadne zaškrtávacie pole na klientovi a ani jedna nie je všeobecne bezpečnejšia; umiestňujú viditeľnosť a údržbu na rôzne miesta.

Urobte DNS, IPv6 a prijatie explicitnými

Preklad adries neopravuje preklad mien. Klient môže použiť resolver dodaný s profilom VPN, privátny resolver pre konkrétne menné priestory alebo schválený verejný, a nedostupný resolver pod touto politikou bude zlyhávať ďalej, aj keď smerovanie funguje. Testujte meno a adresu oddelene, aby sa obe zlyhania nikdy nezlúčili do jedného hlásenia.

IPv6 potrebuje v návrhu vlastný odsek. Fungujúci preklad IPv4 nič nehovorí o tom, či klienti IPv6 majú trasu, platný verejný zdroj alebo politiku, ktorá ich zablokuje, keď tunel spadne. Nechať to nevyslovené znamená, že polovica klientov ticho obchádza bránu, zatiaľ čo druhá polovica funguje.

Pre prijatie sledujte jednu povolenú klientsku požiadavku a jej odpoveď cez obe hranice a zapíšte adresu, ktorú má každá hranica v tej chvíli vidieť. Práve tento záznam robí z ďalšej zmeny poolu päťminútovú úpravu namiesto hádky o to, kto vlastní chýbajúcu spätnú trasu. Uchovávajte záznam pri klientskom profile, nie v tikete, pretože profil je to, čo následný inžinier nájde ako prvý.