VNet-vertaisverkotus ja palvelupäätepisteet

Eri Azure VNet -verkkojen resurssit eivät oletusarvoisesti voi viestiä keskenään, vaikka ne sijaitsisivat samalla Azure-alueella. Suurilla organisaatioilla on kuitenkin usein useita VNet-verkkoja: erilliset VNet-verkot kehitykselle, testaukselle ja tuotannolle tai eri VNet-verkot eri osastoille. VNet-verkon vertaisverkotus yhdistää kaksi VNet-verkkoa suoraan Microsoftin yksityisen runkoverkon kautta. Näin kummankin VNet-verkon resurssit voivat viestiä ikään kuin ne olisivat samassa verkossa, ilman että liikenne kulkee julkisen internetin kautta tai että tarvitaan VPN-yhdyskäytävää.

VNet-verkon vertaisverkotus on ei-transitiivinen yhteys: jos VNet A on vertaisverkotettu VNet B:n kanssa ja VNet B VNet C:n kanssa, VNet A ei voi viestiä VNet C:n kanssa, ellet luo erillistä vertaisverkotusta A:n ja C:n välille. Vertaisverkkoyhteydet ovat kaksisuuntaisia, mutta ne on määritettävä molemmille puolille — vertaisverkotuksen luominen A:sta B:hen ei luo automaattisesti yhteyttä B:stä A:han. Kun molemmat puolet on määritetty, vertaisverkotettujen VNet-verkkojen välinen liikenne kulkee Azure-runkoverkossa pienellä viiveellä ja suurella kaistanleveydellä, joka vastaa yhden VNet-verkon aliverkkojen välistä viestintää.

VNet-peeringissä on kaksi käyttöaluetta: paikallinen VNet-peering yhdistää kaksi VNet-verkkoa samalla Azure-alueella. Liikenne pysyy alueen sisällä, ja siitä veloitetaan pieni tiedonsiirtomaksu gigatavua kohden. Globaali VNet-peering yhdistää kaksi VNet-verkkoa eri Azure-alueilla, ja liikenne reititetään Microsoftin maailmanlaajuisen runkoverkon kautta. Näin East US -alueen resurssit voivat viestiä yksityisesti West Europe -alueen resurssien kanssa ilman julkisen internetin käyttöä. Globaalin peeringin tiedonsiirtokustannukset ovat hieman paikallista peeringiä suuremmat, mutta ratkaisu on silti huomattavasti edullisempi ja luotettavampi kuin VPN:n kautta reitittäminen.

Yleinen yritysympäristöjen malli käyttää VNet-peeringiä hub-and-spoke-topologian toteuttamiseen. Keskitetty hub-VNet sisältää jaetut palvelut, kuten Azure Firewallin, VPN Gatewayn, DNS-palvelimet ja valvonnan. Useat spoke-VNet-verkot, yksi kutakin ympäristöä tai työkuormaa kohden, muodostavat peering-yhteyden hubiin. Kun kaikki spoke-verkkojen liikenne reititetään hubin palomuurin kautta, organisaatio saa keskitetyn tietoturvatarkastuksen ilman monimutkaista NSG-hallintaa jokaisessa spoke-verkossa. Koska peering ei ole transitiivinen, hubin palomuuri reitittää liikenteen spoke-verkkojen välillä User-Defined Routes (UDRs) -reittien avulla.

VNet-peeringillä on yksi tärkeä vaatimus: peering-yhteydessä olevien VNet-verkkojen osoiteavaruudet eivät saa olla päällekkäisiä. Jos VNet A käyttää osoiteavaruutta 10.0.0.0/16 ja VNet B käyttää myös osoiteavaruutta 10.0.0.0/16, peering epäonnistuu, koska Azure ei pysty reitittämään liikennettä identtisten osoitealueiden välillä. Siksi kaikille VNet-verkoille ja paikallisverkoille on erittäin tärkeää suunnitella toisistaan erilliset CIDR-alueet ennen käyttöönoton aloittamista. VNet-verkon osoiteavaruuden muuttaminen resurssien käyttöönoton jälkeen edellyttää VNet-verkon luomista uudelleen tai rajoitetun osoiteavaruuden lisäämis- ja poistamisominaisuuden käyttämistä.

Palvelun päätepisteet laajentavat VNet-verkon identiteetin Azure PaaS -palveluihin, kuten Azure Storageen, Azure SQL Databaseen, Azure Key Vaultiin ja Cosmos DB:hen. Kun otat palvelun päätepisteen käyttöön aliverkossa, kyseisen aliverkon resurssien liikenne määritettyyn Azure-palveluun reititetään Azure-runkoverkon kautta julkisen internetin sijaan, vaikka palvelun julkista IP-osoitetta käytetäänkin. Palvelu voi tämän jälkeen rajoittaa käytön vain resursseihin niissä VNet-verkoissa, joissa palvelun päätepiste on otettu käyttöön. Tämä parantaa tietoturvaa huomattavasti verrattuna internetin kautta käytettäviin päätepisteisiin.

