UDR w Azure do bramy VPN: jedno miejsce docelowe, nie cały ruch wychodzący

Skieruj jeden prefiks Azure na bramę VPN bez przenoszenia całego ruchu wychodzącego. Przeczytaj obowiązujące trasy, przypnij podsieć obciążenia i dokończ drogę powrotną.

Dodajesz trasę zdefiniowaną przez użytkownika dla jednego prefiksu zewnętrznego, kierujesz ją na bramę VPN, a ruch nadal wychodzi ścieżką internetową Azure. Albo wychodzi poprawnie i odpowiedź nigdy nie wraca. Oba wyniki biorą się z tego samego błędu: traktowania następnego skoku w Azure jako całego projektu. Tabela tras decyduje tylko, które wyjście pakiet wybierze wewnątrz Azure. Co dzieje się z nim po tunelu i jak wraca odpowiedź, to druga połowa, którą musisz zbudować.

Następny skok to brama, a nie adres IP urządzenia

UDR wysyła pasujący prefiks do typu następnego skoku, a VirtualNetworkGateway to typ, nie adres. Ludzie wklejają prywatny adres IP bramy do trasy VirtualAppliance i zastanawiają się, dlaczego nic nie pasuje, bo ten typ oczekuje raczej karty sieciowej lub wewnętrznego load balancera. Dokumentacja routingu firmy Microsoft ogranicza też następny skok bramy do sieci wirtualnej, której brama jest bramą VPN. ExpressRoute, Route Server i koncentrator Virtual WAN nie są adresowane tą opcją.

Sprawdź, co sieć wirtualna naprawdę ma, zanim napiszesz trasę. Jeśli projekt routuje przez koncentrator, trasa należy do właściciela routingu koncentratora, a nie do szprychy, którą akurat edytujesz.

Przeczytaj obowiązującą trasę, zanim cokolwiek zmienisz

Azure łączy trasy systemowe, prefiksy poznane przez BGP i UDR w obowiązującą tabelę tras dla każdej karty sieciowej, a najdłuższy pasujący prefiks wygrywa niezależnie od tego, skąd pochodzi. Dla tego samego prefiksu UDR wygrywa z trasą BGP. Ta kolejność jest powodem, dla którego nieaktualny UDR z wcześniejszego eksperymentu może po cichu nadpisać prefiks, którego właśnie nauczyłeś się przez tunel.

Najpierw spójrz na obowiązującą tabelę, potem zdecyduj, czy dodajesz trasę, czy ją zastępujesz:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Czytaj także kolumnę źródła, nie tylko prefiks. Trasa z właściwym prefiksem i złym źródłem mówi, który obiekt edytować, i ratuje cię od dodania drugiej trasy, która przegrywa z pierwszą.

Napisz trasę pod rzeczywisty prefiks i podsieć

Użyj rzeczywistego prefiksu celu, wziętego z usługi, do której naprawdę docierasz, zamiast publicznego zakresu skopiowanego z postu na forum. Zacznij od jednej zatwierdzonej usługi, zanim rozważysz trasę domyślną, która przenosi cały ruch wychodzący. Następnie przypnij tabelę tras do podsieci obciążenia. Podsieć bramy ma własne wymagania, a przypięcie tam twojej tabeli psuje bramę, zamiast kierować obciążenie.

Utwórz trasę, a następnie powiąż tabelę z podsiecią, w której działa obciążenie:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Propagacja też ma znaczenie. Przy włączonej propagacji BGP w tej tabeli poznane prefiksy pojawiają się obok twoich, a bardziej szczegółowy poznany prefiks może pokonać szerszy UDR. Wyłączaj propagację tylko wtedy, gdy chcesz, aby zestaw UDR był nadrzędny dla tej podsieci.

Dokończ połowę po stronie lokalnej, inaczej przepływ tam umrze

Brama lokalna musi zaakceptować źródło z Azure, przekazać je do celu i zezwolić aplikacji. Jej dalsza droga może być wyjściem internetowym lub innym prywatnym skokiem, ale ta decyzja należy do planu, a nie do tabeli tras Azure. Typowym błędem jest powrót. Cel internetowy nie będzie routował prywatnego źródła Azure z powrotem do ciebie, więc odpowiedź idzie do własnej bramy domyślnej i ginie, albo nigdy nie wychodzi.

Dwa projekty to rozwiązują i nie są wymienne. Przetłumacz źródło na wyjściu, aby cel odpowiadał na publiczny adres, który posiada sieć lokalna. Albo zachowaj źródło i zbuduj rutowaną relację powrotną, aby odpowiedzi wracały przez tunel. Wybierz jedno i zapisz, który adres zobaczy aplikacja.

Selektory i listy dozwolonych są od tego oddzielone. Wybór następnego skoku Azure nie poszerza selektorów ruchu VPN i nie zmienia listy dozwolonych źródeł usługi zewnętrznej.

Zweryfikuj po źródle obserwowanym przez cel

Wyślij żądanie z rzeczywistego obciążenia, a nie z hosta przeskoku w innej podsieci, a potem odczytaj adres źródłowy zaobserwowany przez cel. Ta jedna wartość mówi, który z dwóch projektów powrotu jest wdrożony. Następnie sprawdź ścieżkę odpowiedzi i potwierdź, że zwykły ruch zarządzający do maszyny wirtualnej nadal działa, bo trasa domyślna dodana przypadkiem objawia się jako zerwana sesja SSH znacznie wcześniej, niż jako zepsuta aplikacja.

Tranzyt przez wybrany prefiks to znacznie węższa zmiana niż wymuszony tunel. Utrzymaj ją wąską, a wycofanie to usunięcie jednej trasy.

Powiązane artykuły