Azure-peering vai VNet–VNet-VPN? Päätä ennen reititystä

Azure tarjoaa ainakin kaksi tapaa yhdistää kaksi virtuaaliverkkoa, eivätkä ne ole saman objektin vaihdettavia asetuksia. Peering yhdistää VNetit Microsoftin runkoverkossa ilman gatewaytä; VNet–VNet-VPN asettaa IPsec-suhteen kahden gatewayn välille, jotka sinä otat käyttöön, mitoitat ja valvot. Päätös palautuu kolmeen ehtoon, ja jos et pysty vastaamaan kaikkiin kolmeen ennen reitin lisäämistä, olet rakentamassa kiertotietä mallille, jota et koskaan valinnut.

Kolme ehtoa, jotka ratkaisevat mallin

Ensimmäinen on, tarvitseeko vaatimuksen jokin osa IPsec-rajaa, joka on sinun ja johon voit osoittaa. Toinen on, ovatko osoiteavaruudet puhtaat ja tarvitseeko kahden VNetin vain puhua keskenään. Kolmas on, kuka omistaa mahdollisen transit-reitin ja gateway-laskun. Vastaa tässä järjestyksessä, sillä ensimmäinen voi sulkea peeringin pois, oli toinen miten houkutteleva tahansa.

Yhteistä molemmille malleille on kova osoitteistussääntö: VNetien osoiteavaruudet eivät saa mennä päällekkäin. Peering tai VNet–VNet-VPN ei ole tuettu tapa tehdä kahdesta identtisestä alueesta yksiselitteisiä, ja päällekkäisyys vaatii kartoitusratkaisun tai uudelleensuunnittelun, ei eri yhteystyyppiä.

Ehto 1: tarvitsetko IPsec-rajan, joka on sinun?

Peering kuljettaa liikennettä Azuren yksityisessä runkoverkossa eikä vaadi VPN-gatewaytä itse peering-yhteydelle. Tämä on väite kuljetuksesta, ei väite salauksesta, jonka voisit antaa tilintarkastajalle muodossa «käytämme IPsec». Jos vaatimus nimeää asiakkaan määrittämän tunnelin, tietyn IKE-käytännön tai rajan, joka päättyy hallitsemaasi laitteeseen, peering ei täytä sitä, olipa runkoverkko miten yksityinen tahansa.

VNet–VNet-VPN tarjoaa tuon rajan: kaksi gatewaytä, IPsec/IKE-suhteen, jaetut avaimet ja kaiken mukana tulevan operatiivisen pinnan. Perit tunnelin tilan, gatewayn kapasiteetin, SKU-rajat ja valvonnan, joka todistaa tunnelin olevan pystyssä. Se on oikea vastaus, kun vaatimus koskee juuri tuota rajaa, joka kuvataan peeringin yleiskatsauksessa peeringistä erillisenä yhteystyyppinä.

Ole yhtä huolellinen toiseen suuntaan. «Tarvitsemme salausta VNetien välille» täyttyy usein työkuorman omalla TLS:llä, ja silloin gateway on kustannus ilman vaatimusta sen takana. Kirjoita lause, jonka tilintarkastaja lukee, ennen kuin valitset mekanismin.

Ehto 2: onko topologia suora vai täytyykö jonkin kulkea läpi?

Peering ei ole transitiivinen. Kaksi hubiin peerattua VNetiä ei ole siten yhteydessä toisiinsa, ja reitti, joka näyttää toimivan yhteen suuntaan, on yleensä peering, joka saavutti Connected-tilan vain toisella puolella. Molempien puolten on oltava olemassa ja molempien näytettävä Connected, ja se on ensimmäinen asia, jonka tarkistat, kun liikenne katoaa hiljaa.

Jos vaatimus on pääsy paikallisverkkoon hubin kautta, gateway-transit on erillinen suunnittelu, jossa on tietyt roolit: hub omistaa gatewayn, spoke-peering sallii gateway-transitin ja spoken on sallittava edelleenlähetetty liikenne. Nämä ovat peeringin ominaisuuksia, eivät VNetien yhdistämisen automaattisia seurauksia:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Tehokas reititystaulu on rehellinen vastaus kysymykseen «onko polku olemassa?». Se näyttää seuraavan hypyn tyypin, jota alusta todella käyttää, joten peering, joka näyttää määritetyltä mutta ei ole yhteydessä, näkyy puuttuvana tai vääränä reittinä eikä mysteerinä.

Ehto 3: kuka omistaa transit-reitin ja laskun?

Jokaisella lisähypyllä on omistaja. Peeringissä uusi VNet tarkoittaa uutta peering-paria molemmilla puolilla ja transitiivisuudessa hubia, joka jatkaa liikenteen välittämistä, sekä reititystaulua, joka jatkaa siihen osoittamista. VPN:ssä uusi VNet tarkoittaa toista gatewaytä tai toista yhteyttä olemassa olevaan, omalla seurattavalla kapasiteettikatollaan.

Kustannus seuraa samaa muotoa mutta ei samoja eriä: peeringin veloitukset ovat yhteys ja tiedonsiirto, kun taas VPN lisää gateway-tunnit ja omat siirtoveloituksensa. Vertaa kokonaisuutta topologialle, jota todella ajat vuoden, mukaan lukien toinen tunneli ja valvonta, et yhden yhteyden tämän päivän hintaa. Sisällytä työ, jota kukaan ei laskuta: jonkun on kierrätettävä avaimet, seurattava tunnelin tilaa ja vastattava hälytykseen kolmelta aamuyöllä, kun gateway käynnistyy uudelleen. Juuri tuo erä ratkaisee väittelyn yleensä, koska se on ainoa, joka ei koskaan esiinny tarjouksessa.

Minkä valitsetkin, testaa kolme virtausta: aiottu, hylätty joka pitää jäädä hylätyksi, ja palautumistapaus, jossa hubin gateway tai peering on alhaalla. Malli, joka selittää vain onnellisen polun, ei ole vahvistettu, se on esitelty.

Vahvista valinta sen omaa väitettä vastaan

Kirjoita yksi lause, joka nimeää mallin, rajan ja omistajan, ja tarkista sitten, että käyttöönotettu tila vastaa sitä. Peeringille se tarkoittaa, että molemmat peering-tilat ovat Connected, tehokas reitti näyttää peeringin seuraavan hypyn kohdeprefiksille ja polulla ei ole gatewaytä. VNet–VNet-VPN:lle se tarkoittaa, että molemmat yhteydet ovat Connected, avaimet ja käytännöt täsmäävät molemmissa gatewayissä ja reitillä on seuraavana hyppynä virtuaaliverkon gateway.

Jos tarkistukset ovat ristiriidassa lauseen kanssa, korjaa ensin lause. Suurin osa näiden suunnitelmien sekaannuksesta tulee hybridistä, jota kukaan ei kuvannut: peering työkuorman aliverkolle, VPN yhdelle vanhalle palvelulle ja reititystaulu, joka hiljaa suosii yhtä niistä.