Tarvitseeko peeringillä yhdistetty Azure VNet oman VPN-yhdyskäytävän?

Uusi spoke-VNet ilmestyy, hubissa on jo toimiva site-to-site-yhdyskäytävä, ja ilmeinen kysymys on, täytyykö toisesta yhdyskäytävästä maksaa. Yleensä ei: yhdyskäytävän transit antaa spoke’lle luvan käyttää hubin yhdyskäytävää peeringin yli. Kolme ehtoa ratkaisee, toimiiko se, eikä yhtäkään niistä näy peeringin tilamerkissä. Peering-yhteys ja lupa käyttää jonkun toisen yhdyskäytävää ovat erillisiä asetuksia, joten kaksi VM:ää, jotka jo pingaavat toisiaan, eivät todista VPN-polusta mitään.

Ensimmäinen ehto: yhdyskäytävä ja spoke’n puute sellaisesta

Azure tukee yhdyskäytävän transiittia muille kuin Basic-tason VPN Gateway -SKU:ille, ja sekä alueellinen että maailmanlaajuinen peering voivat kantaa sitä. Spoke kuluttaa yhdyskäytävää, jota se ei omista, joten sillä ei voi olla omaansa: jos spokessa on jo yhdyskäytävä tai etäyhdyskäytävä-vaihtoehto on jo valittu, haluamasi transiittiasetus on joko poissa käytöstä tai tehoton. Tarkista tämä ennen kuin alat selvittää mitään, sillä pois käytöstä oleva valintaruutu on oire, ei vika. Lue ensin SKU ja olemassa oleva yhdyskäytävä ja katso sitten peering-asetuksia.

Älä poista olemassa olevaa spoken yhdyskäytävää saadaksesi vaihtoehdon näkyviin ennen kuin tiedät, mitä siitä riippuu. Siirtojärjestys on tärkeämpi kuin valintaruutu.

Toinen ehto: yksi asetus kussakin peeringin suunnassa

Peering on kaksi objektia, yksi kummassakin VNetissä, ja transiittiasetukset sijaitsevat tuon parin eri puolilla. Hubin peering spokee kohti on sallittava hubin yhdyskäytävän palvella spokee; spoken peering hubia kohti on hyväksyttävä hubin yhdyskäytävä. Microsoftin yhdyskäytävän transiittiopas nimeää ne suunnittain, ja se on ainoa tapa pitää ne oikein:

remote-merkinnällä varustettu komponentti muuttaa merkitystään sen mukaan, minkä VNetin peeringiä muokkaat, joten lue suuntaa, älä sanaa. Aseta molemmat puolet, tallenna ja vahvista, että peering ilmoittaa yhteydestä molemmissa paikoissa.

Kolmas ehto: osoiteavaruus ja käyttöoikeuksien rajat

Transit ei voi saada samaa kohdeprefixiä tarkoittamaan kahta verkkoa, joten hubin, spoken ja paikallisen verkon alueiden on oltava erillisiä ennen kuin mikään tästä toimii. VNetit voivat olla myös eri tilauksissa tai eri vuokralaisissa; se ei ole kielto, mutta identiteetillä, joka luo tai päivittää kunkin peeringin, on oltava tarvittavat käyttöoikeudet siihen verkkoon. Tilausten väliset muutokset epäonnistuvat usein käyttöoikeuksiin, ja virhe on helppo lukea väärin topologiaongelmaksi.

Kirjoita alueet ja omistajat muistiin ennen muutosta. Kummankin arvaaminen tuottaa peeringin, joka yhdistyy eikä reititä mitään.

Vahvista tehokkailla reiteillä, älä peeringin tilalla

Katso spoke-työkuorman verkkoliitännän tehokkaita reittejä ja etsi todellinen paikallisen verkon prefix. Tarkista aliverkon reititystaulu ja se, onko yhdyskäytävän reittien levitys poistettu käytöstä, koska käyttäjän määrittämä reitti tai tarkastuslaite voi ohittaa polun, jota peeringin liput ehdottavat. Vahvista sitten toinen suunta: paikallisen verkon on tiedettävä, miten spoken prefixiin päästään site-to-site-yhteyden kautta, joko opituilla ilmoituksilla tai eksplisiittisellä reitillä ja asiakaslaitteen vastaavalla suojatun verkon merkinnällä. Jos prefix puuttuu jommaltakummalta puolelta, peeringin liput eivät ole se, mitä pitää muuttaa.

Testaa yhtä palvelua spoke-työkuormasta ja seuraa vastausta. Testi VPN-yhdyskäytävästä tai hubin VM:stä käyttää eri lähdeprefixiä ja eri polkua.

Jos topologia palvelee myös point-to-site-asiakkaita, validoi heidän asennetut reittinsä erikseen. Windowsin asiakaspaketit voivat vaatia uudelleenluontia topologiamuutoksen jälkeen, ja se on asiakkaan reititystehtävä eikä todiste siitä, että yhdyskäytävän jakaminen epäonnistui.

Mitä yhdyskäytävän jakaminen ei myönnä

Yhdyskäytävän transit on reitityksen mukavuus, ei valtuutus. Verkon suojausryhmät, paikalliset suodattimet ja palvelutason säännöt päättävät edelleen, mihin spoke-työkuorma voi päästä, joten ota käyttöön tietty lähde-kohde-palvelu sen sijaan, että olettaisit jaetun tunnelin sallivan kaiken sen takana.

Peering ei myöskään ole transitiivinen niin kuin ihmiset toivovat. Toisen spoken tai yksityisen päätepisteen lisääminen tuo mukanaan omat reititys- ja käyttövaatimuksensa, joita nykyinen transiittiasetus ei kata.