NAT VPN zerbitzarian edo routerrean? Biak funtziona dezakete

Ordenagailu eramangarrian konexioa ibilbide lehenetsi gisa markatzea denek gogoratzen duten urratsa da, eta atebidean ezer aldatzen ez duena da hain zuzen. Bezeroak Interneteko eskaerak tunelera bidaltzen ditu orain; eraikina uzten duten ala ez birbidalketaren, itzulpen-puntu baten eta bezeroaren helbide pribatura iristen den itzulera-bide baten mende dago. Bi antolamenduk hirurak eman ditzakete, lana toki desberdinetan jartzen dute, eta biek modu isil berean huts egiten dute inork erantzunaren norabidea bere gain hartzen ez duenean. Haien artean aukeratzeak bezeroen igerilekua nork ikusi behar duen galdera dakar.

Mitoa: bezeroaren ibilbideak irteera eraikitzen du

Tunelatze behartua bezeroaren aldea da politika: trafikoa VPN egokitzaileetara doala erabakitzen du, fisikoetara beharrean. Microsoften VPN bideratze dokumentazioak banaketa eta behartze portaera hori deskribatzen ditu, eta bezeroaren ibilbide-taulari buruzko adierazpena da, ez zerbitzariaren birbidalketa-arauenei buruzkoa. Bezeroaren ikuspegitik tunela da Internet bizi den tokia; atebidearen ikuspegitik pakete bat iritsi da inork goragoko ez duen helbide batetik. Inongo alderik ez dago gaizki konfiguratuta bere horretan, eta horregatik hutsegiteak zerbitzari hondatua dirudi eramangarriaren ondoan dagoenarentzat.

Desdoitze hori da artikuluaren gainerakoak konpontzen duen arazo osoa. Zerbaiti esker bezeroaren helbide pribatua itzulgai bihurtu behar da, eta aukera non dagoen da.

Marraztu lehenengo itzulera-bidea

Idatzi bidea helbide errealekin edozein ezarpen ukitu aurretik, eta markatu bertan bi itzulpen-puntu hautagaiak. Laborategi honek 10.70.0.0/24 VPN igerilekua erabiltzen du, bezero bat 10.70.0.37 helbidean, zerbitzariaren LAN helbidea 172.16.40.10, router bat 172.16.40.1 helbidean eta irteera publiko bat 203.0.113.40 helbidean.

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?)

Dagoeneko Interneten arakatzen ari den zerbitzariak bere bidea baino ez du frogatzen. Bezero baten izenean birbidalitako paketea beste erabaki bat da, makina berean birbidalketa-politikak hartua, eta hori da normalean falta dena. Diagraman hiru erabaki-puntu markatzeak haietako bati buruzkoa bakarrik mantentzen du elkarrizketa.

A aukera: itzuli VPN zerbitzarian

Hemen zerbitzariak bezeroaren iturburua bere LAN helbidera itzultzen du paketea routerrari eman aurretik, eta routerrak bere ohiko itzulpena aplikatzen du irteeran. Erantzunean, routerraren mapatzeak zerbitzariaren helbidea berrezartzen du eta zerbitzariaren mapatzeak bezeroaren helbidea. Seriean dauden bi itzulpen egoeradun normalak eta bideragarriak dira, baldin eta biak erregistratzen badira; routerrak ez du inoiz igerilekurako ibilbiderik behar, eta hori da antolamendu honen erakargarritasuna.

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

Erabili irakurketa hauek zerbitzariak jadanik daukan ikusteko, NAT badagoela suposatu beharrean. Blog batetik kopiatutako Linux masquerade araua ez da Windows konfigurazio bat, eta ostalariaren suebakian VPN entzulearentzako baimena ez da bezeroaren eskaera aurrera birbidaltzeko baimena bera. Egiaztatu zerbitzariaren birbidalketa-rola bere kudeaketa-azaletik, eta gero begiratu itzulpena bereizita, biak hedapen baten zati desberdinek gaitu ohi baitituzte.

B aukera: eraman igerilekua routerrera

Bigarren antolamenduan zerbitzariak bezeroaren benetako iturburu-helbidea birbidaltzen du, eta routerrak itzultzen du. Horrek bezeroen igerilekua ertzean ikusgai mantentzen du, eta horrek laguntzen du routerra trafiko-politikaren, erregistroaren edo ikuskapenaren tokia bada. Gainera, routerrak 10.70.0.0/24 rako itzulera-ibilbidea behar duela esan nahi du, 172.16.40.10 helbidera seinalatuz, eta gainera aurrizki hori benetan barne hartzen duen Internet politikak; LAN azpisarearentzat idatzitako arau bat ez da isilki igerilekura hedatzen.

Aukeratu hau ertzeko gailua politikaren jabe izateko asmoa duenean eta beste aurrizki bat onar dezakeenean bere bideratze- eta itzulpen-tauletan. Aukeratu zerbitzari aldeko itzulpena igerilekuak goian ikusezin jarraitu behar duenean eta routerra talde berak administratzen ez duenean. Inongo aukerarik ez da bezeroaren kontrol-laukiren batetik ondorioztatzen, eta bat ere ez da orokorrean seguruagoa; ikusgaitasuna eta mantentze-lana toki desberdinetan jartzen dituzte.

Egin DNS, IPv6 eta onarpena esplizitu

Helbideen itzulpenak ez du izenen ebazpena konpontzen. Bezeroak VPN profilearekin emandako ebazpen-gailu bat erabil dezake, izen-espazio zehatzetarako ebazpen-gailu pribatu bat edo onartutako publiko bat, eta politika horren pean iristezina den ebazpen-gailuak huts egiten jarraituko du bideratzea funtzionatzen hasi ondoren. Probatu izen bat eta helbide bat bereizita, bi hutsegiteak inoiz txosten bakarrean bat ez daitezen.

IPv6k bere paragrafoa behar du diseinuan. Funtzionatzen duen IPv4 itzulpenak ez du ezer esaten IPv6 bezeroek ibilbiderik, iturri publiko baliodunik edo tunela erortzen denean blokeatzen dituen politikarik duten ala ez. Hori esan gabe uzteak bezeroen erdiak atebidea isilki saihesten duela esan nahi du, beste erdiak funtzionatzen duen bitartean.

Onarpenerako, jarraitu baimendutako bezero-eskaera bat eta haren erantzuna bi mugaz zehar, eta idatzi muga bakoitzak une horretan ikusi beharko lukeen helbidea. Erregistro horrek egiten du hurrengo igerileku-aldaketa bost minutuko aldaketa, falta den itzulera-ibilbidea nork duen eztabaidatu beharrean. Gorde erregistroa bezeroaren profilean, tiketean beharrean, hurrengo ingeniariak aurkituko duena profila baita.