Kodėl Azure Point-to-Site VPN nekeičia jūsų viešojo IP
Point-to-site tunelis perduoda tik virtualaus tinklo maršrutus, todėl jūsų viešasis IP lieka vietinis, kol priverstinis tunelizavimas ir užkardos SNAT neperkelia išėjimo į Azure.
Prisijungiu Azure VPN klientą Windows nešiojamajame kompiuteryje, atidarau adreso atgarsio puslapį ir matau tą patį viešąjį adresą, kurį išdavė mano namų maršrutizatorius. Tuo tarpu jump box adresu 10.20.0.4 atsako ir privataus endpoint pavadinimas išsprendžiamas, taigi tunelis nesugadintas. Point-to-site šliuzas daro būtent tai, ką sako jo numatytoji konfigūracija: perduoda privačius prefiksus ir viską kita palieka vietinėje jungtyje. Azure priklausančio išėjimo adreso gavimas yra maršrutizavimo dizaino pakeitimas, o ne taisymas.
Ką šliuzas skelbia pagal numatytuosius nustatymus
Šliuzas stumia maršrutus virtualaus tinklo adresų erdvei, taip pat susietiems tinklams, kur leidžiamas šliuzo tranzitas, ir vietiniams prefiksams, išmoktiems per site-to-site ryšį arba BGP. Toje aibėje nėra 0.0.0.0/0. Jūsų operacinė sistema laiko numatytąjį maršrutą Wi-Fi arba Ethernet, todėl paketas į viešą API net nepatenka į tunelį.
Adresas, kurį klientas gauna tunelio viduje, yra privati nuoma iš point-to-site baseino. Jis identifikuoja klientą VNet ištekliams; tai ne adresas, kurį gali matyti internetas, ir jis niekada neatsiras kaip išeinančios užklausos į SaaS API šaltinis. Allowlist įrašas, sukurtas aplink šią nuomą, negali veikti, kad ir kiek lauktumėte, kol jis pasirodys tiekėjo žurnaluose.
Padalytas tunelis ir priverstinis tunelizavimas greta
| 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 |
Tik antroji eilutė keičia adresą, kurį mato nuotolinė paslauga. Visa kita toje lentelėje yra sąnaudos ir operacinis paviršius, kuriuos priimate, kai išėjimas turi būti tikrinamas arba verčiamas Azure viduje. Jei kas nors prašo pakeisti viešąjį IP, jis prašo viso dešiniojo stulpelio, o ne mažo kliento pataisymo.
Yra tarpinis variantas, kurį verta pavadinti prieš ką nors perdarant. Proxy arba šliuzo VM VNet viduje suteikia kontroliuojamą šaltinio adresą programoms, kurias galima nukreipti į jį, nejudinant kliento numatytojo maršruto. Tai palieka įprastą naršymą vietinį ir vis tiek patenkina partnerį, kuriam reikia tik vieno API iškvietimo iš Azure. Jis nepavyksta, kai reikalavimas iš tikrųjų susijęs su visu srautu, nes viskas, kas nepaiso proxy nustatymo, vis tiek išeina vietiškai.
Priverskite tunelį perduoti numatytąjį maršrutą
Virtualaus tinklo šliuze palaikomas būdas nukreipti visą kliento interneto srautą į tunelį yra pridėti pasirinktinius maršrutus prie point-to-site konfigūracijos. Dvi pusės apima visą IPv4 erdvę, ir kiekviena yra konkretesnė už vietinį numatytąjį maršrutą, todėl klientas teikia joms pirmenybę nieko netrindamas:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Ši eilutė yra iliustracinė, o ne paruošta kopijuoti: pirmiausia gaukite šliuzo objektą naudodami Get-AzVirtualNetworkGateway ir pakeiskite juo GWOBJ, ir prieš vykdydami patvirtinkite, kad SKU ir diegimo modelis priima pasirinktinius maršrutus. Tie patys prefiksai rodomi portale point-to-site konfigūracijos puslapyje, kuri yra saugesnė vieta juos nustatyti, jei dar nerašote šliuzo scenarijaus.
Pakeitus šiuos prefiksus kliento paketas tampa negaliojantis. Atsisiųskite VPN kliento paketą iš naujo ir įdiekite jį iš naujo, nes maršrutai keliauja profilio viduje. Klientas, kuris vėl prisijungia su senu profiliu, išlaiko seną maršrutų rinkinį, ir galite prarasti valandą derindami pakeitimą, kuris jo niekada nepasiekė.
Apsaugotame virtualiame WAN centre atitikmuo yra numatytasis maršrutas centro maršrutų lentelėje, susietoje su point-to-site šliuzu, o srautą paima Azure Firewall centre. Užkarda verčia interneto krypties ryšius į savo viešuosius IP adresus, ir būtent iš šio vertimo atsiranda naujasis išėjimo adresas. Kai užkarda turi kelis viešuosius IP, bet kuris iš jų gali pasirodyti kaip šaltinis, todėl allowlist turi juos visus.
Abu aukščiau pateikti sprendimai yra IPv4. Du /1 prefiksai nieko nedaro IPv6, o point-to-site IPv6 palaikymas yra toks siauras, kad derėtų išbandyti derinį prieš žadant paritetą.
Patikrinkite maršrutą, tada išėjimą
Įdiegę paketą iš naujo ir vėl prisijungę, patvirtinkite, kad klientas tikrai įdiegė abi puses. Windows Get-NetRoute -DestinationPrefix 0.0.0.0/1 ir ta pati užklausa 128.0.0.0/1 turėtų nurodyti tunelio sąsają, o route print rodo abu šalia pradinio numatytojo maršruto. Linux ip route show turi išvardyti du prefiksus; jei ne, profilis jų niekada neperdavė.
Tada dar kartą patikrinkite viešąjį adresą iš kliento ir perskaitykite užkardos žurnalą tam pačiam ryšiui. Šaltinis turėtų būti užkardos viešasis IP su išverstu portu. Klientas, kuris vis dar išeina vietiškai, nors abu maršrutai egzistuoja, reiškia, kad paketai pasiekė Azure ir išėjo kitu keliu: vartotojo apibrėžtas maršrutas šliuzo subnete, užkarda, kuri pati priverstinai tuneliuojama į vietinį tinklą, arba politika, kuri atmeta srautą prieš vertimą.
Dar kartą išbandykite vieną privatų tikslą toje pačioje sesijoje. Jump host, kuris nustoja atsakinėti po pakeitimo, yra įprastas ženklas, kad nauji prefiksai ką nors išstūmė, arba siauresnį vietinį maršrutą, kuris anksčiau buvo skelbiamas, arba vardų sprendimą, kuris dabar eina į resolverį be persiuntėjo jūsų privačioms zonoms.
Kada palikti padalytą tunelį ramybėje
Jei tikslas yra tik pasiekti privatų API, privatų endpoint ar vidinį administravimo puslapį, numatytasis elgesys yra pigesnis ir tylesnis. Priverstinis tunelizavimas prideda užkardos valandų ir duomenų apdorojimo mokesčių, ilgesnį kelią ir dar vieną vietą, kur kiekvienas kliento srautas gali nepavykti. Jis taip pat pagauna daug daugiau srauto nei vienintelis tikslas, kuris jums rūpėjo.
Imkitės jo, kai reikalavimas formuluojamas išėjimo požiūriu: partneris turi matyti fiksuotą Azure adresą, saugumas nori, kad ryšiai būtų registruojami ir tikrinami, arba duomenys turi išeiti per vieną kontroliuojamą tašką. Net tada sprendimas kiekvienam vartotojui suteikia bendrą išėjimą, todėl atskaitomybė už vartotoją turi kilti iš tapatybės programoje, o ne iš šaltinio adreso.
Prieš uždarydami pakeitimą patvirtinkite keturis dalykus: įdiegtas kliento paketas yra naujasis, du /1 maršrutai yra tunelio sąsajoje, privatus tikslas vis dar atsako, o nuotolinės paslaugos žurnalas rodo užkardos adresą.