NAT på VPN-servern eller i routern? Båda kan fungera

Att markera en anslutning som standardrutt på en bärbar dator är steget alla minns, och det är just det som inte ändrar något på gatewayen. Klienten skickar nu internetförfrågningarna in i tunneln; om de lämnar byggnaden beror på vidarebefordran, en översättningspunkt och en returväg som når klientens privata adress. Två uppställningar kan leverera alla tre, de lägger arbetet på olika ställen, och båda misslyckas på samma tysta sätt när ingen äger svarriktningen. Att välja mellan dem är en fråga om vem som bör se klientpoolen.

Myten: en klientrutt bygger utgången

Tvingad tunnling är en policy på klientsidan: den avgör att trafiken går till VPN-adaptern i stället för den fysiska. Microsofts dokumentation om VPN-routing beskriver den delningen och det tvingade beteendet, och det är ett påstående om klientens rutttabell, inte om serverns vidarebefordringsregler. Från klientens synpunkt är tunneln där internet bor; från gatewayens synpunkt anlände ett paket från en adress som ingen längre upp någonsin hört talas om. Ingen av sidorna är felkonfigurerad isolerat, och därför ser felet ut som en trasig server för personen vid den bärbara datorn.

Den diskrepansen är hela problemet som resten av artikeln löser. Något måste göra klientens privata adress returbar, och valet är var.

Rita returvägen först

Skriv ned vägen med riktiga adresser innan du rör en inställning, och markera de två möjliga översättningspunkterna på den. Det här labbet använder en VPN-pool på 10.70.0.0/24 med en klient på 10.70.0.37, en server-LAN-adress på 172.16.40.10, en router på 172.16.40.1 och en offentlig utgång på 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?)

Servern som redan surfar på internet bevisar bara sin egen väg. Ett paket som vidarebefordras för en klients räkning är ett annat beslut, fattat av vidarebefordringspolicyn på samma maskin, och det är den som vanligtvis saknas. Att markera de tre beslutspunkterna i diagrammet håller samtalet om en av dem i taget.

Alternativ A: översätt på VPN-servern

Här översätter servern klientens källa till sin egen LAN-adress innan den lämnar paketet till routern, och routern tillämpar sin vanliga översättning på väg ut. På svaret återställer routerns mappning serveradressen, och serverns mappning återställer klientadressen. Två tillståndsbevarande översättningar i serie är normala och genomförbara, förutsatt att båda registreras; routern behöver aldrig en rutt till poolen, och det är det som är tjusningen med den här uppställningen.

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

Använd dessa läsningar för att se vad servern redan har i stället för att anta att det finns en NAT. En Linux-masquerade-regel kopierad från en blogg är inte en Windows-konfiguration, och ett tillstånd i värdens brandvägg för VPN-lyssnaren är inte samma policy som tillstånd att vidarebefordra en klients begäran. Bekräfta serverns vidarebefordringsroll från dess egen administrationsyta, och titta sedan på översättningen separat, eftersom de två ofta aktiveras av olika delar av en driftsättning.

Alternativ B: flytta poolen till routern

I den andra uppställningen vidarebefordrar servern klientens verkliga källadress, och routern översätter den. Det håller klientpoolen synlig vid kanten, vilket hjälper om routern är där trafikpolicy, loggning eller inspektion bor. Det innebär också att routern behöver en returrutt för 10.70.0.0/24 som pekar på 172.16.40.10, plus en internetpolicy som faktiskt omfattar det prefixet; en regel skriven för LAN-subnätet sträcker sig inte tyst till poolen.

Välj detta när kantenheten är den avsedda policyägaren och kan acceptera ytterligare ett prefix i sina routing- och översättningstabeller. Välj översättningen på serversidan när poolen ska förbli osynlig längre upp och routern inte administreras av samma team. Ingen av alternativen antyds av någon kryssruta på klienten, och ingen av dem är säkrare generellt; de placerar synlighet och underhåll på olika ställen.

Gör DNS, IPv6 och acceptans uttryckliga

Adressöversättning löser inte namnmatchning. Klienten kan använda en resolver som levereras med VPN-profilen, en privat resolver för vissa namnrymder eller en godkänd offentlig, och en oåtkomlig resolver under den policyn kommer att fortsätta misslyckas efter att routingen fungerar. Testa ett namn och en adress var för sig, så att de två felen aldrig smälter samman i en rapport.

IPv6 behöver sitt eget stycke i designen. En fungerande IPv4-översättning säger ingenting om huruvida IPv6-klienter har en rutt, en giltig offentlig källa eller en policy som blockerar dem när tunneln fallerar. Att lämna det osagt innebär att hälften av klienterna tyst kringgår gatewayen medan den andra hälften fungerar.

För acceptans, följ en tillåten klientbegäran och dess svar över båda gränserna, och skriv ned vilken adress varje gräns bör se i det ögonblicket. Den registreringen är det som gör nästa pooländring till en fem minuters redigering i stället för en diskussion om vem som äger den saknade returrutten. Förvara registreringen med klientprofilen i stället för i ett ärende, eftersom profilen är det som nästa ingenjör hittar först.