NAT a VPN-kiszolgálón vagy a routeren? Mindkettő működhet

Egy kapcsolat alapértelmezett útvonalként való megjelölése a laptopon az a lépés, amelyre mindenki emlékszik, és éppen az, amely semmit nem változtat az átjárón. Az ügyfél most az internetes kéréseket az alagútba küldi; hogy elhagyják-e az épületet, a továbbítástól, egy fordítási ponttól és egy visszafelé vezető útvonaltól függ, amely eléri az ügyfél privát címét. Két elrendezés képes mindhármat biztosítani, különböző helyekre teszik a munkát, és mindkettő ugyanúgy csendesen hibázik, amikor senki nem felel a válasz irányáért. A választás köztük arról szól, kinek kell látnia az ügyfélgyűjtőt.

A mítosz: az ügyfél útvonala építi ki a kimenetet

A kényszerített alagútkezelés ügyféloldali irányelv: eldönti, hogy a forgalom a VPN-adapterre megy a fizikai helyett. A Microsoft VPN-útvonalkezelési dokumentációja leírja ezt a szétválasztást és kényszerített viselkedést, és ez az ügyfél útvonaltáblájáról szóló kijelentés, nem a kiszolgáló továbbítási szabályairól. Az ügyfél szemszögéből az alagút az a hely, ahol az internet él; az átjáró szemszögéből egy csomag olyan címről érkezett, amelyről fentebb senki nem hallott. Egyik oldal sincs önmagában rosszul konfigurálva, és ezért tűnik a hiba a laptopnál ülőnek törött kiszolgálónak.

Ez az eltérés az a teljes probléma, amelyet a cikk többi része megold. Valaminek visszaküldhetővé kell tennie az ügyfél privát címét, és a választás az, hogy hol.

Először rajzolja fel a válasz útvonalát

Írja le az útvonalat valós címekkel, mielőtt bármely beállításhoz nyúlna, és jelölje meg rajta a két lehetséges fordítási pontot. Ez a laboratórium 10.70.0.0/24 VPN-gyűjtőt használ egy ügyféllel 10.70.0.37 címen, a kiszolgáló LAN-címével 172.16.40.10, egy routerrel 172.16.40.1 címen és egy nyilvános kimenettel 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?)

A kiszolgáló, amely már böngészi az internetet, csak a saját útvonalát bizonyítja. Az ügyfél nevében továbbított csomag más döntés, amelyet ugyanazon a gépen a továbbítási irányelv hoz, és általában éppen ez hiányzik. A három döntési pont megjelölése az ábrán egyszerre csak az egyikükről folytatott beszélgetést tartja fenn.

A lehetőség: fordítás a VPN-kiszolgálón

Itt a kiszolgáló az ügyfél forrását a saját LAN-címére fordítja, mielőtt átadja a csomagot a routernek, a router pedig kimenetkor alkalmazza a szokásos fordítását. A válaszon a router leképezése visszaállítja a kiszolgáló címét, a kiszolgáló leképezése pedig az ügyfél címét. Két állapotot tartó fordítás egymás után normális és megvalósítható, feltéve hogy mindkettőt rögzítik; a routernek soha nincs szüksége útvonalra a gyűjtő felé, és ez ezen elrendezés vonzereje.

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

Ezekkel az olvasásokkal nézze meg, mi van már a kiszolgálón, ahelyett hogy feltételezné, hogy NAT van a helyén. A blogból másolt Linux masquerade szabály nem Windows-konfiguráció, és a gazdagép tűzfalában a VPN-figyelőnek adott engedély nem ugyanaz az irányelv, mint az ügyfél kérésének továbbítására adott engedély. Erősítse meg a kiszolgáló továbbítási szerepét a saját felügyeleti felületéről, majd nézze meg a fordítást külön, mert a kettőt gyakran egy telepítés különböző részei engedélyezik.

B lehetőség: a gyűjtő átvitele a routerre

A második elrendezésben a kiszolgáló továbbítja az ügyfél valódi forráscímét, és a router fordítja le. Ez láthatóvá teszi az ügyfélgyűjtőt a peremen, ami segít, ha a router az a hely, ahol a forgalmi irányelv, a naplózás vagy az ellenőrzés él. Ez azt is jelenti, hogy a routernek visszafelé vezető útvonalra van szüksége 10.70.0.0/24 felé, amely 172.16.40.10 címre mutat, plusz egy internetes irányelvre, amely valóban tartalmazza ezt az előtagot; a LAN-alhálózatra írt szabály nem terjed ki csendesen a gyűjtőre.

Akkor válassza ezt, ha a perem eszköz a szándékolt irányelv-tulajdonos, és el tud fogadni egy másik előtagot az útvonal- és fordítótábláiban. Akkor válassza a kiszolgáló oldali fordítást, ha a gyűjtőnek fent láthatatlannak kell maradnia, és a routert nem ugyanaz a csapat kezeli. Egyik lehetőséget sem sugallja semmilyen jelölőnégyzet az ügyfélen, és egyik sem biztonságosabb általában; a láthatóságot és a karbantartást különböző helyekre teszik.

Tegye egyértelművé a DNS-t, az IPv6-ot és az elfogadást

A címfordítás nem javítja a névfeloldást. Az ügyfél használhat a VPN-profillal szállított feloldót, privát feloldót bizonyos névterekhez, vagy jóváhagyott nyilvánosat, és az ezen irányelv alatt elérhetetlen feloldó továbbra is meghibásodik, miután az útvonalkezelés működik. Tesztelje külön a nevet és a címet, hogy a két hiba soha ne olvadjon egy jelentésbe.

Az IPv6-nak saját bekezdésre van szüksége a tervezésben. Egy működő IPv4-fordítás semmit nem mond arról, hogy az IPv6-ügyfeleknek van-e útvonaluk, érvényes nyilvános forrásuk vagy olyan irányelvük, amely blokkolja őket, amikor az alagút leesik. Ennek kimondatlanul hagyása azt jelenti, hogy az ügyfelek fele csendesen megkerüli az átjárót, míg a másik fele működik.

Az elfogadáshoz kövessen egy engedélyezett ügyfélkérést és válaszát mindkét határon át, és írja le, melyik címet kellene látnia minden határnak abban a pillanatban. Ez a feljegyzés teszi a következő gyűjtőváltoztatást ötperces szerkesztéssé a hiányzó visszafelé vezető útvonal tulajdonosáról szóló vita helyett. Tartsa a feljegyzést az ügyfélprofil mellett, ne egy jegyben, mert a profil az, amit a következő mérnök először megtalál.