ExpressRoute plus VPN: vilka feldomaner täcker du?
En andra IPsec-tunnel täcker en slutpunkt, inte kretsen under den. Kartlägg varje feldoman och avgör sedan om en okrypterad reservväg är tillåten.
En IPsec-tunnel som körs över ExpressRoutes privata peering lägger till kryptering på en transport som redan finns. En andra tunnel förbättrar slutpunktens tillgänglighet och gör absolut ingenting för operatörens väg under båda. Den skillnaden är lätt att tappa när instrumentpanelerna visar två gröna tunnlar och designgranskningen ställer en annan fråga: vilka fel måste den här förbindelsen överleva? Svara på det först och räkna sedan tunnlar, eftersom antalet gröna indikatorer är en egenskap hos krypteringslagret och antalet feldomaner är en egenskap hos hela vägen.
Börja med fel, inte med gröna tunnlar
Skriv fyra rader innan du ritar något: en VPN-slutpunkt eller peer-instans som fallerar, en lokal router eller first-mile-anslutning som fallerar, den delade ExpressRoute-vägen som fallerar och IPsec som blir otillgängligt medan privat peering fortfarande bär trafik. Varje rad namnger vad designen måste bevara, och var och en besvaras av en annan mekanism.
| 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 dokumenterar site-to-site-VPN med privata IP-adresser över ExpressRoutes privata peering och den stödda samexistensen med internetbaserade site-to-site-anslutningar. Den samexistensen är en annan underliggande design, och den uppstår inte bara för att du lade till ännu en privat tunnelslutpunkt.
Feldoman 1: VPN-slutpunkten
Två tunnlar på en gateway är oftast active-active-par som terminerar på samma resurs på Azure-sidan. De skyddar mot ett problem med en enskild tunnel eller instans och skyddar inte mot att resursen blir otillgänglig, omkonfigureras eller tar slut på kapacitet. Slutpunktsredundans betyder en andra stödd slutpunkt, med egen väg och egen konfiguration, plus en rutt som kan nå den.
Kontrollera vad du faktiskt har driftsatt och inte vad diagrammet säger, eftersom portalen grupperar dessa resurser på sätt som döljer deras relation:
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}'Om båda tunnlarna pekar på en gateway med en offentlig IP har du slutpunktsredundans av ett bestämt och begränsat slag. Det kan vara precis vad kravet ber om, och det bör sägas så i stället för att beskrivas som en redundant förbindelse.
Feldoman 2: den lokala vägen och operatören
Under krypteringen ligger en fysisk och kommersiell verklighet: en kundkantsenhet, en korskoppling, ett leverantörsnät och en peering-plats. riktlinjerna för ExpressRoute-tillgänglighet är tydliga med att redundans från ände till ände omfattar kundens och tjänsteleverantörens segment, inte bara Microsoft-sidan. Två logiska vägar som delar en router, en strömförsörjning eller en first-mile-anslutning delar fortfarande det beroendet.
Det är här en design oftast underkänns i en ärlig granskning. Två kretsar från samma leverantör, som terminerar i samma byggnad, på utrustning från samma inköpsorder, är inte två feldomaner. De är en feldoman med två fakturor.
Ställ operatörsfrågan skriftligt: vilka av dessa vägar divergerar, var, och vad är det dokumenterade beteendet när det delade segmentet fallerar? En muntlig försäkran under ett designsamtal överlever inte det avbrott du designar för.
Feldoman 3: rutten som överlever utan IPsec
Privat peering och IPsec kan erbjuda konkurrerande rutter till samma applikationsprefix. Om den skyddade rutten försvinner kan en överlevande direkt ExpressRoute-rutt fortfarande vara användbar, utan det krypteringslager som tunneln gav. Om det är acceptabelt är ett policybeslut, och det är det beslut som oftast lämnas implicit.
Krypteringskrav och tillgänglighetskrav kan här verkligen kollidera. ”Varje överlevande rutt räknas som framgång” är ett tillgänglighetspåstående som tyst besvarar krypteringsfrågan med ”nej”. Skriv ned vilket som vinner, för vilka prefix och vem som godkände det.
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 tableJämför de lärda rutterna med de prefix du förväntade dig. En reservväg som bär en liten administrativ belastning kan vara helt tillräcklig för den belastningen och långt ifrån den kapacitet produktionsbehovet kräver, så notera kapacitetsantagandet bredvid rutten.
Notera tre separata rader, inte en enda dom
Håll slutpunktsredundans, transportredundans och katastrofåterställning som separata poster i designregistret, var och en med egen mekanism, egen verifiering och egen ägare. När en incidentgranskning frågar varför förbindelsen överlevde en gateway-omstart men inte ett fiberbrott, svarar tre rader i en enda mening; en enda ”redundant”-kryssruta kan inte.
Testa sedan de rader du kan testa billigt. Låt en tunnel fallera och bekräfta att trafiken flyttar och krypteras om. Dra tillbaka en rutt och bekräfta att den överlevande vägen är den du avsåg, och bekräfta sedan om den fortfarande är krypterad. Dokumentera de fel du inte kunde simulera, eftersom en otestad rad är ett antagande och bör märkas som det.
Det användbara resultatet är en kort tabell plus en mening per rad. Om en rad inte har någon mekanism är det fyndet, och det är mycket billigare att upptäcka i en designgranskning än under ett operatörsavbrott som ingen av de två tunnlarna någonsin hade överlevt.