NAT by die VPN-bediener of by die roeteerder? Albei kan werk

Om 'n verbinding as die standaardroete op 'n skootrekenaar te merk, is die stap wat almal onthou, en dit is juis die een wat niks op die poort verander nie. Die kliënt stuur nou internetversoeke in die tonnel in; of hulle die gebou verlaat, hang af van aanstuur, 'n vertaalpunt en 'n terugpad wat die kliënt se private adres bereik. Twee reëlings kan al drie lewer, hulle plaas die werk op verskillende plekke, en albei faal op dieselfde stil manier wanneer niemand die antwoordrigting besit nie. Om tussen hulle te kies, is 'n vraag oor wie die kliëntpoel moet sien.

Die mite: 'n kliëntroete bou die uitgang

Geforseerde tonneling is 'n kliëntkant-beleid: dit besluit dat verkeer na die VPN-adapter gaan pleks van die fisiese een. Microsoft se dokumentasie oor VPN-roetes beskryf daardie splitsings- en forseergedrag, en dit is 'n stelling oor die kliënt se roetetabel, nie oor die bediener se aanstuurstreëls nie. Uit die kliënt se oogpunt is die tonnel waar die internet woon; uit die poort se oogpunt het 'n pakket aangekom van 'n adres waarvan niemand stroomop ooit gehoor het nie. Geen kant is op sigself verkeerd opgestel nie, en daarom lyk die fout vir die persoon by die skootrekenaar soos 'n stukkende bediener.

Daardie wanverhouding is die hele probleem wat die res van hierdie artikel oplos. Iets moet die kliënt se private adres terugbringbaar maak, en die keuse is waar.

Teken eers die antwoordpad

Skryf die pad neer met werklike adresse voordat jy aan 'n instelling raak, en merk die twee kandidaat-vertaalpunte daarop. Hierdie lab gebruik 'n VPN-poel van 10.70.0.0/24 met een kliënt by 10.70.0.37, 'n bediener-LAN-adres van 172.16.40.10, 'n roeteerder by 172.16.40.1 en 'n publieke uitgang van 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?)

Die bediener wat reeds die internet verken, bewys net sy eie pad. 'n Pakket wat namens 'n kliënt aangestuur word, is 'n ander besluit, geneem deur die aanstuurbeleid op dieselfde masjien, en dit is die een wat gewoonlik ontbreek. Om die drie besluitpunte op die diagram te merk, hou die gesprek op een van hulle op 'n slag.

Opsie A: vertaal op die VPN-bediener

Hier vertaal die bediener die kliënt se bron na sy eie LAN-adres voordat hy die pakket aan die roeteerder oorhandig, en die roeteerder pas sy gewone vertaling toe op pad uit. Op die antwoord herstel die roeteerder se kartering die bedieneradres, en die bediener se kartering herstel die kliëntadres. Twee toestandbeheerde vertalings in serie is normaal en werkbaar, mits albei aangeteken word; die roeteerder het nooit 'n roete na die poel nodig nie, en dit is die aantreklikheid van hierdie reëling.

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

Gebruik hierdie leesopdragte om te sien wat die bediener reeds het, eerder as om aan te neem dat daar 'n NAT is. 'n Linux-masquerade-reël wat uit 'n blog gekopieer is, is nie 'n Windows-opstelling nie, en 'n toestemming in die gasheer-vuurmuur vir die VPN-luisteraar is nie dieselfde beleid as toestemming om 'n kliënt se versoek verder aan te stuur nie. Bevestig die bediener se aanstuurrol uit sy eie bestuurskoppelvlak, en kyk dan apart na vertaling, want die twee word dikwels deur verskillende dele van 'n ontplooiing aangeskakel.

Opsie B: dra die poel na die roeteerder

In die tweede reëling stuur die bediener die kliënt se werklike bronadres aan, en die roeteerder vertaal dit. Dit hou die kliëntpoel sigbaar by die rand, wat help as die roeteerder die plek is waar verkeersbeleid, logs of inspeksie woon. Dit beteken ook die roeteerder het 'n terugroete vir 10.70.0.0/24 nodig wat na 172.16.40.10 wys, plus 'n internetbeleid wat daardie voorvoegsel werklik insluit; 'n reël wat vir die LAN-subnet geskryf is, strek nie vanself na die poel nie.

Kies dit wanneer die randtoestel die bedoelde beleideienaar is en nog 'n voorvoegsel in sy roete- en vertaaltabelle kan aanvaar. Kies die bedienerkant-vertaling wanneer die poel onsigbaar moet bly stroomop en die roeteerder nie deur dieselfde span bestuur word nie. Nie een van die opsies word deur enige merkie op die kliënt geïmpliseer nie, en nie een is in die algemeen veiliger nie; hulle plaas sigbaarheid en onderhoud op verskillende plekke.

Maak DNS, IPv6 en aanvaarding eksplisiet

Adresvertaling maak nie naamoplossing reg nie. Die kliënt kan 'n oplosser gebruik wat saam met die VPN-profiel gelewer word, 'n private oplosser vir spesifieke naamruimtes, of 'n goedgekeurde publieke een, en 'n onbereikbare oplosser onder daardie beleid sal aanhou faal nadat die roetering werk. Toets 'n naam en 'n adres afsonderlik, sodat die twee foute nooit in een verslag saamgesmelt word nie.

IPv6 het sy eie paragraaf in die ontwerp nodig. 'n Werkende IPv4-vertaling sê niks oor of IPv6-kliënte 'n roete het, 'n geldige publieke bron, of 'n beleid wat hulle blokkeer wanneer die tonnel val nie. Om dit onvermeld te laat, beteken die helfte van die kliënte omseil die poort stilweg terwyl die ander helfte werk.

Vir aanvaarding, volg een toegelate kliëntversoek en sy antwoord oor albei grense, en skryf neer watter adres elke grens op daardie oomblik moet sien. Daardie rekord is wat die volgende poelverandering 'n wysiging van vyf minute maak in plaas van 'n argument oor wie die ontbrekende terugroete besit. Hou die rekord by die kliëntprofiel eerder as in 'n kaartjie, want die profiel is wat die volgende ingenieur eerste sal vind.