Af hverju Azure Point-to-Site VPN breytir ekki opinberu IP-tölunni þinni

Ég tengi Azure VPN biðlarann á Windows fartölvu, opna síðu sem endurvarpar vistfanginu og sé sama opinbera vistfangið og heimanet-beinirinn minn úthlutaði. Á meðan svarar stökkvélinn á 10.20.0.4 og nafn einkatengipunkts leysist, svo göngin eru ekki brotin. Point-to-site hlið gerir nákvæmlega það sem sjálfgefin uppsetning þess segir: flytur einkaforskeytin og skilur allt annað eftir á staðbundnu tengingunni. Að fá útgangsvistfang í eigu Azure er breyting á leiðarhönnun, ekki viðgerð.

Hvað hliðið auglýsir sjálfgefið

Hliðið ýtir leiðum fyrir vistfangarými sýndarnetsins, auk jafningjaneta þar sem hliðarflutningur er leyfður og staðbundinna forskyta sem lærð eru um site-to-site tengingu eða BGP. Það er ekkert 0.0.0.0/0 í því mengi. Stýrikerfið þitt heldur sjálfgefinni leið sinni á Wi-Fi eða Ethernet, svo pakki á leið til opinbers API fer aldrei inn í göngin.

Vistfangið sem biðlarinn fær inni í göngunum er einkalán úr point-to-site lauginni. Það auðkennir biðlarann gagnvart auðlindum í VNet; það er ekki vistfang sem internetið getur séð og mun aldrei birtast sem uppspretta útleiðarbeiðni til SaaS API. Færsla á leyfðum lista sem byggð er í kringum það lán getur ekki virkað, hversu lengi sem þú bíður eftir að hún birtist í annálum söluaðilans.

Skipt göng og þvinguð göng hlið við hlið

Aðeins önnur röðin breytir vistfanginu sem fjartengd þjónusta sér. Allt annað í þeirri töflu er kostnaður og rekstrarflötur sem þú samþykkir þegar útgangurinn verður að vera skoðaður eða þýddur inni í Azure. Ef einhver biður þig að láta opinbera IP-ið breytast er hann að biðja um alla hægri dálkinn, ekki smáaðlögun á biðlaranum.

Það er millivalkostur sem er þess virði að nefna áður en þú byggir eitthvað upp á nýtt. Proxy- eða hliðar-VM inni í VNetinu gefur þér stýrt uppsprettuvistfang fyrir forritin sem hægt er að beina að því, án þess að færa sjálfgefna leið biðlarans. Það heldur venjulegri vafrun staðbundinni og fullnægir samt samstarfsaðila sem þarf aðeins eitt API-kall frá Azure. Það bregst þegar krafan snýst í raun um alla umferð, því allt sem hunsar proxy-stillinguna fer samt út staðbundið.

Láttu göngin bera sjálfgefnu leiðina

Á hliði sýndarnets er studda leiðin til að beina allri internetumferð biðlarans í göngin að bæta sérsniðnum leiðum við point-to-site uppsetninguna. Tveir helmingar ná yfir allt IPv4 rýmið og hvor er sértækari en staðbundin sjálfgefna leið, svo biðlarinn kýs þær án þess að eyða neinu:

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

Þessi lína er til skýringar, ekki tilbúin til að klippa og líma: sæktu fyrst hliðarhlutinn með Get-AzVirtualNetworkGateway og settu hann í stað GWOBJ, og staðfestu að SKU-in og uppsetningarlíkanið þekki sérsniðnar leiðir áður en þú keyrir hana. Sömu forskyttin birtast í gáttinni á point-to-site uppsetningarsíðunni, sem er öruggari staðurinn til að stilla þau ef þú ert ekki þegar með hliðið í skriftu.

