Miksi Azure Point-to-Site VPN ei muuta julkista IP-osoitettasi

Yhdistän Azure VPN -asiakkaan Windows-kannettavassa, avaan osoitteen kaikupohjan ja näen saman julkisen osoitteen, jonka kotireitittimeni jakoi. Sillä välin hyppypalvelin osoitteessa 10.20.0.4 vastaa ja yksityisen päätepisteen nimi ratkeaa, joten tunneli ei ole rikki. Point-to-site-yhdyskäytävä tekee täsmälleen sen, mitä sen oletusasetukset sanovat: kuljettaa yksityiset etuliitteet ja jättää kaiken muun paikalliseen linkkiin. Azure-omisteisen lähtöosoitteen saaminen on reitityssuunnittelun muutos, ei korjaus.

Mitä yhdyskäytävä mainostaa oletuksena

Yhdyskäytävä työntää reittejä virtuaaliverkon osoiteavaruudelle sekä vertaisverkoille, joissa yhdyskäytävän läpikulku on sallittu, ja paikalliset etuliitteet, jotka on opittu site-to-site-yhteyden tai BGP:n kautta. Siinä joukossa ei ole 0.0.0.0/0:aa. Käyttöjärjestelmäsi pitää oletusreittinsä Wi-Fissä tai Ethernetissä, joten julkiseen API:in menevä paketti ei koskaan päädy tunneliin.

Osoite, jonka asiakas saa tunnelin sisällä, on yksityinen vuokraus point-to-site-altaasta. Se tunnistaa asiakkaan VNetin resursseille; se ei ole osoite, jonka internet voi nähdä, eikä se koskaan esiinny SaaS-API:in menevän lähtevän pyynnön lähteenä. Vuokrauksen ympärille rakennettu sallittujen luettelon merkintä ei voi toimia, kuinka kauan tahansa odotat sen ilmestymistä toimittajan lokeihin.

Jaettu tunneli ja pakotettu tunnelointi rinnakkain

Vain toinen rivi muuttaa osoitetta, jonka etäpalvelu näkee. Kaikki muu taulukossa on kustannus ja ylläpitopinta, jonka hyväksyt, kun ulostulo on tarkastettava tai käännettävä Azuren sisällä. Jos joku pyytää sinua muuttamaan julkisen IP:n, hän pyytää koko oikean sarakkeen, ei pientä säätöä asiakkaassa.

On välimuoto, joka kannattaa nimetä ennen kuin rakennat mitään uudelleen. VNetin sisällä oleva välityspalvelin- tai yhdyskäytävä-VM antaa hallitun lähdeosoitteen sovelluksille, jotka voidaan ohjata siihen, siirtämättä asiakkaan oletusreittiä. Tämä pitää tavallisen selailun paikallisena ja tyydyttää silti kumppanin, joka tarvitsee vain yhden API-kutsun Azuresta. Se epäonnistuu, kun vaatimus koskee todella kaikkea liikennettä, koska mikä tahansa välityspalvelinasetuksen ohittava lähtee silti paikallisesti.

Anna tunnelin kantaa oletusreitti

Virtuaaliverkon yhdyskäytävässä tuettu tapa ohjata kaikki asiakkaan internettiliikenne tunneliin on lisätä mukautetut reitit point-to-site-kokoonpanoon. Kaksi puoliskoa kattaa koko IPv4-avaruuden, ja kumpikin on tarkempi kuin paikallinen oletusreitti, joten asiakas suosii niitä poistamatta mitään:

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

Tuo rivi on havainnollistava, ei valmis kopioitavaksi: hae ensin yhdyskäytävän objekti komennolla Get-AzVirtualNetworkGateway ja korvaa sillä GWOBJ, ja varmista ennen suorittamista, että SKU ja käyttöönottomalli hyväksyvät mukautetut reitit. Samat etuliitteet näkyvät portaalissa point-to-site-kokoonpanon sivulla, joka on turvallisempi paikka määrittää ne, jos et jo hallinnoi yhdyskäytävää skriptillä.

