Azure-yksityinen IP-VPN ExpressRouten yli ilman NVA:ta

Myytti on, että liikenteen salaaminen ExpressRouten yksityisen peeringin yli vaatii virtuaalisen verkkolaitteen. Ei vaadi. Azure tukee Site-to-Site VPN Gatewaytä, jonka tunnelin päätepiste on yksityinen RFC1918-osoite, jota kuljetetaan piirin yli, ja laite on valinnainen eikä rakenteellinen. Sen, mitä laitemyytti kätkee, on se osa, joka todella puree: yksityisen päätepisteen ottaminen käyttöön yhdessä objektissa kahden sijaan ja sen salliminen, että suora peering-reitti voittaa hiljaa salatun polun.

Mistä myytti tuli

Väitteellä on kunnioitettava tausta. Vuosien ajan käytännön resepti IPsecille yksityisen peeringin yli oli NVA, koska hallittu yhdyskäytävä tarjosi vain julkisia päätepisteitä. Se muuttui, ja ennen muutosta kirjoitettuja vastauksia siteerataan edelleen ketjuissa, joissa kukaan ei tarkista päivämäärää. Korjaus on kapea: yksityisosoitteinen VPN-yhdyskäytävä on olemassa, ja se muuttaa päätepisteen, ei sen ympärillä olevaa reitityslogiikkaa.

Mikään tästä ei eläköitä NVA:ta. Se eläköittää oletuksen, että laite on ainoa tie vaatimukseen.

Ota yksityinen päätepiste käyttöön molemmilla tasoilla

Aloita toimivasta ExpressRouten yksityisen peeringin yhteydestä, joka on linkitetty VNetiin, jossa VPN-yhdyskäytävä on. Paikallisen puolen on jo päästävä kyseisiin yksityisiin osoitteisiin piirin yli, koska tunneli käyttää niitä osoitteita kuljetuksena. Sitten yhdyskäytävän edellytys: Microsoftin menettely yksityisen IP:n VPN:lle vaatii yhdyskäytävän, joka on rakennettu Standard-julkisen IP-resurssin päälle. Yksityinen tunneliosoitteistus ei poista tätä vaatimusta, mikä yllättää ihmiset, jotka olettavat, että „yksityinen“ tarkoittaa „ei julkista IP:tä missään“.

Ota nyt lippu käyttöön molemmissa paikoissa. Yhdyskäytävän kokoonpanolla on oma kytkimensä yksityisille IP:ille, ja yksittäisellä Site-to-Site-yhteydellä on toinen, joka saa kyseisen yhteyden käyttämään yksityistä osoitetta. Toisen asettaminen ja toisen jättäminen on yleisin puutteellinen kokoonpano; tunneli joko ei muodostu tai muodostuu väärään päätepisteeseen.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Vahvista ominaisuuksien nimet asennettua CLI-versiota vasten, koska portaalin tunnisteet ja CLI-ominaisuudet eivät aina käytä samaa sanamuotoa. Aktiivinen-aktiivinen yhdyskäytävä tarjoaa kaksi yksityistä tunneliosoitetta, ja paikallinen laite tarvitsee molemmat vastapuolet määritettyinä, jos haluat redundancyn merkitsevän jotain. BGP:tä ei vaadita pelkästään tämän yksityisosoitteisen tunnelin nostamiseen, vaikka se yleensä on osa tapaa, jolla jaat etuliitteitä.

Toinen myytti: muodostettu tunneli salaa liikenteesi

Kaksi polkua saavuttaa nyt sovellusverkon: suora yksityisen peeringin polku ja VPN:n kautta kulkeva polku. Molemmat toimivat. Vain yksi soveltaa tätä IPsec-kerrosta. Microsoft dokumentoi, että kun samat etuliitteet ilmoitetaan sekä ExpressRouten että VPN:n yli, Azure suosii suoraa ExpressRoute-polkua, joten terve tunneli ja terveet laskurit eivät todista mitään siitä, minne sovelluksen paketit menivät.

Dokumentoidut ohjausmenetelmät ovat kattava alue ExpressRoutella ja tarkempi suojattu alue VPN:llä tai toisistaan erilliset etuliitteet kahdella polulla. Esimerkiksi yksityinen peering voisi kuljettaa 10.40.0.0/16, kun VPN ilmoittaa 10.40.12.0/24. Tarkempi etuliite voittaa ja loput alueesta pysyy suorana.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Tee sama tarkistus paikalliseen suuntaan, koska reitittimesi mieltymys ratkaisee, mitä kautta lähtevä liikenne lähtee. Ja pidä tunnelin oma kuljetus ExpressRoute-polulla; reitti, joka vetää yhdyskäytävän yksityisen päätepisteen tunneliin, tekee tunnelista itsestään riippuvaisen.

Päätä, mitä tapahtuu, kun tunneli putoaa

Tarkempi VPN-reitti katoaa, kun tunneli putoaa, kun taas laajempi suora reitti jää. Liikenne kulkee silloin salaamattomana ja kaikki näyttää terveeltä, mikä on huonoin vikatila vaatimukselle, joka on olemassa salauksen takaamiseksi. Jos vaatimus kieltää tämän varareitin, reitityksen ja käyttöoikeuskäytännön on sanottava se nimenomaisesti sen sijaan, että luotetaan tunnelin saatavuuteen.

Kirjoita muistiin, mitkä etuliitteet voivat jäädä suoraan saavutettaviksi ja mitkä on pysäytettävä, kun salattu polku puuttuu. Testaa sitten sallittu tapaus oikealla liikenteellä ja vertaa yhteyden laskureita, koska pelkkä reititystaulu ei kerro, päteekö salausvaatimus edelleen.

Tämä kehys antaa sinun myös arvioida NVA:ta sen todellisten ominaisuuksien, kuten useiden tunnelien, läpäisyn tai toimittajatarkastuksen, perusteella sen sijaan, että ostaisit sen siksi, että päätepiste on yksityinen.