Miért nem változtatja meg az Azure Point-to-Site VPN a nyilvános IP-címét

Csatlakoztatom az Azure VPN klienst egy Windows laptopon, megnyitok egy cím-visszhang oldalt, és ugyanazt a nyilvános címet látom, amelyet az otthoni routerem kiadott. Közben a 10.20.0.4-es ugrógép válaszol, és egy privát végpont neve feloldódik, tehát az alagút nem sérült. A point-to-site átjáró pontosan azt teszi, amit az alapértelmezett konfigurációja mond: szállítja a privát előtagokat, és minden mást a helyi kapcsolaton hagy. Azure-tulajdonú kimeneti cím megszerzése az útválasztási terv megváltoztatása, nem javítás.

Mit hirdet az átjáró alapértelmezés szerint

Az átjáró útvonalakat küld a virtuális hálózat címtartományához, valamint azokhoz a társított hálózatokhoz, ahol az átjáró-tranzit engedélyezett, és a site-to-site kapcsolaton vagy BGP-n keresztül tanult helyi előtagokhoz. Ebben a készletben nincs 0.0.0.0/0. Az operációs rendszere a Wi-Fi-n vagy Etherneten tartja az alapértelmezett útvonalát, ezért egy nyilvános API felé menő csomag soha nem lép be az alagútba.

A cím, amelyet a kliens az alagúton belül kap, privát bérlet a point-to-site készletből. A klienset azonosítja a VNet erőforrásai felé; ez nem olyan cím, amelyet az internet láthat, és soha nem fog az SaaS API felé menő kimenő kérés forrásaként megjelenni. Az erre a bérletre épített engedélyezési listabejegyzés nem működhet, akármeddig vár arra, hogy megjelenjen a szállító naplóiban.

Osztott alagút és kényszerített alagútkezelés egymás mellett

Csak a második sor változtatja meg azt a címet, amelyet egy távoli szolgáltatás lát. A táblázat minden más eleme költség és üzemeltetési felület, amelyet akkor vállal, amikor a kimenetet az Azure-on belül kell megvizsgálni vagy lefordítani. Ha valaki arra kéri, hogy változzon meg a nyilvános IP, a teljes jobb oldali oszlopot kéri, nem egy apró módosítást a kliensen.

Van egy köztes lehetőség, amelyet érdemes megnevezni, mielőtt bármit újjáépítene. Egy proxy- vagy átjáró-VM a VNeten belül ellenőrzött forráscímet ad azoknak az alkalmazásoknak, amelyek ráirányíthatók, anélkül hogy a kliens alapértelmezett útvonalát elmozdítaná. Ez a normál böngészést helyben tartja, és mégis kielégít egy partnert, akinek csak egyetlen API-hívásra van szüksége Azure-ból. Akkor vall kudarcot, amikor a követelmény valóban az összes forgalomra vonatkozik, mert minden, ami figyelmen kívül hagyja a proxy beállítást, mégis helyben lép ki.

Késztesse az alagutat az alapértelmezett útvonal hordozására

Virtuális hálózati átjárón a kliens teljes internethasználatának az alagútba terelésére támogatott módszer egyéni útvonalak hozzáadása a point-to-site konfigurációhoz. Két fél lefedi a teljes IPv4-teret, és mindegyik pontosabb a helyi alapértelmezett útvonalnál, ezért a kliens előnyben részesíti őket anélkül, hogy bármit törölne:

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

Ez a sor szemléltető, nem másolásra kész: először kérje le az átjáró objektumát a Get-AzVirtualNetworkGateway parancsával, és helyettesítse vele a GWOBJ-t, majd futtatás előtt erősítse meg, hogy az SKU és az üzembe helyezési modell elfogadja az egyéni útvonalakat. Ugyanezek az előtagok megjelennek a portálon a point-to-site konfigurációs oldalon, ami biztonságosabb hely a beállításukra, ha még nem szkripteli az átjárót.

