Bakit hindi binabago ng Azure Point-to-Site VPN ang iyong pampublikong IP
Ang point-to-site tunnel ay nagdadala lamang ng mga ruta ng virtual network, kaya nananatiling lokal ang iyong pampublikong IP hanggang ilipat ng forced tunneling at firewall SNAT ang egress sa Azure.
Kinokonekta ko ang Azure VPN client sa isang Windows laptop, binubuksan ang page ng echo ng address at nakikita ang parehong pampublikong address na ibinigay ng router sa bahay. Samantala, sumasagot ang jump box sa 10.20.0.4 at nareresolba ang pangalan ng pribadong endpoint, kaya hindi sira ang tunnel. Ginagawa ng point-to-site gateway ang eksaktong sinasabi ng default na configuration nito: dinadala ang mga pribadong prefix at iniiwan ang lahat ng iba pa sa lokal na link. Ang makakuha ng egress address na pag-aari ng Azure ay pagbabago ng disenyo ng routing, hindi pagkukumpuni.
Ano ang inaanunsyo ng gateway bilang default
Itinutulak ng gateway ang mga ruta para sa address space ng virtual network, kasama ang mga peer network kung saan pinapayagan ang gateway transit at mga on-premises prefix na natutunan sa site-to-site na koneksyon o BGP. Walang 0.0.0.0/0 sa set na iyon. Pinapanatili ng operating system mo ang default na ruta nito sa Wi-Fi o Ethernet, kaya ang packet papunta sa pampublikong API ay hindi kailanman pumapasok sa tunnel.
Ang address na natatanggap ng client sa loob ng tunnel ay isang pribadong lease mula sa point-to-site pool. Tinutukoy nito ang client sa mga resource sa VNet; hindi ito address na nakikita ng internet, at hindi kailanman lalabas bilang source ng isang outbound na kahilingan sa isang SaaS API. Ang entry sa allowlist na binuo sa paligid ng lease na iyon ay hindi maaaring gumana, gaano man katagal kang maghintay na lumitaw ito sa mga log ng vendor.
Split tunnel at forced tunneling nang magkatabi
| 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 |
Tanging ang ikalawang hilera ang nagbabago ng address na nakikita ng isang remote na serbisyo. Lahat ng iba pa sa talahanayang iyon ay gastos at operasyonal na surface na tinatanggap mo kapag kailangang suriin o isalin ang egress sa loob ng Azure. Kung may magpatulong sa iyo na baguhin ang pampublikong IP, hinihingi niya ang buong kanang kolum, hindi isang maliit na pagsasaayos sa client.
May gitnang opsyon na sulit pangalanan bago ka magtayo muli ng kahit ano. Ang isang proxy o gateway VM sa loob ng VNet ay nagbibigay sa iyo ng kontroladong source address para sa mga application na maaaring ituro doon, nang hindi ginagalaw ang default na ruta ng client. Pinapanatili nitong lokal ang normal na pag-browse at natutugunan pa rin ang isang partner na kailangan lamang ng isang API call na magmumula sa Azure. Nabigo ito kapag ang pangangailangan ay talagang tungkol sa lahat ng trapiko, dahil ang anumang bumabalewala sa proxy setting ay lumalabas pa rin nang lokal.
Ipadala ang default na ruta sa tunnel
Sa isang virtual network gateway, ang suportadong paraan para ihatid ang lahat ng internet traffic ng client sa tunnel ay ang pagdaragdag ng mga custom na ruta sa point-to-site configuration. Tinatakpan ng dalawang kalahati ang buong IPv4 space, at ang bawat isa ay mas partikular kaysa sa lokal na default na ruta, kaya mas pinipili ito ng client nang walang binubura:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Ang linyang iyon ay halimbawa lamang at hindi kumpleto para kopyahin: kunin muna ang gateway object gamit ang Get-AzVirtualNetworkGateway at palitan ang GWOBJ nito, at tiyakin bago patakbuhin na tinatanggap ng SKU at deployment model ang mga custom na ruta. Lumilitaw ang parehong mga prefix sa portal sa pahina ng point-to-site configuration, na mas ligtas na lugar para itakda ang mga ito kung hindi mo pa nagsa-script ang gateway.
Ang pagbabago ng mga prefix na iyon ay nagpapawalang-bisa sa client package. I-download muli ang VPN client package at i-install muli, dahil naglalakbay ang mga ruta sa loob ng profile. Ang client na muling kumokonekta gamit ang lumang profile ay pinapanatili ang lumang set ng ruta, at maaari kang mawalan ng isang oras sa pag-debug ng pagbabagong hindi kailanman nakarating dito.
Sa isang secured virtual WAN hub, ang katumbas ay isang default na ruta sa hub route table na nauugnay sa point-to-site gateway, kung saan ang Azure Firewall sa hub ang tumatanggap ng trapiko. Isinasalin ng firewall ang mga koneksyon papunta sa internet sa sarili nitong pampublikong IP address, at mula sa pagsasaling iyon nagmumula ang bagong egress address. Kapag ang firewall ay may ilang pampublikong IP, alinman sa mga ito ay maaaring lumitaw bilang source, kaya dapat taglayin ng allowlist ang lahat.
Ang dalawang disenyo sa itaas ay IPv4. Ang dalawang /1 prefix ay walang ginagawa para sa IPv6, at ang point-to-site IPv6 support ay sapat na makitid para subukan mo ang kombinasyon bago mangako ng pagtatapat.
Suriin ang ruta, pagkatapos ang labasan
Pagkatapos i-install muli ang package at muling kumonekta, tiyakin na aktwal na na-install ng client ang dalawang kalahati. Sa Windows, dapat pangalanan ng Get-NetRoute -DestinationPrefix 0.0.0.0/1 at ng parehong query para sa 128.0.0.0/1 ang tunnel interface, at ipinapakita ng route print ang pareho sa tabi ng orihinal mong default. Sa Linux, dapat ilista ng ip route show ang dalawang prefix; kung hindi, hindi kailanman dinadala ng profile ang mga ito.
Pagkatapos, suriin muli ang pampublikong address mula sa client at basahin ang firewall log para sa parehong koneksyon. Dapat ang pampublikong IP ng firewall na may isinaling port ang source. Ang client na lumalabas pa rin nang lokal habang umiiral ang parehong ruta ay nangangahulugang umabot ang mga packet sa Azure at lumabas sa ibang daan: isang user-defined route sa gateway subnet, isang firewall na mismong forced-tunnel sa lokal na network, o isang policy na nagbabagsak ng flow bago ang pagsasalin.
Subukan muli ang isang pribadong destinasyon sa parehong session. Ang jump host na tumitigil sumagot pagkatapos ng pagbabago ang karaniwang palatandaan na may naipitan ang mga bagong prefix, alinman sa mas makitid na lokal na ruta na inaanunsyo dati o sa pagresolba ng pangalan na ngayon ay papunta sa resolver na walang forwarder para sa iyong pribadong zone.
Kailan dapat iwanan ang split tunnel
Kung ang layunin ay maabot lamang ang isang pribadong API, pribadong endpoint o panloob na admin page, ang default na pag-uugali ay mas mura at mas tahimik. Ang forced tunneling ay nagdaragdag ng oras ng firewall at bayad sa pagproseso ng data, mas mahabang daan, at isa pang lugar kung saan maaaring mabigo ang bawat client flow. Mas marami rin itong nahuhuli na trapiko kaysa sa nag-iisang destinasyong inalala mo.
Gamitin ito kapag ang pangangailangan ay nakasaad sa mga tuntunin ng egress: dapat makita ng partner ang isang fixed na Azure address, gusto ng seguridad na ma-log at masuri ang mga koneksyon, o kailangang lumabas ng data sa isang kontroladong punto. Kahit noon, binibigyan ng disenyo ang bawat user ng shared na labasan, kaya ang pananagutan kada user ay dapat magmula sa identity sa application at hindi sa source address.
Bago isara ang pagbabago, tiyakin ang apat na bagay: ang naka-install na client package ay ang bago, ang dalawang /1 ruta ay nasa tunnel interface, sumasagot pa rin ang isang pribadong destinasyon, at ipinapakita ng log ng remote na serbisyo ang address ng firewall.