ExpressRoute plus VPN: które domeny awarii obejmujesz?

Tunel IPsec działający przez prywatny peering ExpressRoute dodaje szyfrowanie do transportu, który już istnieje. Drugi tunel poprawia dostępność punktu końcowego i nie robi absolutnie nic dla ścieżki operatora pod oboma. Tę różnicę łatwo zgubić, gdy pulpity pokazują dwa zielone tunele, a przegląd projektu zadaje inne pytanie: które awarie musi przetrwać to połączenie? Najpierw odpowiedz na to, a potem licz tunele, bo liczba zielonych wskaźników jest właściwością warstwy szyfrowania, a liczba domen awarii właściwością całej ścieżki.

Zacznij od awarii, nie od zielonych tuneli

Napisz cztery wiersze, zanim cokolwiek narysujesz: awaria jednego punktu końcowego VPN lub jednej instancji peera, awaria jednego lokalnego routera lub łącza pierwszej mili, awaria wspólnej ścieżki ExpressRoute oraz niedostępność IPsec, gdy prywatny peering nadal przenosi ruch. Każdy wiersz nazywa to, co projekt musi zachować, i każdemu odpowiada inny mechanizm.

Microsoft dokumentuje VPN typu lokacja-lokacja z prywatnymi adresami IP przez prywatny peering ExpressRoute oraz obsługiwaną koegzystencję z połączeniami lokacja-lokacja opartymi na internecie. Ta koegzystencja to inny projekt warstwy dolnej i nie pojawia się tylko dlatego, że dodano kolejny punkt końcowy prywatnego tunelu.

Domena awarii 1: punkt końcowy VPN

Dwa tunele na jednej bramie to zwykle pary active-active kończące się na tym samym zasobie po stronie Azure. Chronią przed problemem jednego tunelu lub jednej instancji, a nie chronią przed tym, że zasób stanie się niedostępny, zostanie przekonfigurowany albo zabraknie mu wydajności. Redundancja punktu końcowego oznacza drugi obsługiwany punkt końcowy, z własną ścieżką i własną konfiguracją, oraz trasę, która potrafi do niego dotrzeć.

Sprawdź, co faktycznie wdrożono, a nie co mówi diagram, ponieważ portal grupuje te zasoby w sposób, który ukrywa ich relację:

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

Jeśli oba tunele wskazują na jedną bramę z jednym publicznym adresem IP, masz redundancję punktu końcowego określonego i ograniczonego rodzaju. To może być dokładnie to, czego wymaga wymaganie, i tak należy to nazwać, zamiast opisywać jako połączenie redundantne.

Domena awarii 2: ścieżka lokalna i operator

Pod szyfrowaniem leży rzeczywistość fizyczna i handlowa: urządzenie brzegowe klienta, połączenie krzyżowe, sieć dostawcy i lokalizacja peeringu. wytyczne dotyczące dostępności ExpressRoute są jednoznaczne: redundancja od końca do końca obejmuje segmenty klienta i dostawcy usług, nie tylko stronę Microsoft. Dwie logiczne ścieżki, które dzielą router, zasilanie lub łącze pierwszej mili, nadal dzielą tę zależność.

Tu projekt zwykle nie przechodzi uczciwego przeglądu. Dwa obwody od tego samego dostawcy, kończące się w tym samym budynku, na sprzęcie z tego samego zamówienia, nie są dwiema domenami awarii. To jedna domena awarii z dwiema fakturami.

Zadaj pytanie operatorowi na piśmie: które z tych ścieżek się rozchodzą, gdzie, i jakie jest udokumentowane zachowanie, gdy wspólny segment zawiedzie? Ustne zapewnienie podczas rozmowy projektowej nie przetrwa awarii, dla której projektujesz.

Domena awarii 3: trasa, która przetrwa bez IPsec

Prywatny peering i IPsec mogą oferować konkurencyjne trasy do tego samego prefiksu aplikacji. Jeśli chroniona trasa zniknie, pozostała bezpośrednia trasa ExpressRoute może być nadal użyteczna, bez warstwy szyfrowania, którą zapewniał tunel. Czy to jest dopuszczalne, jest decyzją polityki, i właśnie ta decyzja najczęściej pozostaje domyślna.

Wymagania dotyczące szyfrowania i dostępności mogą się tu naprawdę zderzyć. „Każda pozostała trasa liczy się jako sukces” to stwierdzenie o dostępności, które po cichu odpowiada na pytanie o szyfrowanie „nie”. Zapisz, które wygrywa, dla których prefiksów i kto to zatwierdził.

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

Porównaj nauczone trasy z prefiksami, których oczekiwano. Ścieżka zapasowa przenosząca niewielkie obciążenie administracyjne może być dla niego w pełni wystarczająca i daleka od wydajności potrzebnej produkcji, więc zapisz założenie o wydajności obok trasy.

Zapisz trzy osobne wiersze, nie jeden werdykt

Utrzymuj redundancję punktu końcowego, redundancję transportu i odtwarzanie po katastrofie jako osobne wpisy w rejestrze projektu, każdy z własnym mechanizmem, własną weryfikacją i własnym właścicielem. Gdy przegląd incydentu pyta, dlaczego połączenie przetrwało restart bramy, ale nie przecięcie światłowodu, trzy wiersze odpowiadają jednym zdaniem; jedno pole „redundantne” nie potrafi.

Następnie przetestuj wiersze, które można przetestować tanio. Wyłącz jeden tunel i potwierdź, że ruch się przenosi i jest ponownie szyfrowany. Wycofaj jedną trasę i potwierdź, że pozostała ścieżka jest tą zamierzoną, a potem potwierdź, czy nadal jest szyfrowana. Udokumentuj awarie, których nie udało się zasymulować, ponieważ nieprzetestowany wiersz jest założeniem i powinien być tak oznaczony.

Użytecznym wynikiem jest krótka tabela plus jedno zdanie na wiersz. Jeśli wiersz nie ma mechanizmu, to jest ustalenie, i znacznie taniej jest odkryć je w przeglądzie projektu niż podczas awarii operatora, której żaden z dwóch tuneli nigdy by nie przetrwał.