Að breyta þessum forskyttum gerir biðlarapakkann ógildan. Sæktu VPN biðlarapakkann aftur og settu hann upp á ný, því leiðirnar ferðast inni í sniðinu. Biðlari sem tengist aftur með gamla sniðinu heldur gamla leiðasettinu og þú getur tapað klukkustund í að kemba breytingu sem náði aldrei til hans.

Í öruggri sýndar-WAN stöð er samsvarandi hlutur sjálfgefna leið í leiðatöflu stöðvarinnar sem tengd er point-to-site hliðinu, en Azure Firewall í stöðinni tekur umferðina. Eldveggurinn þýðir tengingar á leið til internetsins yfir á sín eigin opinberu IP-vistföng og úr þeirri þýðingu kemur nýja útgangsvistfangið. Þegar eldveggur hefur nokkur opinber IP, getur hvert þeirra birst sem uppsprettan, svo leyfður listi verður að innihalda þau öll.

Báðar hannanirnar hér að ofan eru IPv4. Forskeytin tvö /1 gera ekkert fyrir IPv6 og IPv6 stuðningur point-to-site er nógu þröngur til að þú prófir samsetninguna áður en þú lofar jafnrétti.

Athugaðu leiðina, svo útganginn

Eftir að hafa sett pakkann upp á ný og tengst aftur skaltu staðfesta að biðlarinn hafi í raun sett upp helmingana. Í Windows ættu Get-NetRoute -DestinationPrefix 0.0.0.0/1 og sama fyrirspurn fyrir 128.0.0.0/1 að nefna gagnatenginguna og route print sýnir bæði við hlið upprunalegu sjálfgefnu leiðarinnar. Í Linux verður ip route show að telja upp forskyttin tvö; ef ekki bar sniðið þau aldrei.

Athugaðu svo opinbera vistfangið frá biðlaranum aftur og lestu eldveggjarannálinn fyrir sömu tengingu. Uppsprettan ætti að vera opinbert IP eldveggsins með þýddri gátt. Biðlari sem fer enn út staðbundið þó báðar leiðir séu til þýðir að pakkarnir náðu Azure og fóru út um aðra leið: notandaskilgreinda leið á hliðarundirnetinu, eldvegg sem er sjálfur þvingaður í göng til staðbundna netsins, eða stefna sem sleppir flæðinu fyrir þýðinguna.

Prófaðu eitt einkatengimark aftur í sama lotu. Stökkvél sem hættir að svara eftir breytinguna er venjulega merkið um að nýju forskyttin hafi ýtt einhverju til hliðar, annaðhvort þrengri staðbundinni leið sem áður var auglýst eða nafnaleysingu sem fer nú til leysanda án framsendingar fyrir einkasvæðin þín.

Hvenær á að láta skiptu göngin í friði

Ef markmiðið er aðeins að ná í einka-API, einkatengipunkt eða innri stjórnendarsíðu er sjálfgefna hegðunin ódýrari og hljóðlátari. Þvinguð göng bæta við eldveggsklstundum og gagnavinnslugjöldum, lengri leið og einum stað til viðbótar þar sem hvert biðlaraflæði getur mistekist. Það grípur einnig miklu meiri umferð en eina áfangastaðinn sem þér þótti vænt um.

Gríptu til þess þegar krafan er sett fram út frá útgangi: samstarfsaðili verður að sjá fast Azure vistfang, öryggið vill að tengingarnar séu skráðar og skoðaðar, eða gögn verða að fara út um einn stýrðan punkt. Jafnvel þá gefur hönnunin hverjum notanda sameiginlegan útgang, svo ábyrgð hvers notanda verður að koma frá auðkenni í forritinu frekar en frá uppsprettuvistfanginu.

Áður en þú lokar breytingunni skaltu staðfesta fjóra hluti: uppsetta biðlarapakkinn er sá nýi, leiðirnar tvær /1 eru á gagnatengingunni, einkatengimark svarar enn og annáll fjartengdu þjónustunnar sýnir eldveggsvistfangið.