Inspekcja NVA w Azure: dlaczego odpowiedź przechodzi przez inną zaporę

Przepływ z oddziału do Azure może być poprawnie routowany w obu kierunkach i nadal zawodzić, ponieważ oba kierunki przechodzą przez różne urządzenia. Żądanie opuszcza oddział przez VPN, ląduje na NVA A i dociera do obciążenia. Odpowiedź opuszcza obciążenie, pasuje do trasy wskazującej na NVA B i ginie tam. Każda trasa na tym obrazku jest poprawna, a sesja TCP nadal jest zerwana.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Ta luka jest tu całym tematem: zbieżność routingu i własność stanu sesji to różne problemy, które na diagramie wyglądają identycznie.

Co Route Server faktycznie programuje

Azure Route Server nawiązuje peering z obsługiwanymi mówcami BGP, uczy się ich tras i programuje je w efektywnych trasach sieci wirtualnej. To zadanie płaszczyzny sterowania. Nie czyta tablicy sesji zapory producenta i nie wie, które urządzenie dopuściło dane połączenie. Dwa następne skoki o równym koszcie to dla tej tkaniny po prostu dwa sposoby dotarcia do tego samego prefiksu i użyje dowolnego z nich.

Nauka trasy dowodzi więc osiągalności. Nie dowodzi niczego o tym, czy urządzenie po drugiej stronie widziało już ten przepływ.

Przeczytaj oba kierunki, zanim zaprojektujesz

Zacznij od zapisania sterowania, które naprawdę masz w każdym kierunku, a nie tego, które zamierzałeś. Bardziej szczegółowe trasy BGP, trasy zdefiniowane przez użytkownika i zachowanie bramy konkurują ze sobą, a zwycięzca jest ustalany dla celu, nie dla sesji. Trasa domyślna na NVA nie oznacza, że każdy prywatny prefiks przez nią przechodzi.

Przydatnym sprawdzeniem jest zapytanie, dla jednego konkretnego IP obciążenia, do którego następnego skoku rozwiązuje się każdy kierunek. Jeśli odpowiedź to dwa różne urządzenia, masz problem asymetrii, niezależnie od tego, czy już się ujawnił.

Gdzie mieszka stan

Zapora stanowa przyjmuje połączenie i trzyma wpis tablicy z kluczem piątki. Odpowiedź musi dotrzeć do urządzenia, które trzyma ten wpis, albo to urządzenie musi uzyskać stan w inny sposób. Nic w płaszczyźnie danych Azure nie przekazuje wpisu między urządzeniami. Albo ruch jest kierowany z powrotem do właściciela, albo urządzenia współdzielą stan przez mechanizm producenta, albo projekt nie działa.

Dlatego dwie zdrowe NVA nie są kontrolą zdrowia dla inspekcji. Zdrowie dotyczy osiągalności; inspekcja dotyczy tego, która instancja trzyma sesję.

Obsługiwane modele HA i co każdy obiecuje

Microsoft's guidance on intencji routingu Virtual WAN opisują ograniczone zachowanie dla łączności o podwójnej roli i NVA zapór, gdzie routing bezpośredni może omijać normalne symetryczne egzekwowanie koncentratora. Czytaj te uwagi jako ograniczenia wybranej topologii, nie jako zakaz projektów aktywnych-aktywnych. Para producenta, która synchronizuje stan lub kieruje na przepływ, może być obsługiwana. Para o równym koszcie, która nie robi żadnego z nich, nie jest.

Następnie zdefiniuj, co dzieje się z istniejącymi sesjami, gdy węzeł zawiedzie. Zbieżność tras przywraca osiągalność dla nowych przepływów w kilka sekund, podczas gdy stary stan zapory po prostu znika. Ponowne połączenie klienta może być udokumentowanym wynikiem, a to decyzja podejmowana przed incydentem, nie w jego trakcie.

Co przetestować, zanim jej zaufasz

Test with inspection enabled and polityką dostępu obciążenia na miejscu, ponieważ każde z nich może ukryć asymetrię. Wyślij nowy autoryzowany przepływ w obu kierunkach i potwierdź, że to samo urządzenie widziało obie połowy. Następnie uruchom stały ruch i wywołaj zatwierdzone przełączenie, obserwując, czy istniejące sesje przetrwają, czy połączą się ponownie.

Koreluj każdy przepływ z urządzeniem, które go obsłużyło. Przechwycenie pakietów na jednej NVA mówi prawie nic, jeśli odpowiedź nigdy do niej nie wróciła.

Na koniec zapisz plan jako trzy osobne wiersze: własność tras, sterowanie ruchem i własność stanu sesji. Projekty psują się, gdy pierwsze dwa są rozwiązane, a trzeci zakładany.