Näiden etuliitteiden muuttaminen tekee asiakaspaketista kelvottoman. Lataa VPN-asiakaspaketti uudelleen ja asenna se uudelleen, koska reitit kulkevat profiilin sisällä. Vanhalla profiilillaan uudelleen yhdistävä asiakas pitää vanhan reittijoukon, ja saatat menettää tunnin vianetsintään muutokselle, joka ei koskaan saavuttanut sitä.

Suojatussa virtuaalisessa WAN-keskittimessä vastine on oletusreitti keskittimen reititystaulukossa, joka on liitetty point-to-site-yhdyskäytävään, ja liikenteen ottaa keskittimen Azure Firewall. Palomuuri kääntää internettiin menevät yhteydet omiksi julkisiksi IP-osoitteikseen, ja juuri siitä käännöksestä uusi lähtöosoite tulee. Kun palomuurilla on useita julkisia IP:itä, mikä tahansa niistä voi näkyä lähteenä, joten sallittujen luettelossa on oltava ne kaikki.

Molemmat yllä olevat mallit ovat IPv4:tä. Kaksi /1-etuliitettä ei tee IPv6:lle mitään, ja point-to-siten IPv6-tuki on niin kapea, että yhdistelmä kannattaa testata ennen pariteetin lupaamista.

Tarkista reitti ja sitten ulostulo

Kun olet asentanut paketin uudelleen ja yhdistänyt, varmista, että asiakas todella asensi puoliskot. Windowsissa Get-NetRoute -DestinationPrefix 0.0.0.0/1 ja sama kysely 128.0.0.0/1:lle pitäisi nimetä tunnelin rajapinta, ja route print näyttää molemmat alkuperäisen oletusreittisi vieressä. Linuxissa ip route show:n on luettava molemmat etuliitteet; jos ei, profiili ei koskaan kuljettanut niitä.

Tarkista sitten julkinen osoite asiakkaasta uudelleen ja lue palomuuriloki samalle yhteydelle. Lähteen pitäisi olla palomuurin julkinen IP käännetyllä portilla. Asiakas, joka lähtee edelleen paikallisesti molempien reittien ollessa olemassa, tarkoittaa, että paketit saavuttivat Azuren ja lähtivät toista kautta: käyttäjän määrittämä reitti yhdyskäytävän aliverkossa, palomuuri, joka on itse pakotetusti tunnelissa paikallisverkkoon, tai käytäntö, joka pudottaa virran ennen käännöstä.

Testaa uudelleen yhtä yksityistä kohdetta samassa istunnossa. Hyppypalvelin, joka lakkaa vastaamasta muutoksen jälkeen, on tavallinen merkki siitä, että uudet etuliitteet syrjäyttivät jotain, joko kapeamman paikallisen reitin, jota aiemmin mainostettiin, tai nimien ratkaisun, joka menee nyt ratkaisijaan, jolla ei ole välittäjää yksityisille vyöhykkeillesi.

Milloin jättää jaettu tunneli rauhaan

Jos tavoitteena on vain päästä yksityiseen API:in, yksityiseen päätepisteeseen tai sisäiseen hallintasivuun, oletuskäyttäytyminen on halvempaa ja hiljaisempaa. Pakotettu tunnelointi lisää palomuuritunteja ja datankäsittelymaksuja, pidemmän polun ja vielä yhden paikan, jossa jokainen asiakasvirta voi epäonnistua. Se myös sieppaa paljon enemmän liikennettä kuin se yksi kohde, josta olit huolissasi.

Turvaudu siihen, kun vaatimus ilmaistaan ulostulon kannalta: kumppanin on nähtävä kiinteä Azure-osoite, tietoturva haluaa yhteydet lokitettavan ja tarkastettavan, tai tiedon on lähdettävä yhden hallitun pisteen kautta. Silloinkin malli antaa jokaiselle käyttäjälle jaetun ulostulon, joten käyttäjäkohtaisen vastuun on tultava sovelluksen identiteetistä, ei lähdeosoitteesta.

Ennen kuin suljet muutoksen, varmista neljä asiaa: asennettu asiakaspaketti on uusi, kaksi /1-reittiä ovat tunnelin rajapinnassa, yksityinen kohde vastaa edelleen ja etäpalvelun loki näyttää palomuurin osoitteen.