Domyślna iniekcja trasy w sieciach wirtualnych szprych

Jedną z najpopularniejszych architektur na platformie Azure jest projekt piasty i szprych, w którym obciążenia wdrożone w sieci wirtualnej będącej szprychą wysyłają ruch za pośrednictwem udostępnionych urządzeń sieciowych, które istnieją w sieci wirtualnej piasty. Trasy zdefiniowane przez użytkownika (UDR) zwykle muszą być skonfigurowane w sieciach wirtualnych szprych w celu kierowania ruchu do urządzeń zabezpieczeń w koncentratorze. Jednak ten projekt wymaga od administratorów zarządzania tymi trasami w wielu szprychach.

Usługa Azure Route Server oferuje scentralizowany punkt, w którym wirtualne urządzenia sieciowe (WUS) mogą anonsować trasy, które wprowadza w sieciach wirtualnych szprych. Dzięki temu administratorzy nie muszą tworzyć i aktualizować tabel tras w sieciach wirtualnych szprych.

Topologia

Na poniższym diagramie przedstawiono prosty projekt piasty i szprych z siecią wirtualną piasty i dwiema szprychami. W centrum wdrożono wirtualne urządzenie sieciowe i serwer route server. Bez serwera Route Server trasy zdefiniowane przez użytkownika muszą być skonfigurowane w każdej szprychy. Te trasy zdefiniowane przez użytkownika zwykle zawierają trasę domyślną dla 0.0.0.0/0, która wysyła cały ruch z sieci wirtualnych szprych za pośrednictwem urządzenia WUS. Ten scenariusz może służyć na przykład do sprawdzania ruchu w celach bezpieczeństwa.

W przypadku serwera Route Server w sieci wirtualnej piasty nie ma potrzeby używania tras zdefiniowanych przez użytkownika. Urządzenie WUS anonsuje prefiksy sieciowe do serwera Route Server, który wprowadza je w taki sposób, aby były wyświetlane w obowiązujących trasach dowolnej maszyny wirtualnej wdrożonej w sieci wirtualnej koncentratora lub sieciach wirtualnych szprych, które są równorzędne z siecią wirtualną koncentratora z ustawieniem Użyj bramy zdalnej sieci wirtualnej lub serwera Route Server.

Łączność z środowiskiem lokalnym za pośrednictwem urządzenia WUS

Jeśli urządzenie WUS jest używane do zapewnienia łączności z siecią lokalną za pośrednictwem sieci VPN IPsec lub technologii SD-WAN, ten sam mechanizm może służyć do przyciągania ruchu z szprych do urządzenia WUS. Ponadto urządzenie WUS może dynamicznie uczyć się prefiksów platformy Azure z usługi Azure Route Server i anonsować je przy użyciu protokołu routingu dynamicznego do środowiska lokalnego. Na poniższym diagramie opisano tę konfigurację:

Inspekcja ruchu prywatnego za pośrednictwem urządzenia WUS

W poprzednich sekcjach przedstawiono ruch sprawdzany przez wirtualne urządzenie sieciowe (WUS), wstrzykiwając trasę domyślną 0.0.0.0/0 z urządzenia WUS do serwera Route Server. Jeśli jednak chcesz tylko sprawdzić ruch między szprychami i szprychami i szprychami za pośrednictwem urządzenia WUS, należy wziąć pod uwagę, że usługa Azure Route Server nie anonsuje trasy, która jest taka sama lub dłuższa prefiks niż przestrzeń adresowa sieci wirtualnej poznana na podstawie urządzenia WUS. Innymi słowy, usługa Azure Route Server nie będzie wprowadzać tych prefiksów do sieci wirtualnej i nie będzie programowana na kartach sieciowych maszyn wirtualnych w sieciach wirtualnych piasty lub szprych.

