Site-to-Site VPN między AWS a Azure: najpierw zapisz trasę powrotną
Połączony tunel między chmurami niczego nie dowodzi, dopóki każda podsieć obciążenia nie kieruje ruchu do zdalnego prefiksu. Przejdź plan po kolei, a potem przetestuj usługę.
Tunel się podniesie. Zwykle tak się dzieje, bo IKE potrzebuje tylko zgodnych propozycji i osiągalnego adresu peera. Potem zawodzi droga powrotna: obciążenie w AWS wysyła pakiety do tunelu, ale po stronie Azure nikt nie wie, jak odpowiedzieć na 10.10.0.0/16, albo trasa Azure jest w tabeli, której podsieć obciążenia nie używa. Zapisz plan tras, zanim dotkniesz jakiejkolwiek konsoli, a tunel stanie się najmniej ciekawą częścią pracy.
Krok 1: zamroź plan adresów
Pracuj na konkretnych wartościach. Obciążenie w AWS znajduje się na 10.10.1.20 w 10.10.0.0/16 i potrzebuje TCP 443 do usługi Azure na 10.20.1.30 w 10.20.0.0/16. Oba zakresy nie mogą się nakładać, a testem odbiorczym jest para usług, nie tunel.
Zapisz te cztery fakty przed wszystkim innym, bo każdy kolejny krok jest wobec nich sprawdzany.
Krok 2: nazwij bramę, która jest właścicielem każdego końca
AWS Site-to-Site VPN może kończyć się na wirtualnej bramie prywatnej albo na bramie tranzytowej, a to różni właściciele tras. Azure oferuje zarządzaną bramę VPN Gateway i osobno urządzenia oparte na VM, które klienci prowadzą sami. Zanotuj, którą parę masz, bo następny skok jest inny w każdej kombinacji.
Dla zarządzanej bramy nie kopiuj trasy wskazującej na zgadywany adres prywatnego urządzenia. Dla urządzenia nie zakładaj, że propagacja tras w chmurze konfiguruje system gościa, bo tak nie jest.
Pomyłka tutaj daje plan, który wygląda kompletnie, i wysyła pakiety na adres, który nigdy nie odpowiada.
Krok 3: zapisz trasę, której każde obciążenie naprawdę używa
Każda granica poniżej to osobne wyszukiwanie, a trasa w jednej z nich nie jest trasą dla pakietu. Wypełnij tabelę własnymi wartościami, zanim tunel zacznie działać.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
W AWS tabelę tras podsieci obciążenia aktualizujesz sam nawet po tym, jak BGP lub tunel są zdrowe; przegląd routingu traktuje to jako część połączenia. W Azure tabela tras zdefiniowanych przez użytkownika jest powiązana z podsiecią, a nie z siecią wirtualną, więc sprawdzaj trasę efektywną na karcie NIC obciążenia, a nie w bloku VNet.
Zarządzana brama Azure może się nauczyć zdalnego prefiksu przez propagację bramy, a UDR może tę decyzję unieważnić. Dodawaj UDR, gdy masz powód, nie odruchowo. Jeśli ją dodasz, prowadź ją do następnego skoku, który brama publikuje dla ścieżki VPN, zamiast wymyślać adres urządzenia. Potem odczytaj ponownie trasy efektywne na karcie NIC, bo tam naprawdę zapada decyzja.
Krok 4: uzgodnij zakres
W BGP porównaj, co każda strona ogłasza, z tym, czego druga strona naprawdę się nauczyła, prefiks po prefiksie. W routingu statycznym porównaj skonfigurowane zakresy zdalne z trasami obciążenia zapisanymi w kroku 3.
Związek IKE zgodny co do kryptografii nie jest dowodem, że któraś strona nauczyła się 10.10.0.0/16 lub 10.20.0.0/16. Dwa tunele mogą być podniesione, gdy jedna strona ogłasza jeden /24 zamiast zaplanowanego /16. Sprawdzaj prefiks w tabeli routingu, a nie w statusie tunelu. Niezgodność ujawnia się później jako jedna działająca podsieć i jedna, która nigdy nie odpowiada.
Krok 5: przetestuj usługę z rzeczywistego źródła
Zezwól na zamierzony przepływ w grupach zabezpieczeń i ACL sieci AWS, w NSG Azure i w każdym filtrze urządzenia na ścieżce. Następnie otwórz jedno połączenie z 10.10.1.20 do zatwierdzonego adresu i portu usługi i potwierdź, że odpowiedź wraca do tego samego źródła.
Zarówno grupy zabezpieczeń chmury, jak i NSG są stanowe, więc odrzucony pakiet powrotny jest objawem routingu, a nie regułą, o której zapomniałeś napisać w drugą stronę.
Ping z dowolnej bramy niczego nie rozstrzyga. ICMP na adres bramy ćwiczy ścieżkę płaszczyzny sterowania, a nie przekazywaną usługę TCP, której potrzebuje obciążenie.
Wycofanie i zapisy
Zapisz właścicieli tras obok identyfikatorów tunelu i zachowaj tabele tras sprzed zmiany. Jeśli zmianę trzeba wycofać, usuń trasy obciążenia przed rozbiórką tunelu, aby żadna podsieć nie wskazywała następnego skoku, którego już nie ma.
Wtedy późniejsze przeniesienie podsieci lub podłączenie spoke ma jedno określone miejsce do aktualizacji, zamiast działającego tunelu, który ponosi winę za trasę, której nigdy nie posiadał.