Kial Azure Point-to-Site VPN ne ŝanĝas vian publikan IP

Mi konektas la Azure VPN-klienton en Windows-portebla komputilo, malfermas adres-ekkon paĝon kaj vidas la saman publikan adreson, kiun donis mia hejma enkursigilo. Dume la saltoskatolo ĉe 10.20.0.4 respondas kaj privata finpunkta nomo solviĝas, do la tunelo ne estas rompita. Point-to-site-pordego faras ĝuste tion, kion diras ĝia defaŭlta agordo: ĝi portas la privatajn prefiksojn kaj lasas ĉion alian en la loka ligo. Akiri eliran adreson posedatan de Azure estas ŝanĝo de enkursiga projekto, ne riparo.

Kion la pordego anoncas defaŭlte

La pordego puŝas itinerojn por la adresspaco de la virtuala reto, plus samnivelaj retoj, kie pordega transito estas permesita, kaj lokaj prefiksoj lernitaj per site-to-site-ligo aŭ BGP. En tiu aro ne estas 0.0.0.0/0. Via operaciumo tenas sian defaŭltan itinerojn sur Wi-Fi aŭ Ethernet, do pakaĵo al publika API neniam eniras la tunelon.

La adreso, kiun kliento ricevas ene de la tunelo, estas privata luo el la point-to-site-baseno. Ĝi identigas la klienton al rimedoj en la VNet; ĝi ne estas adreso, kiun la interreto povas vidi, kaj ĝi neniam aperos kiel la fonto de elira peto al SaaS-API. Allowlist-enskribo konstruita ĉirkaŭ tiu luo ne povas funkcii, kiom ajn longe vi atendas, ke ĝi aperu en la vendistaj protokoloj.

Dividita tunelo kaj devigita tunelado flanko ĉe flanko

Nur la dua vico ŝanĝas la adreson, kiun vidas fora servo. Ĉio alia en tiu tabelo estas kosto kaj operacia surfaco, kiujn vi akceptas, kiam la eliro devas esti inspektita aŭ tradukita ene de Azure. Se iu petas vin ŝanĝi la publikan IP, li petas la tutan dekstran kolumnon, ne etan ĝustigon de la kliento.

Estas meza opcio inda nomi antaŭ ol vi rekonstruos ion ajn. Proxy- aŭ pordega VM ene de la VNet donas al vi kontrolitan fontan adreson por la aplikaĵoj, kiuj povas esti direktitaj al ĝi, sen movi la defaŭltan itinerojn de la kliento. Tio tenas ordinaran retumadon loka kaj tamen kontentigas partneron, kiu bezonas nur unu API-vokon alveni el Azure. Ĝi malsukcesas, kiam la postulo vere temas pri la tuta trafiko, ĉar ĉio, kio ignoras la proxy-agordon, tamen eliras loke.

Igu la tunelon porti la defaŭltan itinerojn

Sur virtuala reta pordego la subtenata maniero direkti la tutan interretan trafikon de la kliento en la tunelon estas aldoni proprajn itinerojn al la point-to-site-agordo. Du duonoj kovras la tutan IPv4-spacon, kaj ĉiu estas pli specifa ol la loka defaŭlta itinero, do la kliento preferas ilin sen forigi ion:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Tiu linio estas ilustra, ne kompleta por kopii: unue prenu la pordegan objekton per Get-AzVirtualNetworkGateway kaj anstataŭigu ĝin per GWOBJ, kaj antaŭ ol ruli ĝin konfirmu, ke la SKU kaj la deploja modelo akceptas proprajn itinerojn. La samaj prefiksoj aperas en la portalo sur la paĝo de point-to-site-agordo, kiu estas la pli sekura loko por agordi ilin, se vi jam ne skriptas la pordegon.

Ŝanĝi tiujn prefiksojn nuligas la klientan pakaĵon. Elŝutu la VPN-klientan pakaĵon denove kaj reinstalu ĝin, ĉar la itineroj vojaĝas ene de la profilo. Kliento, kiu rekonektiĝas per sia malnova profilo, konservas la malnovan itineraron, kaj vi povas perdi horon serĉante cimon en ŝanĝo, kiu neniam atingis ĝin.

En sekura virtuala WAN-hubo la ekvivalento estas defaŭlta itinero en la huba itinertabelo asociita kun la point-to-site-pordego, dum Azure Firewall en la hubo prenas la trafikon. La fajroŝirmilo tradukas interretajn konektojn al siaj propraj publikaj IP-adresoj, kaj el tiu traduko venas la nova elira adreso. Kiam fajroŝirmilo havas plurajn publikajn IP-ojn, iu ajn el ili povas aperi kiel la fonto, do allowlist devas enhavi ĉiujn.

Ambaŭ projektoj supre estas IPv4. La du prefiksoj /1 faras nenion por IPv6, kaj la point-to-site-subteno por IPv6 estas sufiĉe mallarĝa, ke vi testu la kombinaĵon antaŭ ol promesi egalecon.

Kontrolu la itineron, poste la eliron

Post reinstalo de la pakaĵo kaj rekonekto, konfirmu, ke la kliento vere instalas la duonojn. En Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 kaj la sama demando por 128.0.0.0/1 devus nomi la tunelan interfacon, kaj route print montras ambaŭ apud via originala defaŭlta itinero. En Linux ip route show devas listigi la du prefiksojn; se ne, la profilo neniam portis ilin.

Poste rekontrolu la publikan adreson de la kliento kaj legu la fajroŝirman protokolon por la sama konekto. La fonto devus esti la publika IP de la fajroŝirmilo kun tradukita pordo. Kliento, kiu ankoraŭ eliras loke dum ambaŭ itineroj ekzistas, signifas, ke pakaĵoj atingis Azure kaj forlasis per alia vojo: uzant-difinita itinero sur la pordega subreto, fajroŝirmilo, kiu mem estas devige tunelata al la loka reto, aŭ politiko, kiu forĵetas la fluon antaŭ la traduko.

Retestu unu privatan celon en la sama seanco. Salta gastiganto, kiu ĉesas respondi post la ŝanĝo, estas la kutima signo, ke la novaj prefiksoj forpuŝis ion, ĉu pli mallarĝan lokan itineron, kiu antaŭe estis anoncita, ĉu nom-solvon, kiu nun iras al solvilo sen plusendilo por viaj privataj zonoj.

Kiam lasi la dividitan tunelon trankvila

Se la celo estas nur atingi privatan API, privatan finpunkton aŭ internan administran paĝon, la defaŭlta konduto estas pli malmultekosta kaj pli silenta. Devigita tunelado aldonas fajroŝirmajn horojn kaj datenprilaborajn kostojn, pli longan vojon, kaj ankoraŭ unu lokon, kie ĉiu klienta fluo povas malsukcesi. Ĝi ankaŭ kaptas multe pli da trafiko ol la ununura celo, pri kiu vi zorgis.

Uzu ĝin, kiam la postulo estas esprimita laŭ eliro: partnero devas vidi fiksan Azure-adreson, sekureco volas, ke la konektoj estu protokolataj kaj inspektitaj, aŭ datumoj devas forlasi tra unu kontrolita punkto. Eĉ tiam la projekto donas al ĉiu uzanto komunan eliron, do respondeco por uzanto devas veni de identeco en la aplikaĵo, ne de la fonta adreso.

Antaŭ ol vi fermos la ŝanĝon, konfirmu kvar aferojn: la instalita klienta pakaĵo estas la nova, la du itineroj /1 sidas sur la tunela interfaco, privata celo ankoraŭ respondas, kaj la protokolo de la fora servo montras la fajroŝirman adreson.