NAT på VPN-serveren eller på ruteren? Begge kan fungere

Å merke en tilkobling som standardrute på en bærbar PC er trinnet alle husker, og det er nettopp det som ikke endrer noe på gatewayen. Klienten sender nå internettforespørslene inn i tunnelen; om de forlater bygningen, avhenger av videresending, et oversettelsespunkt og en returvei som når klientens private adresse. To ordninger kan levere alle tre, de plasserer arbeidet på forskjellige steder, og begge feiler på samme stille måte når ingen eier svarretningen. Å velge mellom dem er et spørsmål om hvem som bør se klientpuljen.

Myten: en klientrute bygger utgangen

Tvunget tunneling er en policy på klientsiden: den bestemmer at trafikken går til VPN-adapteren i stedet for den fysiske. Microsofts dokumentasjon om VPN-ruting beskriver den delingen og atferden, og det er en uttalelse om klientens rutetabell, ikke om serverens videresendingsregler. Fra klientens synspunkt er tunnelen der internett bor; fra gatewayens synspunkt ankom en pakke fra en adresse som ingen lenger oppe noen gang har hørt om. Ingen av sidene er feilkonfigurert isolert sett, og derfor ser feilen ut som en ødelagt server for personen ved den bærbare PC-en.

Det avviket er hele problemet som resten av denne artikkelen løser. Noe må gjøre klientens private adresse returnerbar, og valget er hvor.

Tegn svarveien først

Skriv ned ruten med ekte adresser før du berører en innstilling, og merk av de to mulige oversettelsespunktene på den. Dette laboratoriet bruker en VPN-pulje på 10.70.0.0/24 med én klient på 10.70.0.37, en server-LAN-adresse på 172.16.40.10, en ruter på 172.16.40.1 og en offentlig utgang 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?)

Serveren som allerede surfer på internett beviser bare sin egen vei. En pakke som videresendes på vegne av en klient, er en annen beslutning, tatt av videresendingspolicyen på samme maskin, og det er den som vanligvis mangler. Å merke de tre beslutningspunktene på diagrammet holder samtalen om ett av dem om gangen.

Alternativ A: oversett på VPN-serveren

Her oversetter serveren klientens kilde til sin egen LAN-adresse før den gir pakken videre til ruteren, og ruteren bruker sin vanlige oversettelse på vei ut. På svaret gjenoppretter ruterens mapping serveradressen, og serverens mapping gjenoppretter klientadressen. To tilstandsfulle oversettelser i serie er normale og gjennomførbare, forutsatt at begge registreres; ruteren trenger aldri en rute til puljen, og det er det tiltalende ved denne ordningen.

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

Bruk disse lesingene for å se hva serveren allerede har i stedet for å anta at det finnes en NAT. En Linux-masquerade-regel kopiert fra en blogg er ikke en Windows-konfigurasjon, og en tillatelse i vertens brannmur for VPN-lytteren er ikke samme policy som tillatelse til å videresende en klients forespørsel videre. Bekreft serverens videresendingsrolle fra dens egen administrasjonsflate, og se deretter på oversettelsen separat, fordi de to ofte aktiveres av forskjellige deler av en utrulling.

Alternativ B: flytt puljen til ruteren

I den andre ordningen videresender serveren klientens virkelige kildeadresse, og ruteren oversetter den. Det holder klientpuljen synlig ved kanten, noe som hjelper hvis ruteren er der trafikkpolicy, logging eller inspeksjon bor. Det betyr også at ruteren trenger en returrute for 10.70.0.0/24 som peker på 172.16.40.10, pluss en internettpolicy som faktisk inkluderer det prefikset; en regel skrevet for LAN-subnettet strekker seg ikke stille til puljen.

Velg dette når kantutstyret er den tiltenkte policyeieren og kan godta et annet prefiks i ruting- og oversettelsestabellene sine. Velg oversettelsen på serversiden når puljen skal forbli usynlig lenger oppe og ruteren ikke administreres av samme team. Ingen av alternativene antydes av noen avkrysningsboks på klienten, og ingen av dem er tryggere generelt; de plasserer synlighet og vedlikehold på forskjellige steder.

Gjør DNS, IPv6 og aksept eksplisitt

Adresseoversettelse løser ikke navneoppslag. Klienten kan bruke en resolver som leveres med VPN-profilen, en privat resolver for bestemte navnerom eller en godkjent offentlig, og en utilgjengelig resolver under den policyen vil fortsette å feile etter at rutingen virker. Test et navn og en adresse hver for seg, slik at de to feilene aldri smelter sammen i én rapport.

IPv6 trenger sitt eget avsnitt i designet. En fungerende IPv4-oversettelse sier ingenting om hvorvidt IPv6-klienter har en rute, en gyldig offentlig kilde eller en policy som blokkerer dem når tunnelen faller. Å la det være usagt betyr at halvparten av klientene stille omgår gatewayen mens den andre halvparten virker.

For aksept, følg én tillatt klientforespørsel og svaret dens over begge grensene, og skriv ned hvilken adresse hver grense bør se i det øyeblikket. Den registreringen er det som gjør den neste puljeendringen til en fem minutters redigering i stedet for en diskusjon om hvem som eier den manglende returruten. Oppbevar registreringen sammen med klientprofilen i stedet for i en billett, siden profilen er det den neste ingeniøren finner først.