Zergatik ez duen Azure Point-to-Site VPN-ek zure IP publikoa aldatzen
Point-to-site tunel batek sare birtualeko ibilbideak baino ez ditu eramaten, beraz zure IP publikoa bertakoa izaten jarraitzen du tunel behartuak eta suebakiko SNAT-ek irteera Azure-ra eraman arte.
Azure VPN bezeroa Windows eramangarri batean konektatzen dut, helbide-oihartzun orri bat irekitzen dut eta nire etxeko bideratzaileak eman zuen helbide publiko bera ikusten dut. Bitartean, 10.20.0.4ko jauzi-makina erantzuten ari da eta puntu amaiera pribatu baten izena ebazten da, beraz tunela ez dago hautsita. Point-to-site atebide batek bere konfigurazio lehenetsiak dioena egiten du zehazki: aurrizki pribatuak eramaten ditu eta gainerako guztia esteka lokalean uzten du. Azure-ren jabetzako irteera-helbide bat lortzea bideratze-diseinuaren aldaketa da, ez konponketa.
Zer iragartzen du atebideak lehenespenez
Atebideak sare birtualaren helbide-espaziorako ibilbideak bultzatzen ditu, baita atebide-transitioa onartzen den pareko sareak eta site-to-site konexio edo BGP bidez ikasitako aurrizki lokalak ere. Multzo horretan ez dago 0.0.0.0/0-rik. Zure sistema eragileak bere ibilbide lehenetsia Wi-Fi edo Ethernet-en mantentzen du, beraz API publiko batera doan paketea ez da inoiz tunelean sartzen.
Bezeroak tuneleko barruan jasotzen duen helbidea point-to-site pool-etik datorren alokairu pribatu bat da. Bezeroa VNet-eko baliabideen aurrean identifikatzen du; ez da internetak ikus dezakeen helbide bat, eta ez da inoiz SaaS API batera doan irteerako eskaera baten iturri gisa agertuko. Alokairu horren inguruan eraikitako baimendutako zerrendako sarrera batek ezin du funtzionatu, saltzailearen erregistroetan agertzeko zenbat itxaron ere.
Tunel zatitua eta tunel behartua elkarren ondoan
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Bigarren ilarak bakarrik aldatzen du urruneko zerbitzu batek ikusten duen helbidea. Taula horretako gainerako guztia kostua eta eragiketa-azalera da, irteera Azure barruan ikuskatu edo itzuli behar denean onartzen duzuna. Norbaitek IP publikoa aldatzea eskatzen badizu, eskuineko zutabe osoa eskatzen ari da, ez bezeroan doikuntza txiki bat.
Edozer berreraiki aurretik aipatzeko merezi duen tarteko aukera bat dago. VNet barruko proxy edo atebide VM batek iturburu-helbide kontrolatua ematen dizu hara zuzendu daitezkeen aplikazioentzat, bezeroaren ibilbide lehenetsia mugitu gabe. Horrek nabigazio arrunta lokalean mantentzen du eta Azure-tik API dei bakarra iristea besterik behar ez duen bazkide bat asetzen jarraitzen du. Trafikoa osoari buruzkoa denean huts egiten du, proxy ezarpena alde batera uzten duen edozeinek lokalean irteten jarraitzen baitu.
Egin ezazu tunelak ibilbide lehenetsia eraman dezan
Sare birtualeko atebide batean, bezeroaren internet trafiko guztia tunelera bideratzeko modu onartua point-to-site konfiguraziora ibilbide pertsonalizatuak gehitzea da. Bi erdiek IPv4 espazio osoa estaltzen dute, eta bakoitza tokiko ibilbide lehenetsia baino zehatzagoa da, beraz bezeroak haiek nahiago ditu ezer ezabatu gabe:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Lerro hori ilustratiboa da, ez kopiatzeko eta itsasteko osoa: lehenik atebidearen objektua lortu Get-AzVirtualNetworkGateway-rekin eta ordeztu GWOBJ, eta exekutatu aurretik egiaztatu SKU-k eta inplementazio-ereduak ibilbide pertsonalizatuak onartzen dituztela. Aurrizki berak agertzen dira atarian point-to-site konfigurazio orrian, eta hori da horiek ezartzeko leku seguruena atebidea jada script bidez kudeatzen ez baduzu.
Aurrizki horiek aldatzeak bezeroaren paketea baliogabetzen du. Deskargatu berriro VPN bezeroaren paketea eta instalatu berriro, ibilbideak profilean barruan bidaiatzen baitute. Bere profil zaharra berreraikitzeko konektatzen den bezero batek ibilbide-multzo zaharrari eusten dio, eta ordu bat gal dezakezu harengana inoiz iritsi ez zen aldaketak arazten.
Babestutako WAN birtualeko hub batean baliokidea point-to-site atebidearekin lotutako hub-eko ibilbide tauleko ibilbide lehenetsia da, hub-eko Azure Firewall-ek trafikoa hartzen duelarik. Suebakiak internetera doazen konexioak bere IP helbide publikoetara itzultzen ditu, eta itzulpenean bertan sortzen da irteera-helbide berria. Suebaki batek hainbat IP publiko dituenean, horietako edozein ager daiteke iturri gisa, beraz baimendutako zerrendak denak eduki behar ditu.
Goiko bi diseinuak IPv4 dira. Bi /1 aurrizkiek ez dute ezer egiten IPv6rako, eta point-to-site IPv6 euskarria nahiko estua da parekotasuna agindu aurretik konbinazioa probatu behar izateko.
Egiaztatu ibilbidea, gero irteera
Paketea berriro instalatu eta konektatu ondoren, egiaztatu bezeroak erdiak benetan instalatu ote zituen. Windows-en, Get-NetRoute -DestinationPrefix 0.0.0.0/1 eta 128.0.0.0/1 enparako kontsulta berak tunelaren interfazea izendatu behar dute, eta route print-ek biak erakusten ditu zure jatorrizko ibilbide lehenetsiaren ondoan. Linux-en, ip route show-k bi aurrizkiak zerrendatu behar ditu; egiten ez badu, profileak ez zituen inoiz eraman.
Ondoren, egiaztatu berriro helbide publikoa bezerotik eta irakurri suebakiaren erregistroa konexio bererako. Iturria suebakiaren IP publikoa izan behar litzateke, portu itzuliarekin. Bi ibilbideak egon arren lokalean irteten jarraitzen duen bezeroak esan nahi du paketeak Azure-ra iritsi eta beste bide batetik atera zirela: erabiltzaileak definitutako ibilbide bat atebidearen azpisareko, suebaki bat bera behartuta tuneletuta dagoena tokiko sarera, edo itzulpena baino lehen fluxua baztertzen duen politika bat.
Probatu berriro helburu pribatu bat saio berean. Aldaketaren ondoren erantzuteari uzten dion jauzi-host bat ohiko seinalea da aurrizki berriek zerbait baztertu dutela: lehen iragartzen zen ibilbide lokal estuago bat edo orain zure zona pribatuetarako aurrebideratzaile gabeko ebazpenera doan izen-ebazpena.
Noiz utzi tunel zatitua bakean
Helburua API pribatu batera, puntu amaiera pribatura edo barneko administrazio orri batera iristea bada soilik, jokabide lehenetsia merkeagoa eta isilagoa da. Tunel behartuak suebaki-orduak eta datu-prozesatzeko kostuak gehitzen ditu, bide luzeagoa eta bezero-fluxu bakoitza huts egin dezakeen beste leku bat. Zuri axola zitzaizun helburu bakarrak baino askoz trafiko gehiago ere harrapatzen du.
Hartu hura, baldintza irteeraren arabera adierazten denean: bazkide batek Azure helbide finkoa ikusi behar du, segurtasunak konexioak erregistratu eta ikuskatuta nahi ditu, edo datuek kontrolatutako puntu batetik irten behar dute. Orduan ere diseinuak erabiltzaile bakoitzari irteera partekatua ematen dio, beraz erabiltzaile bakoitzeko erantzukizuna aplikazioko identitatetik etorri behar da, iturburu-helbidetik ez.
Aldaketa itxi aurretik, egiaztatu lau gauza: instalatutako bezero-paketea berria da, bi /1 ibilbideak tunelaren interfazean daude, helburu pribatu batek oraindik erantzuten du, eta urruneko zerbitzuaren erregistroak suebakiaren helbidea erakusten du.