Kierowanie ruchu między dwoma oddziałami przez bramę VPN Azure
Dwa połączenia Site-to-Site na jednej bramie VPN Azure mogą przepuszczać ruch oddziałów, ale tylko wtedy, gdy oba końce nauczą się prefiksu i istnieje ścieżka powrotna w sieci LAN.
Dwa oddziały mogą wymieniać ruch przez bramę VPN Azure bez żadnego bezpośredniego tunelu między nimi. Każdy oddział otwiera połączenie Site-to-Site do tej samej bramy, a brama przekazuje nauczone prefiksy między oboma połączeniami. Działa to nie dzięki drugiemu tunelowi, lecz dzięki wymianie tras: oddział A musi nauczyć się prefiksu oddziału B, a B prefiksu A. Przejdź przez poniższe kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie, ponieważ każdy kolejny krok od niej zależy.
Wymagania wstępne, zanim cokolwiek skonfigurujesz
Cztery warunki decydują, czy ten projekt może w ogóle działać. Brama musi być oparta na trasach i działać na SKU obsługującym BGP, oba połączenia muszą mieć włączony BGP, przestrzenie adresowe oddziałów nie mogą się nakładać, a żadna strona nie może polegać na NAT, aby ukryć swój rzeczywisty prefiks.
Zaplanuj ASN świadomie. Udokumentowana wartość domyślna Azure to 65515, a każdy router oddziału potrzebuje własnego prywatnego ASN, który nie koliduje z bramą ani z drugim oddziałem. Ponowne użycie wartości domyślnej bez sprawdzenia istniejącej konfiguracji bramy to sposób, w jaki ścieżka AS zostaje później odrzucona.
Potwierdź też, że nie oczekujesz zachowania peeringu VNet. Brama wymienia trasy między dwoma skonfigurowanymi połączeniami; nie czyni dowolnych peeringów przechodnimi. Jeśli trzecia sieć ma dotrzeć do obu oddziałów, potrzebuje własnego połączenia lub własnej ścieżki trasy, a nie założenia, że brama rozdzieli ruch. Zapisz tę granicę przed pierwszym oknem zmian, bo to jest decyzja projektowa, do której ludzie wracają, gdy później dodawana jest nowa lokalizacja.
Konfiguruj w tej kolejności
Każdy krok ma obserwowalny wynik, więc nie przechodź dalej, dopóki się nie pojawi.
- Włącz BGP na bramie sieci wirtualnej i zanotuj jej ASN oraz adres peera.
- Utwórz lokalną bramę sieciową dla każdego oddziału z jego rzeczywistą przestrzenią adresową, jego ASN i adresem peera BGP.
- Utwórz każde połączenie Site-to-Site i włącz BGP na samym połączeniu.
- Skonfiguruj router oddziału tak, aby peeringował z adresem bramy przydzielonym przez Azure, a nie z publicznym punktem końcowym IKE bramy na podstawie założenia.
Czwarty krok to miejsce, w którym zatrzymuje się większość prób. Adres peera BGP raportowany przez Azure to ten, którego router oddziału musi użyć jako sąsiada, i nie zawsze jest to adres, którego ludzie oczekują ze schematu tunelu.
Ogłoś sam prefiks oddziału, na przykład 10.10.0.0/16 z A i 10.20.0.0/16 z B. Nie ogłaszaj trasy domyślnej ani szerokiego agregatu, aby pokryć brakującą konkretną sieć; luka wraca później jako cicha czarna dziura.
Zweryfikuj wymianę tras na obu końcach
Stan połączenia nie jest kontrolą. IPsec może być aktywny na obu połączeniach, podczas gdy żaden prefiks między nimi nie przechodzi. Odczytaj peery BGP bramy i jej nauczone trasy, a następnie potwierdź, że trasa w stronę drugiego oddziału pojawia się jako użyteczna ścieżka.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Prefiks obecny w tabeli BGP nadal może przegrać decyzję o przekazaniu ze statyczną trasą lub bardziej szczegółowym prefiksem. Sprawdzaj wybraną trasę, nie tylko otrzymaną.
Śledź ścieżkę powrotną po stronie LAN
To część, która wygląda poprawnie w Azure, a zawodzi na miejscu. Host w oddziale A wysyła swój pakiet do routera VPN A tylko wtedy, gdy ten router jest jego bramą domyślną lub gdy host lub jego brama ma trasę do prefiksu B. To samo musi być prawdą w drugim kierunku.
Jeśli osobny przełącznik rdzeniowy jest bramą domyślną LAN, potrzebuje trasy w stronę drugiego oddziału wskazującej na router VPN. Bez niej żądanie dociera, a odpowiedź wychodzi ścieżką internetową, i użytkownik widzi połączenie, które się otwiera, a potem zawiesza.
Nie sięgaj po grupę zabezpieczeń sieci w podsieci bramy, aby to naprawić. Ta podsieć ma własne wymagania, a NSG tam nie jest obsługiwanym zamiennikiem polityki po stronie oddziału. Filtrowanie należy do zapór oddziałów i do samych obciążeń, gdzie reguły mogą przeglądać ich właściciele. Przeniesienie tych reguł do NSG podsieci ukrywa je także przed zespołem, który będzie debugował następną awarię.
Zezwól na operację, a potem udowodnij ją odmówionym testem
Nauczona trasa nie jest pozwoleniem. Zezwól na źródło, cel i usługę, których naprawdę potrzebujesz, przez zapory oddziałów i politykę punktu końcowego, a resztę pozostaw odmówioną.
Przetestuj z typowego obciążenia w oddziale A do rzeczywistej usługi w oddziale B, potwierdź odpowiedź, a następnie spróbuj operacji, która powinna pozostać zabroniona. Ruch generowany przez samo urządzenie VPN może używać innego adresu źródłowego i pomijać etap routingu LAN, więc udany ping z routera dowodzi mniej, niż się wydaje.
Zakończ, zapisując cztery fakty: wymienione prefiksy, używane ASN, ścieżkę powrotną LAN dla każdej strony i politykę, która dopuszcza usługę. Jeśli brakuje jednego z nich, konfiguracja działa do pierwszej zmiany, a potem nikt nie potrafi wyjaśnić dlaczego.