ExpressRoute ja VPN: mitkä vikavyöhykkeet katat?
Toinen IPsec-tunneli kattaa päätepisteen, ei sen alla olevaa piiriä. Kartoita jokainen vikavyöhyke ja päätä sitten, sallitaanko salaamaton varareitti.
ExpressRouten yksityisen peeringin yli kulkeva IPsec-tunneli lisää salauksen siirtoyhteyteen, joka on jo olemassa. Toinen tunneli parantaa päätepisteen käytettävyyttä eikä tee kummankaan alla olevan operaattorin reitille yhtään mitään. Tämä ero on helppo menettää, kun kojelaudat näyttävät kahta vihreää tunnelia ja suunnittelukatselmus esittää toisen kysymyksen: mitkä viat tämän yhteyden on kestettävä? Vastaa siihen ensin ja laske sitten tunnelit, koska vihreiden ilmaisimien määrä on salauskerroksen ominaisuus ja vikavyöhykkeiden määrä on koko reitin ominaisuus.
Aloita vioista, älä vihreistä tunneleista
Kirjoita neljä riviä ennen kuin piirrät mitään: yhden VPN-päätepisteen tai peer-instanssin vika, yhden paikallisen reitittimen tai ensimmäisen mailin yhteyden vika, jaetun ExpressRoute-reitin vika ja IPsecin käyttökelvottomuus, kun yksityinen peering kuljettaa yhä liikennettä. Jokainen rivi nimeää, mitä suunnittelun on säilytettävä, ja jokaiseen vastaa eri mekanismi.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft dokumentoi yksityisen IP:n site-to-site-VPN:n ExpressRouten yksityisen peeringin yli ja tuetun rinnakkaiselon internetpohjaisten site-to-site-yhteyksien kanssa. Tämä rinnakkaiselo on erilainen alakerroksen suunnittelu, eikä se ilmesty vain siksi, että lisäsit toisen yksityisen tunnelin päätepisteen.
Vikavyöhyke 1: VPN-päätepiste
Kaksi tunnelia yhdellä yhdyskäytävällä on yleensä active-active-pareja, jotka päättyvät samaan Azure-puolen resurssiin. Ne suojaavat yhden tunnelin tai instanssin ongelmalta eivätkä suojaa siltä, että resurssi tulee käyttökelvottomaksi, määritetään uudelleen tai loppuu kapasiteetilta. Päätepisteen redundanssi tarkoittaa toista tuettua päätepistettä, jolla on oma reitti ja oma kokoonpano, sekä reittiä, joka voi tavoittaa sen.
Tarkista, mitä todella otit käyttöön, älä sitä mitä kaavio sanoo, sillä portaali ryhmittelee nämä resurssit tavoilla, jotka kätkevät niiden suhteen:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'Jos molemmat tunnelit osoittavat yhteen yhdyskäytävään, jolla on yksi julkinen IP, sinulla on tietyn ja rajoitetun tyyppistä päätepisteen redundanssia. Se voi olla täsmälleen se, mitä vaatimus pyytää, ja se pitäisi ilmaista niin sen sijaan, että sitä kuvattaisiin redundanttina yhteytenä.
Vikavyöhyke 2: paikallinen reitti ja operaattori
Salauksen alla on fyysinen ja kaupallinen todellisuus: asiakkaan reunalaite, ristikytkentä, palveluntarjoajan verkko ja peering-sijainti. ExpressRouten käytettävyysohjeet sanovat selvästi, että päästä päähän -redundanssi kattaa asiakkaan ja palveluntarjoajan segmentit, ei vain Microsoftin puolta. Kaksi loogista reittiä, jotka jakavat reitittimen, virransyötön tai ensimmäisen mailin yhteyden, jakavat yhä tämän riippuvuuden.
Tässä suunnittelu yleensä epäonnistuu rehellisessä katselmuksessa. Kaksi piiriä samalta palveluntarjoajalta, jotka päättyvät samaan rakennukseen, saman tilauksen laitteilla, eivät ole kaksi vikavyöhykettä. Ne ovat yksi vikavyöhyke ja kaksi laskua.
Kysy operaattorilta kirjallisesti: mitkä näistä reiteistä eriytyvät, missä, ja mikä on dokumentoitu käyttäytyminen, kun jaettu segmentti pettää? Suunnittelupuhelun aikana annettu suullinen vakuutus ei kestä sitä katkosta, jota varten suunnittelet.
Vikavyöhyke 3: reitti, joka säilyy ilman IPseciä
Yksityinen peering ja IPsec voivat tarjota kilpailevia reittejä samaan sovellusetuliitteeseen. Jos suojattu reitti katoaa, jäljelle jäävä suora ExpressRoute-reitti voi olla yhä käyttökelpoinen, ilman sitä salauskerrosta, jonka tunneli tarjosi. Onko se hyväksyttävää, on politiikan päätös, ja se on päätös, joka useimmin jätetään implisiittiseksi.
Salausvaatimukset ja käytettävyysvaatimukset voivat todella törmätä tässä. «Mikä tahansa säilyvä reitti lasketaan menestykseksi» on käytettävyysväite, joka vastaa hiljaa salauskysymykseen «ei». Kirjoita, kumpi voittaa, mille etuliitteille ja kuka sen hyväksyi.
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableVertaa opittuja reittejä odotettuihin etuliitteisiin. Pientä hallinnollista kuormaa kantava varareitti voi olla täysin riittävä sille kuormalle ja kaukana siitä kapasiteetista, jota tuotantokysyntä tarvitsee, joten kirjaa kapasiteettioletus reitin viereen.
Kirjaa kolme erillistä riviä, ei yhtä tuomiota
Pidä päätepisteen redundanssi, siirtoyhteyden redundanssi ja katastrofista palautuminen erillisinä merkintöinä suunnittelutietueessa, kullakin oma mekanismi, oma varmistus ja oma omistaja. Kun häiriökatselmus kysyy, miksi yhteys kesti yhdyskäytävän uudelleenkäynnistyksen mutta ei kuidun katkeamista, kolme riviä vastaa yhdellä lauseella; yksi «redundantti»-valintaruutu ei pysty siihen.
Testaa sitten rivit, jotka voit testata halvalla. Kaada yksi tunneli ja varmista, että liikenne siirtyy ja salataan uudelleen. Vedä yksi reitti pois ja varmista, että säilyvä reitti on se, jonka tarkoitit, ja varmista sitten, onko se yhä salattu. Dokumentoi viat, joita et voinut simuloida, koska testaamaton rivi on oletus ja se pitäisi merkitä sellaiseksi.
Hyödyllinen tulos on lyhyt taulukko ja yksi lause riviä kohden. Jos rivillä ei ole mekanismia, se on löydös, ja se on paljon halvempaa havaita suunnittelukatselmuksessa kuin operaattorin katkoksen aikana, jota kumpikaan tunneli ei olisi koskaan kestänyt.