Jednak usługa Azure Route Server anonsuje większą podsieć niż przestrzeń adresowa sieci wirtualnej, która jest nauczona z urządzenia WUS. Istnieje możliwość anonsowania z urządzenia WUS supersieci tego, co masz w sieci wirtualnej. Jeśli na przykład sieć wirtualna używa przestrzeni 10.0.0.0/16adresowej RFC 1918, urządzenie WUS może anonsować 10.0.0.0/8 się do serwera usługi Azure Route Server, a te prefiksy zostaną wprowadzone do sieci wirtualnych piasty i szprych. To zachowanie sieci wirtualnej jest przywołyne w temacie About BGP with VPN Gateway (Informacje o protokole BGP z bramą sieci VPN).

Ważne

Jeśli masz scenariusz, w którym prefiksy o tej samej długości są anonsowane z usługi ExpressRoute i urządzenia WUS, platforma Azure preferuje i programuje trasy poznane w usłudze ExpressRoute. Aby uzyskać więcej informacji, zapoznaj się z następną sekcją.

Łączność z lokalną siecią za pośrednictwem bram sieci wirtualnej

Jeśli sieć VPN lub brama usługi ExpressRoute istnieje w tej samej sieci wirtualnej co serwer Route Server i urządzenie WUS w celu zapewnienia łączności z sieciami lokalnymi, trasy poznane przez te bramy będą również programowane w sieciach wirtualnych szprych. Te trasy zastępują trasę domyślną (0.0.0.0/0) wstrzykniętą przez serwer tras, ponieważ byłyby bardziej szczegółowe (dłuższe maski sieciowe). Na poniższym diagramie opisano poprzedni projekt, w którym dodano bramę usługi ExpressRoute.

Nie można skonfigurować podsieci w sieciach wirtualnych szprych, aby poznać tylko trasy z usługi Azure Route Server. Wyłączenie opcji "Propagacja tras bramy" w tabeli tras skojarzonej z podsiecią uniemożliwiłoby wstrzyknięcie obu typów tras (tras z bramy sieci wirtualnej i tras z usługi Azure Route Server) do kart sieciowych w tej podsieci.

Domyślnie serwer route server anonsuje wszystkie prefiksy poznane z urządzenia WUS do usługi ExpressRoute. Może to nie być pożądane, na przykład ze względu na limity tras usługi ExpressRoute lub samego serwera Route Server. W takim przypadku urządzenie WUS może ogłosić swoje trasy do serwera Route Server, w tym społeczność no-advertise protokołu BGP (z wartością 65535:65282). Gdy usługa Route Server odbiera trasy z tą społecznością protokołu BGP, wprowadza je do podsieci, ale nie będzie anonsować ich do innych elementów równorzędnych protokołu BGP (takich jak usługa ExpressRoute lub bramy sieci VPN lub inne urządzenia WUS).

Współistnienie sdWAN z usługą ExpressRoute i usługą Azure Firewall

Konkretnym przypadkiem poprzedniego projektu jest wstawienie usługi Azure Firewall w przepływie ruchu w celu sprawdzenia całego ruchu przechodzącego do sieci lokalnych za pośrednictwem usługi ExpressRoute lub za pośrednictwem urządzeń SD-WAN/VPN. W takiej sytuacji wszystkie podsieci szprych mają tabele tras, które uniemożliwiają szprychom uczenie się dowolnej trasy z usługi ExpressRoute lub serwera Route Server i mają trasy domyślne (0.0.0.0/0) z usługą Azure Firewall jako następny przeskok, jak pokazano na poniższym diagramie:

Podsieć usługi Azure Firewall uczy się tras pochodzących zarówno z usługi ExpressRoute, jak i sieci VPN/SDWAN NVA, i decyduje, czy wysyła ruch w jeden sposób, czy z drugiej. Zgodnie z opisem w poprzedniej sekcji, jeśli urządzenie WUS anonsuje ponad 1000 tras do serwera Route Server, powinno wysłać swoje trasy protokołu BGP oznaczone społeczności no-advertiseBGP. W ten sposób prefiksy SDWAN nie będą wstrzykiwane z powrotem do środowiska lokalnego za pośrednictwem usługi Express-Route.

Symetria ruchu