Ezeknek az előtagoknak a megváltoztatása érvényteleníti az ügyfélcsomagot. Töltse le újra a VPN ügyfélcsomagot, és telepítse újra, mert az útvonalak a profilon belül utaznak. Az a kliens, amely a régi profiljával csatlakozik újra, megtartja a régi útvonalkészletet, és elveszíthet egy órát egy olyan változtatás hibakeresésével, amely soha nem érte el.

Egy biztonságos virtuális WAN-központban ennek megfelelője egy alapértelmezett útvonal a központ útvonaltáblájában, amely a point-to-site átjáróhoz kapcsolódik, a forgalmat pedig a központban lévő Azure Firewall veszi át. A tűzfal az internet felé menő kapcsolatokat a saját nyilvános IP-címeire fordítja, és ebből a fordításból származik az új kimeneti cím. Ha egy tűzfalnak több nyilvános IP-je van, bármelyikük megjelenhet forrásként, ezért az engedélyezési listának mindegyiket tartalmaznia kell.

A fenti két terv IPv4-es. A két /1 előtag semmit nem tesz az IPv6-ért, és a point-to-site IPv6-támogatása elég szűk ahhoz, hogy a kombinációt tesztelje, mielőtt paritást ígér.

Ellenőrizze az útvonalat, majd a kimenetet

A csomag újratelepítése és az újracsatlakozás után erősítse meg, hogy a kliens valóban telepítette a feleket. Windowson a Get-NetRoute -DestinationPrefix 0.0.0.0/1 és ugyanaz a lekérdezés a 128.0.0.0/1-re az alagút interfészét kell megnevezze, a route print pedig mindkettőt az eredeti alapértelmezett útvonala mellett mutatja. Linuxon az ip route show-nak fel kell sorolnia a két előtagot; ha nem teszi, a profil soha nem szállította őket.

Ezután ellenőrizze újra a nyilvános címet a kliensről, és olvassa el a tűzfal naplóját ugyanahhoz a kapcsolathoz. A forrásnak a tűzfal nyilvános IP-jének kell lennie, lefordított porttal. Az a kliens, amely továbbra is helyben lép ki, miközben mindkét útvonal létezik, azt jelenti, hogy a csomagok elérték az Azure-t, és más úton távoztak: felhasználó által definiált útvonal az átjáró alhálózatán, olyan tűzfal, amely maga is kényszerített alagúton megy a helyi hálózat felé, vagy olyan szabályzat, amely a fordítás előtt eldobja a folyamot.

Teszteljen újra egy privát célpontot ugyanabban a munkamenetben. Az ugrógép, amely a változtatás után abbahagyja a válaszolást, a szokásos jele annak, hogy az új előtagok kiszorítottak valamit: vagy egy korábban hirdetett szűkebb helyi útvonalat, vagy a névfeloldást, amely most olyan feloldóhoz megy, amelynek nincs továbbítója a privát zónáihoz.

Mikor hagyja békén az osztott alagutat

Ha a cél csak egy privát API, egy privát végpont vagy egy belső admin oldal elérése, az alapértelmezett viselkedés olcsóbb és csendesebb. A kényszerített alagútkezelés tűzfalórákat és adatfeldolgozási díjakat, hosszabb utat és még egy helyet ad hozzá, ahol minden kliensfolyam meghiúsulhat. Sokkal több forgalmat is elkap, mint az az egyetlen cél, amely miatt aggódott.

Akkor nyúljon hozzá, amikor a követelmény a kimenet szempontjából fogalmazódik meg: egy partnernek fix Azure-címet kell látnia, a biztonság a kapcsolatok naplózását és vizsgálatát kéri, vagy az adatoknak egyetlen ellenőrzött ponton kell távozniuk. Még ekkor is a terv minden felhasználónak közös kimenetet ad, ezért a felhasználónkénti elszámoltathatóságnak az alkalmazásban lévő identitásból kell jönnie, nem a forráscímből.

Mielőtt lezárja a változtatást, erősítsen meg négy dolgot: a telepített ügyfélcsomag az új, a két /1 útvonal az alagút interfészén van, egy privát célpont még válaszol, és a távoli szolgáltatás naplója mutatja a tűzfal címét.