Miks Azure Point-to-Site VPN teie avalikku IP-d ei muuda
Point-to-site-tunnel edastab ainult virtuaalvõrgu marsruute, seega teie avalik IP jääb lokaalseks, kuni sunnitud tunnelimine ja tulemüüri SNAT viivad väljundi Azure'i.
Ühendan Azure VPN-kliendi Windowsi sülearvutis, avan aadressi kajastava lehe ja näen sama avalikku aadressi, mille mu kodune ruuter väljastas. Vahepeal vastab hüppekast aadressil 10.20.0.4 ja privaatse lõpp-punkti nimi laheneb, seega tunnel ei ole katki. Point-to-site-lüüs teeb täpselt seda, mida tema vaikekonfiguratsioon ütleb: kannab privaatsed prefiksid ja jätab kõik muu lokaalsele lingile. Azure'ile kuuluva väljundväljundi saamine on marsruutimise disaini muutus, mitte parandus.
Mida lüüs vaikimisi teadustab
Lüüs lükkab marsruudid virtuaalvõrgu aadressiruumi jaoks, lisaks võrdõigusvõrgud, kus lüüsitransiit on lubatud, ning kohalikud prefiksid, mis on õpitud saidi-lõiksaid ühenduse või BGP kaudu. Selles komplektis ei ole ühtegi 0.0.0.0/0. Teie operatsioonisüsteem hoiab oma vaikemarsruuti Wi-Fi või Etherneti peal, seega avaliku API poole liikuv pakett ei sisene kunagi tunnelisse.
Aadress, mille klient tunnelis saab, on privaatne liising point-to-site-basseinist. See identifitseerib kliendi VNeti ressursside jaoks; see ei ole aadress, mida internet näeb, ja see ei ilmu kunagi SaaS-API-le suunatud väljuva päringu allikana. Selle liisingu ümber ehitatud lubatud loendi kirje ei saa töötada, ükskõik kui kaua te ootate, et see tarnija logides ilmuks.
Jagatud tunnel ja sunnitud tunnelimine kõrvuti
| 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 |
Ainult teine rida muudab aadressi, mida kaugteenus näeb. Kõik muu selles tabelis on kulu ja halduspind, millega te nõustute, kui väljundit tuleb Azure'i sees kontrollida või tõlkida. Kui keegi palub teil avalikku IP-d muuta, palub ta tervet parempoolset veergu, mitte väikest kohandust kliendis.
Enne kui midagi ümber ehitate, tasub nimetada vahepealset valikut. Puhverserveri või lüüsi VM VNeti sees annab teile kontrollitud lähteaadressi rakendustele, mida saab sinna suunata, ilma kliendi vaikemarsruuti liigutamata. See hoiab tavapärase sirvimise lokaalsena ja rahuldab ikkagi partnerit, kes vajab ainult ühte API-kutset Azure'ist. See ebaõnnestub, kui nõue puudutab tõesti kogu liiklust, sest kõik, mis puhverserveri seadet eirab, väljub ikka lokaalselt.
Pange tunnel kandma vaikemarsruuti
Virtuaalvõrgu lüüsil on toetatud viis suunata kogu kliendi internetiliiklus tunnelisse kohandatud marsruutide lisamine point-to-site-konfiguratsiooni. Kaks poolt katavad kogu IPv4 ruumi ja kumbki on täpsem kui kohalik vaikemarsruut, seega eelistab klient neid midagi kustutamata:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1See rida on näitlik, mitte täielik kopeerimiseks: hankige esmalt lüüsi objekt käsuga Get-AzVirtualNetworkGateway ja asendage sellega GWOBJ, ning kinnitage enne käivitamist, et SKU ja juurutusmudel aktsepteerivad kohandatud marsruute. Samad prefiksid ilmuvad portaalis point-to-site-konfiguratsiooni lehel, mis on turvalisem koht nende seadmiseks, kui te lüüsi juba skriptiga ei halda.
Nende prefiksite muutmine muudab kliendipaketi kehtetuks. Laadige VPN-kliendi pakett uuesti alla ja installige uuesti, sest marsruudid liiguvad profiili sees. Klient, mis ühendub uuesti oma vana profiiliga, hoiab vana marsruudikomplekti ja te võite kaotada tunni, siludes muudatust, mis temani kunagi ei jõudnud.
Kaitstud virtuaalse WAN-i jaoturis on ekvivalent vaikemarsruut jaoturi marsruuditabelis, mis on seotud point-to-site-lüüsiga, kusjuures liikluse võtab jaoturi Azure Firewall. Tulemüür tõlgib internetti suunatud ühendused omaenda avalikeks IP-aadressideks ja just sellest tõlkest pärineb uus väljundväljundi aadress. Kui tulemüüril on mitu avalikku IP-d, võib ükskõik milline neist allikana ilmuda, seega peab lubatud loend sisaldama neid kõiki.
Mõlemad ülalolevad lahendused on IPv4. Kaks prefiksit /1 ei tee IPv6 jaoks midagi ja point-to-site'i IPv6-tugi on nii kitsas, et kombinatsiooni tuleks testida enne pariteedi lubamist.
Kontrollige marsruuti, seejärel väljundit
Pärast paketi uuesti installimist ja ühenduse taastamist kinnitage, et klient paigaldas pooled tõesti. Windowsis peaksid Get-NetRoute -DestinationPrefix 0.0.0.0/1 ja sama päring 128.0.0.0/1 nimetama tunneliliidese ning route print näitab mõlemat teie algse vaikemarsruudi kõrval. Linuxis peab ip route show loetlema kaks prefiksit; kui ei, ei kandnud profiil neid kunagi.
Seejärel kontrollige avalikku aadressi kliendist uuesti ja lugege sama ühenduse kohta tulemüüri logi. Allikas peaks olema tulemüüri avalik IP tõlgitud pordiga. Klient, mis väljub ikka lokaalselt, kuigi mõlemad marsruudid on olemas, tähendab, et paketid jõudsid Azure'i ja lahkusid teist teed: kasutaja määratud marsruut lüüsi alamvõrgus, tulemüür, mis ise on sunnitud tunneliga kohalikku võrku, või poliitika, mis viskab voolu enne tõlget kõrvale.
Testige samas seansis uuesti ühte privaatset sihtkohta. Hüppemajutaja, mis lõpetab pärast muudatust vastamise, on tavaline märk, et uued prefiksid tõrjusid midagi välja: kas varem teatatud kitsama kohaliku marsruudi või nimehalduse, mis läheb nüüd resolverisse, millel pole teie privaatsete tsoonide jaoks edastajat.
Millal jätta jagatud tunnel rahule
Kui eesmärk on ainult jõuda privaatse API, privaatse lõpp-punkti või sisemise administraatorilehe juurde, on vaikekäitumine odavam ja vaiksem. Sunnitud tunnelimine lisab tulemüüritunde ja andmetöötluskulusid, pikema tee ja veel ühe koha, kus iga kliendivool võib ebaõnnestuda. See püüab ka palju rohkem liiklust kui ainus sihtkoht, mille pärast muretsesite.
Haarake selle järele, kui nõue on sõnastatud väljundi kaudu: partner peab nägema fikseeritud Azure'i aadressi, turvalisus tahab, et ühendused logitaks ja kontrollitaks, või andmed peavad lahkuma ühe kontrollitud punkti kaudu. Isegi siis annab lahendus igale kasutajale ühise väljundi, seega peab kasutajapõhine vastutus tulema rakenduses olevast identiteedist, mitte lähteaadressist.
Enne muudatuse sulgemist kinnitage nelja asja: paigaldatud kliendipakett on uus, kaks marsruuti /1 asuvad tunneliliidesel, privaatne sihtkoht vastab ikka ja kaugteenuse logi näitab tulemüüri aadressi.