Kaksi paikallista VPN-osoitetta: kaksi Azure-vertaiskonetta, ei yksi
Toinen paikallinen VPN-osoite on toinen vertaiskone, ei toinen kenttäarvo. Yksi paikallisen verkon yhdyskäytävä ja yksi yhteys laitetta kohti, sitten laske tunnelit.
Kaaviossa on kaksi internet-linkkiä sivukonttorissa ja yksi Azure VPN -yhdyskäytävä, joten paikallisen verkon yhdyskäytävä saa molemmat julkiset osoitteet. Se näyttää siistiltä eikä toimi niin kuin kaavio antaa ymmärtää. Jokainen paikallinen VPN-laite on erillinen vertaissuhde, ja Microsoftin monilaitesuunnittelu antaa kullekin oman paikallisen verkon yhdyskäytäväresurssin ja oman yhteyden. Toisen osoitteen lisääminen yhteen resurssiin ei luo toista vertaiskonetta. Se luo resurssin, joka ei kuvaa kumpaakaan laitetta oikein.
Myytti: yksi yhdyskäytävä, kaksi osoitetta
Paikallisen verkon yhdyskäytävä on kuvaus etävertaiskoneesta: yksi julkinen päätepiste ja sen takana olevat yksityiset etuliitteet. Ei ole tuettua tapaa saada resurssi tarkoittamaan »jompaa kumpaa näistä kahdesta laitteesta«.
Sama sekaannus näkyy toiseen suuntaan, jossa kaksi julkista Azure-IP:tä tulkitaan todisteeksi kahdesta Azure-yhdyskäytävästä.
Laske objektit ja sitten tunnelit
Ota kaksi itsenäisesti ylläpidettyä paikallista laitetta, kummallakin oma julkinen osoite ja pääsy samoihin yksityisiin verkkoihin, sekä yksi reititykseen perustuva Azure-yhdyskäytävä aktiivinen-aktiivinen-tilassa. Azure-yhdyskäytävällä on kaksi aktiivista instanssia erillisillä julkisilla IP-osoitteilla. Jokainen paikallinen laite yhdistää molempiin instansseihin. Se on täysi verkko, ja objektien määrä seuraa siitä, ei kaaviosta.
Aritmetiikka on tarpeeksi lyhyt liitettäväksi suunnitteluasiakirjaan:
2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh
Yksi yhteysresurssi voi kantaa useampaa kuin yhtä taustalla olevaa tunnelia, joten neljä tunnelia ei tarkoita neljää virtuaaliverkon yhdyskäytävää. Kaksi julkista Azure-IP:tä eivät myöskään ole samat objektit kuin kaksi paikallisen verkon yhdyskäytävää, jotka kuvaavat etäsivustoa.
Mitä aktiivinen-aktiivinen lisää Azure-puolella
Aktiivinen-aktiivinen muuttaa Azure-yhdyskäytävän yhdestä aktiivisesta instanssista kahdeksi, kummallakin oma julkinen IP, ja juuri se tekee täyden verkon ylipäätään mahdolliseksi. Se ei kaksinkertaista yhden virtauksen läpimenoa. Se ei myöskään poista tarvetta tukea paikallisella puolella samanhintaista monipolkua, jos molemmat laitteet välittävät samanaikaisesti. Vahvista yhdyskäytävän tila, SKU ja etälaitteen kyvyt ennen kuin varaat mitään.
Passiivisessa valmiustilassa oleva yhdyskäytävä on täysin kelvollinen suunnittelu; se tuottaa vain erilaisen tunnelimäärän.
BGP tekee molemmista poluista käyttökelpoisia
Monilaitesuunnittelussa molemmat paikalliset laitteet ajavat BGP:tä. Anna kummallekin yksilöllinen BGP-vertaisosoite ja mainosta samoja aiottuja yksityisiä etuliitteitä asiaankuuluvilla poluilla. Yksityiset etuliitteet yksilöivät suojatut verkot, kun taas julkiset osoitteet yksilöivät, mihin salatut kantoaaltoyhteydet päättyvät. Näiden kahden sekoittaminen tuottaa suunnittelun, jossa jokainen tunneli on ylhäällä ja reitit ovat väärin.
Suunnittele paluureititys ja kaikki tilallinen tarkastus, jonka on kestettävä kumpi tahansa polku. Terve IKE-istunto jokaisessa päätepisteessä ei todista, että työkuorma voi käyttää jokaista mainostettua reittiä.
Virtausperusteinen valinta ei ole kaistanleveyden yhdistämistä
Azure valitsee polun virtausta kohden käyttämällä hajautusta virtauksen osoitteiden ja porttien yli. Vakaassa tilassa tietyn TCP- tai UDP-virtauksen paketit kulkevat yleensä samaa tunnelia, ja paikallinen puoli voi valita paluusuunnalle toisen tunnelin. Siksi kaksi laitetta ja neljä tunnelia parantavat käytettävyyttä, eivät yhden siirron nopeutta. Kun toimittajan dia esittää yhdistämistä, se kuvaa toista ominaisuutta tai väärinkäsitystä.
Testaa rinnakkaisilla virtauksilla, jos haluat nähdä polkujen jakautuvan, ja yhdellä virtauksella, jos haluat nähdä rajan.
Minkä redundanssin todella poistit
Kaksi WAN-osoitetta yhdessä laitteessa parantaa liityntälinkin vaihtoehtoja mutta jakaa kyseisen laitteen virran, ohjelmiston ja vikatilan. Ne eivät ole sama asia kuin kaksi laitetta, eikä mikään Azure-puolen kokoonpano muuta sitä. Noudata toimittajan tukemaa kahden WAN:n tai klusterin suunnittelua sen sijaan, että päättelet redundanssin osoitteiden määrästä. Testaa sitten: poista yksi polku kerrallaan ja vahvista jäljellä olevat reitit sekä todellinen sovellusvaihto molempiin suuntiin.
Odota tunnistus- ja konvergenssiviiveitä ja odota joidenkin olemassa olevien istuntojen päättyvän.