Jeśli w scenariuszu aktywnym/aktywnym jest używanych wiele wystąpień urządzenia WUS w celu zapewnienia lepszej odporności lub skalowalności, symetria ruchu jest wymagana, jeśli urządzenia WUS muszą zachować stan połączeń. Dotyczy to na przykład zapór nowej generacji.

• W przypadku łączności z maszyn wirtualnych platformy Azure do publicznego Internetu urządzenie WUS używa źródłowego tłumaczenia adresów sieciowych (SNAT), aby ruch wychodzący był pozyskiwany z publicznego adresu IP urządzenia WUS, co powoduje osiągnięcie symetrii ruchu.
• W przypadku ruchu przychodzącego z Internetu do obciążeń uruchomionych na maszynach wirtualnych dodatkowe do docelowego tłumaczenia adresów sieciowych (DNAT) urządzenia WUS będą wymagały wykonania translacji adresów sieciowych (SNAT), aby upewnić się, że ruch powrotny z maszyn wirtualnych ląduje w tym samym wystąpieniu urządzenia WUS, które przetworzyło pierwszy pakiet.
• W przypadku łączności między platformą Azure a platformą Azure, ponieważ źródłowa maszyna wirtualna podejmie decyzję o routingu niezależnie od miejsca docelowego, funkcja SNAT jest obecnie wymagana do osiągnięcia symetrii ruchu.

Wiele wystąpień urządzenia WUS można również wdrożyć w konfiguracji aktywne/pasywnej, na przykład jeśli jedna z nich anonsuje gorsze trasy (z dłuższą ścieżką AS) niż druga. W takim przypadku usługa Azure Route Server będzie wprowadzać tylko preferowaną trasę na maszynach wirtualnych sieci wirtualnej, a mniej preferowana trasa będzie używana tylko wtedy, gdy główne wystąpienie urządzenia WUS zatrzymuje reklamy za pośrednictwem protokołu BGP.

Różne serwery tras do anonsowania tras do bram sieci wirtualnej i do sieci wirtualnych

Jak pokazano w poprzednich sekcjach, usługa Azure Route Server ma podwójną rolę:

• Uczy się i anonsuje trasy do/z bram sieci wirtualnej (VPN i ExpressRoute)
• Konfiguruje trasy poznane w sieci wirtualnej i bezpośrednio równorzędnych sieciach wirtualnych

Ta podwójna funkcjonalność często jest interesująca, ale czasami może to być szkodliwe dla niektórych wymagań. Jeśli na przykład serwer route server jest wdrożony w sieci wirtualnej z urządzeniem WUS anonsowany trasą 0.0.0.0/0 i bramą usługi ExpressRoute reklamowaną prefiksami ze środowiska lokalnego, skonfiguruje wszystkie trasy (zarówno 0.0.0.0.0/0 z urządzenia WUS, jak i lokalne prefiksy) na maszynach wirtualnych w sieci wirtualnej i bezpośrednio równorzędnych sieciach wirtualnych. W związku z tym, ponieważ prefiksy lokalne będą bardziej specyficzne niż 0.0.0.0.0/0, ruch między środowiskiem lokalnym a platformą Azure będzie pomijać urządzenie WUS. Jeśli nie jest to pożądane, poprzednie sekcje w tym artykule pokazały, jak wyłączyć propagację protokołu BGP w podsieciach maszyn wirtualnych i skonfigurować trasy zdefiniowane przez użytkownika.

Jednak istnieje alternatywna, bardziej dynamiczna metoda. Istnieje możliwość korzystania z różnych serwerów usługi Azure Route Servers dla różnych funkcji: jedna z nich będzie odpowiedzialna za interakcję z bramami sieci wirtualnej, a drugą do interakcji z routingiem sieci wirtualnej. Na poniższym diagramie przedstawiono możliwy projekt dla tego:

