ExpressRoute plus VPN: ce domenii de eșec acoperiți?

Un tunel IPsec care rulează peste peeringul privat ExpressRoute adaugă criptare unui transport care există deja. Un al doilea tunel îmbunătățește disponibilitatea punctului final și nu face absolut nimic pentru calea operatorului de sub ambele. Această distincție se pierde ușor când tablourile de bord arată două tuneluri verzi, iar revizia de proiectare pune o altă întrebare: ce eșecuri trebuie să supraviețuiască această conexiune? Răspundeți mai întâi la asta, apoi numărați tunelurile, pentru că numărul indicatorilor verzi este o proprietate a stratului de criptare, iar numărul domeniilor de eșec este o proprietate a întregii căi.

Începeți cu eșecurile, nu cu tunelurile verzi

Scrieți patru rânduri înainte de a desena ceva: un punct final VPN sau o instanță peer care cade, un router local sau o conexiune de primul mile care cade, calea partajată ExpressRoute care cade și IPsec care devine indisponibil în timp ce peeringul privat încă transportă trafic. Fiecare rând numește ce trebuie să păstreze proiectarea, iar la fiecare răspunde un mecanism diferit.

Microsoft documentează VPN site-to-site cu IP-uri private peste peeringul privat ExpressRoute și coexistența acceptată cu conexiuni site-to-site bazate pe internet. Acea coexistență este un alt proiect al stratului inferior și nu apare doar pentru că ați adăugat încă un punct final de tunel privat.

Domeniul de eșec 1: punctul final VPN

Două tuneluri pe un singur gateway sunt de obicei perechi active-active care se termină pe aceeași resursă din partea Azure. Ele protejează împotriva unei probleme a unui singur tunel sau a unei singure instanțe și nu protejează împotriva faptului că resursa devine indisponibilă, este reconfigurată sau rămâne fără capacitate. Redundanța punctului final înseamnă un al doilea punct final acceptat, cu propria cale și propria configurație, plus o rută care poate ajunge la el.

Verificați ce ați implementat de fapt, nu ce spune diagrama, pentru că portalul grupează aceste resurse în moduri care le ascund relația:

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}'

Dacă ambele tuneluri indică un singur gateway cu o singură adresă IP publică, aveți o redundanță a punctului final de un tip anume și limitat. Poate fi exact ceea ce cere cerința, și ar trebui spus astfel în loc să fie descris ca o conexiune redundantă.

Domeniul de eșec 2: calea locală și operatorul

Sub criptare se află o realitate fizică și comercială: un echipament de margine al clientului, o interconectare, o rețea de furnizor și o locație de peering. îndrumările privind disponibilitatea ExpressRoute sunt explicite că redundanța de la un capăt la altul include segmentele clientului și ale furnizorului de servicii, nu doar partea Microsoft. Două căi logice care împart un router, o sursă de alimentare sau o conexiune de primul mile împart în continuare acea dependență.

Aici o proiectare pică de obicei la o revizuire onestă. Două circuite de la același furnizor, care se termină în aceeași clădire, pe echipamente din aceeași comandă, nu sunt două domenii de eșec. Sunt un singur domeniu de eșec cu două facturi.

Puneți întrebarea operatorului în scris: care dintre aceste căi diverg, unde și care este comportamentul documentat când segmentul partajat cade? O asigurare verbală în timpul unui apel de proiectare nu supraviețuiește căderii pentru care proiectați.

Domeniul de eșec 3: ruta care supraviețuiește fără IPsec

Peeringul privat și IPsec pot oferi rute concurente către același prefix de aplicație. Dacă ruta protejată dispare, o rută directă ExpressRoute supraviețuitoare poate fi încă utilizabilă, fără stratul de criptare pe care îl oferea tunelul. Dacă acest lucru este acceptabil este o decizie de politică și este decizia lăsată cel mai des implicită.

Cerințele de criptare și cerințele de disponibilitate pot intra aici în conflict real. „Orice rută supraviețuitoare contează ca succes” este o afirmație despre disponibilitate care răspunde în șoaptă „nu” la întrebarea despre criptare. Notați care câștigă, pentru ce prefixe și cine a aprobat.

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 table

Comparați rutele învățate cu prefixele pe care le așteptați. O cale alternativă care transportă o sarcină administrativă mică poate fi perfect adecvată pentru acea sarcină și departe de capacitatea de care are nevoie cererea de producție, așa că notați ipoteza de capacitate lângă rută.

Notați trei rânduri separate, nu un singur verdict

Păstrați redundanța punctului final, redundanța transportului și recuperarea după dezastru ca intrări separate în registrul de proiectare, fiecare cu mecanismul, verificarea și proprietarul său. Când o revizuire de incident întreabă de ce conexiunea a supraviețuit unei reporniri a gateway-ului, dar nu unei tăieri de fibră, trei rânduri răspund într-o singură propoziție; o singură bifă „redundant” nu poate.

Apoi testați rândurile pe care le puteți testa ieftin. Faceți un tunel să cadă și confirmați că traficul se mută și se recriptează. Retrageți o rută și confirmați că calea supraviețuitoare este cea dorită, apoi confirmați dacă este încă criptată. Documentați eșecurile pe care nu le-ați putut simula, pentru că un rând netestat este o presupunere și ar trebui etichetat ca atare.

Rezultatul util este un tabel scurt plus o propoziție pe rând. Dacă un rând nu are mecanism, aceasta este constatarea, și este mult mai ieftin să o descoperiți într-o revizuire de proiectare decât în timpul unei căderi a operatorului pe care niciunul dintre cele două tuneluri nu ar fi supraviețuit-o.