Dwa lokalne adresy VPN: dwóch partnerów Azure, nie jeden

Diagram ma dwa łącza internetowe w oddziale i jedną bramę VPN Azure, więc brama sieci lokalnej otrzymuje oba publiczne adresy. Wygląda to schludnie i nie działa tak, jak sugeruje diagram. Każde lokalne urządzenie VPN to odrębna relacja partnerska, a projekt Microsoftu dla wielu urządzeń daje każdemu własny zasób bramy sieci lokalnej i własne połączenie. Dodanie drugiego adresu do jednego zasobu nie tworzy drugiego partnera. Tworzy zasób, który nie opisuje poprawnie żadnego z urządzeń.

Mit: jedna brama, dwa adresy

Brama sieci lokalnej to opis zdalnego partnera: jeden publiczny punkt końcowy i prywatne prefiksy za nim. Nie ma obsługiwanego sposobu, aby ten zasób oznaczał „którekolwiek z tych dwóch urządzeń”.

To samo zamieszanie występuje w drugą stronę, gdzie dwa publiczne adresy IP Azure są czytane jako dowód istnienia dwóch bram Azure.

Policz obiekty, potem tunele

Weź dwa niezależnie zarządzane urządzenia lokalne, każde z własnym publicznym adresem i dostępem do tych samych sieci prywatnych, plus jedną bramę Azure opartą na routingu w trybie aktywny-aktywny. Brama Azure ma dwie aktywne instancje z osobnymi publicznymi adresami IP. Każde urządzenie lokalne łączy się z obiema instancjami. To jest pełna siatka, a liczba obiektów wynika z niej, nie z diagramu.

Arytmetyka jest wystarczająco krótka, by wkleić ją do dokumentu projektowego:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Jeden zasób połączenia może przenosić więcej niż jeden tunel bazowy, więc cztery tunele nie oznaczają czterech bram sieci wirtualnej. Dwa publiczne adresy IP Azure również nie są tymi samymi obiektami co dwie bramy sieci lokalnej opisujące zdalną lokalizację.

Co dodaje tryb aktywny-aktywny po stronie Azure

Tryb aktywny-aktywny zmienia bramę Azure z jednej aktywnej instancji na dwie, każdą z własnym publicznym adresem IP, i to właśnie umożliwia pełną siatkę. Nie podwaja przepustowości jednego przepływu. Nie usuwa też potrzeby obsługi przez stronę lokalną wielościeżkowości o równym koszcie, jeśli oba urządzenia przekazują jednocześnie. Przed udostępnieniem czegokolwiek potwierdź tryb bramy, SKU i możliwości urządzenia zdalnego.

Brama w trybie pasywnego oczekiwania jest całkowicie poprawnym projektem; daje tylko inną liczbę tuneli.

BGP czyni obie ścieżki użytecznymi

W projekcie z wieloma urządzeniami oba urządzenia lokalne uruchamiają BGP. Nadaj każdemu unikalny adres partnera BGP i ogłaszaj te same zamierzone prywatne prefiksy na odpowiednich ścieżkach. Prywatne prefiksy identyfikują chronione sieci, a publiczne adresy identyfikują, gdzie kończą się szyfrowane połączenia nośne. Pomieszanie tych dwóch daje projekt, w którym każdy tunel jest aktywny, a trasy są błędne.

Zaplanuj routing powrotny i każdą kontrolę stanową, która musi tolerować dowolną z obu ścieżek. Zdrowa sesja IKE w każdym punkcie końcowym nie dowodzi, że obciążenie może użyć każdej ogłoszonej trasy.

Wybór oparty na przepływie nie jest łączeniem przepustowości

Azure wybiera ścieżkę na przepływ, używając skrótu (hash) po adresacji i portach przepływu. W stanie ustalonym pakiety danego przepływu TCP lub UDP zwykle idą tym samym tunelem, a strona lokalna może wybrać inny tunel dla kierunku powrotnego. Dlatego dwa urządzenia i cztery tunele poprawiają dostępność, a nie szybkość jednego transferu. Gdy slajd dostawcy obiecuje agregację, opisuje inną funkcję lub nieporozumienie.

Testuj z równoległymi przepływami, jeśli chcesz zobaczyć rozkład ścieżek, i z jednym przepływem, jeśli chcesz zobaczyć limit.

Jaką nadmiarowość faktycznie usunąłeś

Dwa adresy WAN na jednym urządzeniu poprawiają opcje łącza dostępowego, ale dzielą zasilanie, oprogramowanie i stan awarii tego urządzenia. Nie są tym samym co dwa urządzenia i żadna konfiguracja po stronie Azure tego nie zmienia. Postępuj zgodnie z obsługiwanym przez dostawcę projektem dual-WAN lub klastra, zamiast wnioskować o nadmiarowości z liczby adresów. Następnie przetestuj: usuwaj po jednej ścieżce i potwierdź pozostałe trasy oraz rzeczywistą wymianę aplikacji w obu kierunkach.

Oczekuj opóźnień wykrywania i konwergencji oraz tego, że niektóre istniejące sesje się zakończą.