NAT op de VPN-server of op de router? Beide kunnen werken

Een verbinding als standaardroute op een laptop markeren is de stap die iedereen onthoudt, en juist die verandert niets op de gateway. De client stuurt de internetverzoeken nu de tunnel in; of ze het gebouw verlaten, hangt af van doorsturen, een vertaalpunt en een retourpad dat het privéadres van de client bereikt. Twee opstellingen kunnen alle drie leveren, ze leggen het werk op verschillende plaatsen, en beide falen op dezelfde stille manier wanneer niemand de antwoordrichting bezit. Kiezen tussen beide is de vraag wie de clientpool mag zien.

De mythe: een clientroute bouwt de uitgang

Geforceerd tunnelen is een beleid aan de clientkant: het bepaalt dat verkeer naar de VPN-adapter gaat in plaats van naar de fysieke. Microsofts documentatie over VPN-routering beschrijft die splitsing en dat gedrag, en het is een uitspraak over de routetabel van de client, niet over de doorstuurregels van de server. Vanuit de client bezien is de tunnel de plek waar het internet woont; vanuit de gateway bezien kwam er een pakket van een adres waarvan niemand hogerop ooit heeft gehoord. Geen van beide kanten is op zichzelf verkeerd geconfigureerd, en daarom lijkt de storing voor de persoon bij de laptop op een kapotte server.

Die mismatch is het hele probleem dat de rest van dit artikel oplost. Iets moet het privéadres van de client terugstuurbare maken, en de keuze is waar.

Teken eerst het retourpad

Schrijf het pad uit met echte adressen voordat je een instelling aanraakt, en markeer de twee mogelijke vertaalpunten erop. Dit lab gebruikt een VPN-pool van 10.70.0.0/24 met één client op 10.70.0.37, een LAN-adres van de server 172.16.40.10, een router op 172.16.40.1 en een openbare uitgang 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?)

De server die al op internet surft, bewijst alleen zijn eigen pad. Een pakket dat namens een client wordt doorgestuurd is een andere beslissing, genomen door het doorstuurbeleid op dezelfde machine, en dat is degene die meestal ontbreekt. De drie beslispunten op het diagram markeren houdt het gesprek telkens over één ervan.

Optie A: vertalen op de VPN-server

Hier vertaalt de server de bron van de client naar zijn eigen LAN-adres voordat hij het pakket aan de router geeft, en de router past op de uitweg zijn gewone vertaling toe. Op het antwoord herstelt de mapping van de router het serveradres en de mapping van de server herstelt het clientadres. Twee stateful vertalingen achter elkaar zijn normaal en werkbaar, mits beide worden vastgelegd; de router heeft nooit een route naar de pool nodig, en dat is de aantrekkingskracht van deze opstelling.

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

Gebruik deze uitlezingen om te zien wat de server al heeft in plaats van aan te nemen dat er een NAT is. Een van een blog gekopieerde Linux-masquerade-regel is geen Windows-configuratie, en een toestemming in de hostfirewall voor de VPN-listener is niet hetzelfde beleid als toestemming om het verzoek van een client door te sturen. Bevestig de doorstuurrol van de server via zijn eigen beheerinterface, en bekijk de vertaling daarna apart, omdat beide vaak door verschillende delen van een uitrol worden ingeschakeld.

Optie B: de pool naar de router brengen

In de tweede opstelling stuurt de server het echte bronadres van de client door, en de router vertaalt het. Dat houdt de clientpool zichtbaar aan de rand, wat helpt als de router de plek is waar verkeersbeleid, logging of inspectie woont. Het betekent ook dat de router een retourroute nodig heeft voor 10.70.0.0/24 die naar 172.16.40.10 wijst, plus een internetbeleid dat dat prefix echt omvat; een regel die voor het LAN-subnet is geschreven, strekt zich niet stilzwijgend uit tot de pool.

Kies dit wanneer het randapparaat de bedoelde eigenaar van het beleid is en nog een prefix in zijn routing- en vertaaltabellen kan accepteren. Kies de vertaling aan serverzijde wanneer de pool hogerop onzichtbaar moet blijven en de router niet door hetzelfde team wordt beheerd. Geen van beide opties wordt door een selectievakje op de client geïmpliceerd, en geen van beide is in het algemeen veiliger; ze plaatsen zichtbaarheid en onderhoud op verschillende plekken.

Maak DNS, IPv6 en acceptatie expliciet

Adresvertaling lost naamresolutie niet op. De client kan een resolver gebruiken die met het VPN-profiel wordt meegeleverd, een privéresolver voor bepaalde naamruimten, of een goedgekeurde openbare, en een onbereikbare resolver onder dat beleid blijft falen nadat de routering werkt. Test een naam en een adres apart, zodat de twee storingen nooit in één rapport samensmelten.

IPv6 heeft zijn eigen alinea in het ontwerp nodig. Een werkende IPv4-vertaling zegt niets over de vraag of IPv6-clients een route, een geldige openbare bron of een beleid hebben dat hen blokkeert wanneer de tunnel wegvalt. Dat onuitgesproken laten betekent dat de helft van de clients de gateway stilzwijgend omzeilt terwijl de andere helft werkt.

Volg voor de acceptatie één toegestaan clientverzoek en het antwoord ervan over beide grenzen, en noteer welk adres elke grens op dat moment zou moeten zien. Die registratie is wat de volgende poolwijziging een bewerking van vijf minuten maakt in plaats van een discussie over wie de ontbrekende retourroute bezit. Bewaar de registratie bij het clientprofiel in plaats van in een ticket, omdat het profiel is wat de volgende engineer als eerste vindt.