Palvelun päätepisteet ja yksityiset päätepisteet mahdollistavat suojatun pääsyn Azure PaaS -palveluihin, mutta ne toimivat eri tavoin: Palvelun päätepiste — reitittää liikenteen Azure-runkoverkon kautta, mutta käyttää edelleen palvelun julkista IP-osoitetta; palvelun päätepiste toimii aliverkkotasolla. Yksityinen päätepiste — määrittää palvelulle VNet-verkostasi peräisin olevan yksityisen IP-osoitteen; julkinen päätepiste voidaan poistaa kokonaan käytöstä, jolloin palvelu on aidosti yksityinen. Yksityiset päätepisteet tarjoavat paremman eristyksen, ja niitä voidaan käyttää myös paikallisverkosta VPN:n tai ExpressRouten kautta. Yksityisiä päätepisteitä suositellaan parhaan tietoturvan saavuttamiseksi, kun taas palvelun päätepisteet ovat yksinkertaisempi ja edullisempi vaihtoehto.

Kun olet ottanut palvelun päätepisteen käyttöön aliverkossa, määrität Azure-palvelun hyväksymään yhteydet vain kyseisestä aliverkosta. Tallennustilin tapauksessa tämä tarkoittaa VNet-säännön lisäämistä tallennustilin palomuuriasetuksiin. Tämän muutoksen jälkeen vain määritetyn aliverkon virtuaalikoneet voivat käyttää tallennustiliä, ja kaikki muu internet-liikenne estetään. Tämä on nopea ja maksuton tapa parantaa tallennustilin tietoturvaa merkittävästi verrattuna siihen, että tili olisi avoin kaikelle internet-liikenteelle. Se on erityisen hyödyllistä tileille, joissa säilytetään arkaluonteisia sovellustietoja.

VNet-integraation (joka on eri asia kuin VNet-peering) avulla Azure App Service -sovellukset voivat tehdä lähteviä yhteyksiä VNet-verkon sisäisiin resursseihin. Ilman VNet-integraatiota App Servicen lähtevä liikenne kulkee aina julkisen internetin kautta, vaikka yhteyden kohteena olisi samassa VNet-verkossa oleva resurssi, kuten Azure SQL tai Azure Cache for Redis. Kun VNet-integraatio on käytössä, sovelluksen lähtevä liikenne reititetään VNet-verkkoon, ja se voi käyttää yksityisiä resursseja. Tämä edellyttää VNet-verkkoon varattua delegoitua aliverkkoa, jonka osoiteavaruus on vähintään /28.

Koska VNet-peering ei ole transitiivinen, useamman kuin kahden VNet-verkon yhdistäminen edellyttää joko suoraa peering-yhteyttä jokaisen parin välillä (O(n²)-kompleksisuus) tai keskitettyä reitityshubia. Hub-and-spoke-mallissa hub-VNet sisältää Network Virtual Appliance (NVA) -laitteen tai Azure Firewallin, joka toimii spoke-verkkojen välisenä siirtymäreitittimenä. Jokaiseen spoke-verkkoon lisätään UDR, joka osoittaa kaiken liikenteen (0.0.0.0/0 tai tiettyihin spoke-verkkojen CIDR-alueisiin suuntautuvan liikenteen) hubissa sijaitsevan NVA:n IP-osoitteeseen. NVA välittää liikenteen oikeaan kohdeverkkoon, mikä mahdollistaa käytännössä transitiivisen yhteyden hubin kautta.

VNet-peeringin tärkeimmät rajoitukset: Osoiteavaruudet eivät saa olla päällekkäisiä — suunnittele CIDR-alueet huolellisesti ennen VNet-verkkojen luomista. Peering ei ole transitiivinen — A:n ja B:n sekä B:n ja C:n välinen peering ei yhdistä A:ta ja C:tä. VNet-verkon osoiteavaruutta ei voi muuttaa, jos verkossa on aktiivisia peering-yhteyksiä, ilman että ne poistetaan väliaikaisesti. Yhdyskäytävän siirto — spoke-VNet-verkot voivat käyttää hub-VNet-verkon VPN- tai ExpressRoute-yhdyskäytävää ottamalla peering-määrityksessä käyttöön asetuksen 'Use Remote Gateways', mutta tämä edellyttää, että hub-yhdyskäytävä luodaan ensin. Näiden rajoitusten ymmärtäminen on tärkeää skaalautuvien ja ylläpidettävien usean VNet-verkon arkkitehtuurien suunnittelussa.

Tässä oppitunnissa opit, että VNet-peering yhdistää kaksi VNet-verkkoa Microsoftin runkoverkon kautta yksityistä ja pienen viiveen viestintää varten ilman VPN:ää, mutta peering ei ole transitiivinen, palvelun päätepisteet reitittävät aliverkon liikenteen Azure PaaS -palveluihin runkoverkon kautta ilman, että palvelu altistuu julkiselle internetille ja yksityiset päätepisteet ovat tehokkaampi vaihtoehto, joka määrittää PaaS-palvelulle yksityisen IP-osoitteen ja mahdollistaa julkisen päätepisteen poistamisen kokonaan käytöstä. Seuraavaksi tutustumme Azure DNS:n ja Load Balancerin perusteisiin.