NAT op de VPN-tsjinner of op de router? Beide kinne wurkje

It markearjen fan in ferbining as de standertrûte op in laptop is de stap dy't elkenien ûnthâldt, en it is krekt dy't neat feroaret op de poarte. De klant stjoert no ynternetfersiken yn 'e tunnel; oft se it gebou ferlitte hinget ôf fan trochstjoere, in oersettpunt en in weromweis dy't it privee-adres fan 'e klant berikt. Twa regelingen kinne alle trije leverje, se pleatse it wurk op ferskillende plakken, en beide mislearje op deselde stille wize as nimmen de rjochting fan it antwurd hat. Kieze tusken har is in fraach oer wa't de klantpool sjen moat.

De myte: in klantrûte bout de útkomst

Twongen tunneling is in belied oan 'e klantkant: it beslút dat ferkear nei de VPN-adapter giet yn plak fan de fysike. De dokumintaasje fan Microsoft oer VPN-routing beskriuwt dat splitsjen en twingen, en it is in útspraak oer de rûtetabel fan 'e klant, net oer de trochstjoerregels fan 'e tsjinner. Fan 'e klant ôf is de tunnel it plak dêr't it ynternet wennet; fan 'e poarte ôf kaam in pakket fan in adres dêr't nimmen boppe ea fan heard hat. Gjin kant is op himsels ferkeard konfigurearre, en dêrom liket de flater foar de persoan by de laptop as in stikken tsjinner.

Dy misferhâlding is it hiele probleem dat de rest fan dit artikel oplost. Iets moat it privee-adres fan 'e klant werombringber meitsje, en de kar is wêr.

Tekenje earst it antwurdpaad

Skriuw it paad op mei echte adressen foardat jo in ynstelling oanreitsje, en markearje de twa mooglike oersettpunten derop. Dit laboratoarium brûkt in VPN-pool fan 10.70.0.0/24 mei ien klant by 10.70.0.37, in LAN-adres fan 'e tsjinner 172.16.40.10, in router by 172.16.40.1 en in iepenbiere útkomst 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 tsjinner dy't al op it ynternet bladert, bewiist allinnich syn eigen paad. In pakket dat foar in klant trochstjoerd wurdt is in oar beslút, nommen troch it trochstjoerbelied op deselde masine, en dat is it iene dat meastentiids ûntbrekt. It markearjen fan de trije beslútpunkten op it diagram hâldt it petear oer ien fan har tagelyk.

Opsje A: oersette op de VPN-tsjinner

Hjir oerset de tsjinner de boarne fan 'e klant nei syn eigen LAN-adres foardat er it pakket oan 'e router jout, en de router past syn gewoane oersetting ta op 'e wei nei bûten. Op it antwurd herstelt de mapping fan 'e router it tsjinneradres, en de mapping fan 'e tsjinner herstelt it klantadres. Twa oersettings mei steat efterinoar binne normaal en wurkber, mits beide fêstlein wurde; de router hat nea in rûte nei de pool nedich, en dat is it aardige fan dizze regeling.

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

Brûk dizze lêzingen om te sjen wat de tsjinner al hat yn plak fan oan te nimmen dat der in NAT is. In Linux-masquerade-regel kopiearre fan in blog is gjin Windows-konfiguraasje, en in tastimming yn 'e hostfirewall foar de VPN-lústerder is net itselde belied as tastimming om it fersyk fan in klant troch te stjoeren. Befêstigje de trochstjoerrol fan 'e tsjinner fan syn eigen behearoerflak, en besjoch dan de oersetting apart, want de twa wurde faak troch ferskillende dielen fan in útrulling ynskeakele.

Opsje B: ferpleats de pool nei de router

Yn 'e twadde regeling stjoert de tsjinner it echte boarneadres fan 'e klant troch, en de router oerset it. Dat hâldt de klantpool sichtber oan 'e râne, wat helpt as de router it plak is dêr't ferkearsbelied, logging of ynspeksje wennet. It betsjut ek dat de router in weromrûte nedich hat foar 10.70.0.0/24 dy't nei 172.16.40.10 wiist, plus in ynternetbelied dat dat foarheaksel echt omfettet; in regel skreaun foar it LAN-subnet wreidet him net stil ús nei de pool.

Kies dit as it râne-apparaat de bedoelde beliedseigner is en noch in foarheaksel yn syn routing- en oersettingstabellen akseptearje kin. Kies de oersetting oan 'e tsjinnerkant as de pool boppe ûnsichtber bliuwe moat en de router net troch itselde team beheard wurdt. Gjin fan beide opsjes wurdt ymplisearre troch in fakje op 'e klant, en gjin fan beide is oer it algemien feiliger; se pleatse sichtberens en ûnderhâld op ferskillende plakken.

Meitsje DNS, IPv6 en akseptaasje eksplisyt

Adresoersetting reparearret gjin namme-oplossing. De klant kin in resolver brûke dy't mei it VPN-profil levere wurdt, in privee resolver foar bepaalde nammeromten, of in goedkarde iepenbiere, en in net-berikbere resolver ûnder dat belied sil trochgean te mislearjen neidat de routing wurket. Test in namme en in adres apart, sadat de twa flaters nea yn ien rapport gearranne.

IPv6 hat syn eigen paragraaf nedich yn it ûntwerp. In wurkjende IPv4-oersetting seit neat oer oft IPv6-klanten in rûte, in jildige iepenbiere boarne of in belied hawwe dat har blokkearret as de tunnel falt. Dat ûnsein litte betsjut dat de helte fan 'e klanten de poarte stil omgiet wylst de oare helte wurket.

Foar akseptaasje, folgje ien tastien klantfersyk en syn antwurd oer beide grinzen, en skriuw op hokker adres elke grins op dat stuit sjen moat. Dat ferslach is wat de folgjende poolferoaring in bewurking fan fiif minuten makket yn plak fan in diskusje oer wa't de ûntbrekkende weromrûte hat. Hâld it ferslach by it klantprofil yn plak fan yn in ticket, om't it profyl is wat de folgjende yngenjeur earst fine sil.