Wêrom Azure Point-to-Site VPN jo iepenbiere IP net feroaret
In point-to-site-tunnel ferfiert allinnich rûtes fan it firtuele netwurk, dus jo iepenbiere IP bliuwt lokaal oant twongen tunneling en firewall-SNAT de útgong nei Azure ferpleatse.
Ik ferbyn Azure VPN-klant op in Windows-laptop, iepenje in adres-echto-side en sjoch itselde iepenbiere adres dat myn thúsrûter joech. Underwilens antwurdet de springbox op 10.20.0.4 en in privee-einpuntnamme wurdt oplost, dus de tunnel is net stikken. In point-to-site-gateway docht krekt wat syn standertkonfiguraasje seit: hy draacht de privee prefiksen en lit al it oare op 'e lokale keppeling. It krijen fan in Azure-eigene útgongsadres is in feroaring fan rûte-ûntwerp, gjin reparaasje.
Wat de gateway standert oankundiget
De gateway triuwt rûtes foar de adresromte fan it firtuele netwurk, plus peare netwurken dêr't gateway-transit tastien is en lokale prefiksen leard oer in site-to-site-ferbining of BGP. Der is gjin 0.0.0.0/0 yn dy set. Jo bestjoeringssysteem hâldt syn standertrûte op Wi-Fi of Ethernet, dus in pakket nei in iepenbiere API komt nea yn 'e tunnel.
It adres dat in klant yn 'e tunnel krijt is in privee lease út 'e point-to-site-pool. It identifisearret de klant foar boarnen yn it VNet; it is gjin adres dat it ynternet sjen kin, en it sil nea as de boarne fan in útgeande oanfraach nei in SaaS-API ferskine. In allowlist-ynskriuwing boud om dy lease kin net wurkje, hoe lang oft jo ek wachtsje oant it yn 'e leveransierslogboeken ferskynt.
Split tunnel en twongen tunneling njonkeninoar
| 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 |
Allinnich de twadde rige feroaret it adres dat in ôfstânstsjinst sjocht. Al it oare yn dy tabel is kosten en operaasje-oerflak dat jo akseptearje as de útgong binnen Azure ynspektearre of oerset wurde moat. As immen jo freget om de iepenbiere IP feroarje te litten, freget er om 'e hiele rjochterkolom, net om in lyts oanpassing oan 'e klant.
Der is in tuskenopsje dy't it neamen wurdich is foardat jo wat werbouwe. In proxy- of gateway-VM yn it VNet jout jo in kontrolearre boarneadres foar de applikaasjes dy't derop rjochte wurde kinne, sûnder de standertrûte fan 'e klant te ferpleatsen. Dat hâldt normaal browsen lokaal en foldocht noch oan in partner dy't mar ien API-oprop út Azure nedich hat. It mislearret as de eask echt oer alle ferkear giet, want alles dat de proxy-ynstelling negearret giet dochs lokaal fuort.
Lit de tunnel de standertrûte drage
Op in firtuele-netwarkgateway is de stipe manier om al it ynternetferkear fan 'e klant de tunnel yn te stjoeren it tafoegjen fan oanpast rûtes oan 'e point-to-site-konfiguraasje. Twa helten dekke de hiele IPv4-romte, en elk is spesifiker as de lokale standertrûte, dus de klant ferkiest se sûnder wat te wiskjen:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Dy rigel is yllustratyf en net klear om te kopiearjen: helje earst it gateway-objekt mei Get-AzVirtualNetworkGateway en ferfange it foar GWOBJ, en befêstigje foar it útfieren dat de SKU en it ymplemintaasjemodel oanpaste rûtes akseptearje. Deselde prefiksen ferskine yn it portaal op 'e point-to-site-konfiguraasjeside, dat is it feiliger plak om se te setten as jo de gateway noch net skripte.
It feroarjen fan dy prefiksen makket it klantpakket ûnjildich. Download it VPN-klantpakket opnij en ynstallearje it opnij, want de rûtes reizgje binnen it profyl. In klant dy't him opnij ferbynt mei syn âlde profyl hâldt de âlde rûteset, en jo kinne in oere ferlieze mei it debuggen fan in feroaring dy't him nea berikte.
Yn in befeilige firtuele WAN-hub is it ekwivalint in standertrûte yn 'e hub-rûtetabel ferbûn mei de point-to-site-gateway, wêrby't Azure Firewall yn 'e hub it ferkear nimt. De firewall oerset ynternet-rjochte ferbiningen nei syn eigen iepenbiere IP-adressen, en út dy oersetting komt it nije útgongsadres. As in firewall ferskate iepenbiere IP's hat, kin elk fan har as de boarne ferskine, dus in allowlist moat se allegear befetsje.
Beide ûntwerpen hjirboppe binne IPv4. De twa /1-prefiksen dogge neat foar IPv6, en point-to-site-IPv6-stipe is sa smel dat jo de kombinaasje testen moatte foardat jo pariteit ûnthjitte.
Kontrolearje de rûte, dan de útgong
Nei it opnij ynstallearjen fan it pakket en it opnij ferbinen, befêstigje dat de klant de helten echt ynstallearre hat. Op Windows moatte Get-NetRoute -DestinationPrefix 0.0.0.0/1 en deselde fraach foar 128.0.0.0/1 de tunnelinterface neame, en route print toant beide njonken jo oarspronklike standertrûte. Op Linux moat ip route show de twa prefiksen listje; docht it dat net, dan hat it profyl se nea droegen.
Kontrolearje dan it iepenbiere adres fan 'e klant ôf opnij en lês it firewall-log foar deselde ferbining. De boarne moat it iepenbiere IP fan 'e firewall wêze mei in oersetten poarte. In klant dy't noch lokaal fuortgiet wylst beide rûtes bestean, betsjut dat pakketten Azure berikt hawwe en fia in oare wei fuortgien binne: in brûker-definiearre rûte op it gateway-subnet, in firewall dy't sels twongen tunnelle is nei it lokale netwurk, of in belied dat de stream foar de oersetting falle lit.
Test opnij ien privee bestimming yn deselde sesje. In springhost dy't nei de feroaring ophâldt mei antwurdzjen is it gewoane teken dat de nije prefiksen wat ferkrongen hawwe, itsij in nauwere lokale rûte dy't earder oankundige waard, itsij namme-oplossing dy't no nei in resolver giet sûnder trochstjoerder foar jo privee sônes.
Wannear jo de split tunnel gewurde litte
As it doel allinnich is om in privee API, in privee einpunt of in ynterne admin-side te berikken, is it standertgedrach goedkeaper en stiller. Twongen tunneling foeget firewall-oeren en datas ferwurkingskosten ta, in langer paad, en noch in plak dêr't elke klantstream mislearje kin. It fangt ek folle mear ferkear as de iene bestimming dêr't jo jo soargen oer makken.
Gryp dêrnei as de eask yn termen fan útgong steld wurdt: in partner moat in fêst Azure-adres sjen, feiligens wol de ferbiningen logge en ynspektearre hawwe, of data moat fia ien kontrolearre punt fuortgean. Sels dan jout it ûntwerp elke brûker in dielde útgong, dus ferantwurdlikens per brûker moat fan identiteit yn 'e applikaasje komme, net fan it boarneadres.
Foardat jo de feroaring slute, befêstigje fjouwer dingen: it ynstallearre klantpakket is it nije, de twa /1-rûtes sitte op 'e tunnelinterface, in privee bestimming antwurdet noch, en it log fan 'e ôfstânstsjinst toant it firewall-adres.