Usługa Route Server 1 w centrum służy do wstrzykiwania prefiksów z sieci SDWAN do usługi ExpressRoute. Ponieważ sieci wirtualne będące szprychami są równorzędne z siecią wirtualną piasty bez bramy zdalnej sieci wirtualnej lub serwera tras (w komunikacji równorzędnej sieci wirtualnej będącej szprychą) i użyj bramy tej sieci wirtualnej lub serwera tras (tranzyt bramy w sieci równorzędnej sieci wirtualnej piasty), sieci wirtualne będące szprychami nie uczą się tych tras (ani prefiksów SDWAN, ani prefiksów usługi ExpressRoute).

Aby propagować trasy do sieci wirtualnych szprych, urządzenie WUS używa usługi Route Server 2 wdrożonej w nowej pomocniczej sieci wirtualnej. Urządzenie WUS będzie propagować tylko jedną 0.0.0.0/0 trasę do usługi Route Server 2. Ponieważ sieci wirtualne będące szprychami są równorzędne z tą pomocniczą siecią wirtualną z użyciem bramy zdalnej sieci wirtualnej lub serwera tras (w komunikacji równorzędnej sieci wirtualnej będącej szprychą) i Użyj bramy tej sieci wirtualnej lub serwera tras (tranzyt bramy w sieci równorzędnej sieci wirtualnej piasty), 0.0.0.0/0 trasa zostanie wyuczone przez wszystkie maszyny wirtualne w szprychach.

Następny przeskok dla 0.0.0.0/0 trasy to urządzenie WUS, więc sieci wirtualne będące szprychami muszą być nadal równorzędne z siecią wirtualną piasty. Innym ważnym aspektem, który należy zauważyć, jest to, że sieć wirtualna piasty musi być równorzędna z siecią wirtualną, w której wdrożono usługę Route Server 2. W przeciwnym razie nie będzie można utworzyć sąsiedztwa protokołu BGP.

Jeśli ruch z usługi ExpressRoute do sieci wirtualnych będącej szprychą ma być wysyłany do wirtualnego urządzenia sieciowego zapory w celu przeprowadzenia inspekcji, tabela tras w podsieci GatewaySubnet jest nadal wymagana, w przeciwnym razie brama sieci wirtualnej usługi ExpressRoute wyśle pakiety do maszyn wirtualnych przy użyciu tras wyciągniętych z komunikacji równorzędnej sieci wirtualnych. Trasy w tej tabeli tras powinny być zgodne z prefiksami szprych, a następnym przeskokiem powinien być adres IP urządzenia WUS zapory (lub moduł równoważenia obciążenia przed zaporą urządzeń WUS w celu zapewnienia nadmiarowości). Urządzenie WUS zapory może być takie samo jak urządzenie WUS SDWAN na powyższym diagramie lub może być innym urządzeniem, takim jak usługa Azure Firewall, ponieważ urządzenie WUS SDWAN może anonsować trasy z następnym przeskokiem wskazującym inne adresy IP. Na poniższym diagramie przedstawiono ten projekt z dodatkiem usługi Azure Firewall:

Uwaga

W przypadku dowolnego ruchu ze środowiska lokalnego przeznaczonego dla prywatnych punktów końcowych ten ruch będzie pomijać urządzenie WUS zapory lub usługę Azure Firewall w centrum. Jednak powoduje to routing asymetryczny (co może prowadzić do utraty łączności między lokalnymi i prywatnymi punktami końcowymi) jako prywatnych punktów końcowych do przekazywania ruchu lokalnego do zapory. Aby zapewnić symetrię routingu, włącz zasady sieciowe tabeli tras dla prywatnych punktów końcowych w podsieciach, w których wdrożono prywatne punkty końcowe.

Ten projekt umożliwia automatyczne wstrzykiwanie tras w sieciach wirtualnych szprych bez zakłóceń z innych tras pochodzących z usługi ExpressRoute, sieci VPN lub środowiska SDWAN oraz dodanie wirtualnych urządzeń WUS zapory do inspekcji ruchu.

Powiązana zawartość

• Dowiedz się więcej o obsłudze usługi Azure Route Server dla usługi ExpressRoute i sieci VPN platformy Azure.
• Dowiedz się, jak skonfigurować komunikację równorzędną między usługą Azure Route Server i wirtualnym urządzeniem sieciowym.