NAT på VPN-serveren eller på routeren? Begge dele kan fungere

At markere en forbindelse som standardrute på en bærbar computer er det trin, alle husker, og det er netop det, der ikke ændrer noget på gatewayen. Klienten sender nu internetanmodninger ind i tunnelen; om de forlader bygningen, afhænger af videresendelse, et oversættelsespunkt og en returvej, der når klientens private adresse. To ordninger kan levere alle tre, de placerer arbejdet forskellige steder, og begge fejler på samme stille måde, når ingen ejer svarretningen. At vælge mellem dem er et spørgsmål om, hvem der bør se klientpuljen.

Myten: en klientrute bygger udgangen

Tvungen tunneling er en politik på klientsiden: den bestemmer, at trafikken går til VPN-adapteren i stedet for den fysiske. Microsofts dokumentation om VPN-routing beskriver den opdeling og adfærd, og det er en udtalelse om klientens rutetabel, ikke om serverens videresendelsesregler. Fra klientens synspunkt er tunnelen der, hvor internettet bor; fra gatewayens synspunkt ankom en pakke fra en adresse, som ingen længere oppe nogensinde har hørt om. Ingen af siderne er fejlkonfigureret isoleret set, og derfor ligner fejlen en ødelagt server for personen ved den bærbare computer.

Den uoverensstemmelse er hele det problem, som resten af denne artikel løser. Noget skal gøre klientens private adresse returnerbar, og valget er hvor.

Tegn svarvejen først

Skriv ruten ned med rigtige adresser, før du rører ved en indstilling, og markér de to mulige oversættelsespunkter på den. Dette laboratorium bruger 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 router på 172.16.40.1 og en offentlig udgang 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, der allerede browser internettet, beviser kun sin egen vej. En pakke, der videresendes på vegne af en klient, er en anden beslutning, truffet af videresendelsespolitikken på samme maskine, og det er den, der normalt mangler. At markere de tre beslutningspunkter på diagrammet holder samtalen om ét af dem ad gangen.

Mulighed A: oversæt på VPN-serveren

Her oversætter serveren klientens kilde til sin egen LAN-adresse, før den giver pakken videre til routeren, og routeren anvender sin sædvanlige oversættelse på vej ud. På svaret gendanner routerens mapping serveradressen, og serverens mapping gendanner klientadressen. To tilstandsfulde oversættelser i serie er normale og anvendelige, forudsat at begge registreres; routeren har aldrig brug for en rute til puljen, og det er det tiltalende ved denne ordning.

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

Brug disse læsninger til at se, hvad serveren allerede har, i stedet for at antage, at der er en NAT. En Linux-masquerade-regel kopieret fra en blog er ikke en Windows-konfiguration, og en tilladelse i værtens firewall for VPN-lytteren er ikke samme politik som tilladelse til at videresende en klients anmodning. Bekræft serverens videresendelsesrolle fra dens egen administrationsflade, og se derefter på oversættelse separat, fordi de to ofte aktiveres af forskellige dele af en udrulning.

Mulighed B: flyt puljen til routeren

I den anden ordning videresender serveren klientens rigtige kildeadresse, og routeren oversætter den. Det holder klientpuljen synlig ved kanten, hvilket hjælper, hvis routeren er der, hvor trafikpolitik, logning eller inspektion bor. Det betyder også, at routeren har brug for en returrute til 10.70.0.0/24, der peger på 172.16.40.10, plus en internetpolitik, der faktisk omfatter det præfiks; en regel skrevet til LAN-undernettet strækker sig ikke stille til puljen.

Vælg dette, når kantudstyret er den tilsigtede politikejer og kan acceptere endnu et præfiks i sine routing- og oversættelsestabeller. Vælg oversættelsen på serversiden, når puljen skal forblive usynlig længere oppe, og routeren ikke administreres af det samme team. Ingen af mulighederne antydes af nogen afkrydsningsboks på klienten, og ingen af dem er mere sikker generelt; de placerer synlighed og vedligeholdelse forskellige steder.

Gør DNS, IPv6 og accept eksplicit

Adresseoversættelse løser ikke navneopløsning. Klienten kan bruge en resolver, der leveres med VPN-profilen, en privat resolver til bestemte navnerum eller en godkendt offentlig, og en utilgængelig resolver under den politik vil fortsætte med at fejle, efter at routing virker. Test et navn og en adresse hver for sig, så de to fejl aldrig smelter sammen i én rapport.

IPv6 har brug for sit eget afsnit i designet. En fungerende IPv4-oversættelse siger intet om, hvorvidt IPv6-klienter har en rute, en gyldig offentlig kilde eller en politik, der blokerer dem, når tunnelen falder. At lade det være usagt betyder, at halvdelen af klienterne stille omgår gatewayen, mens den anden halvdel virker.

Til accept følg en tilladt klientanmodning og dens svar over begge grænser, og skriv ned, hvilken adresse hver grænse bør se i det øjeblik. Den registrering er det, der gør den næste puljeændring til en fem minutters redigering i stedet for en diskussion om, hvem der ejer den manglende returrute. Opbevar registreringen sammen med klientprofilen i stedet for i en billet, da profilen er det, den næste ingeniør finder først.