RRAS na maszynie wirtualnej Azure nie jest obsługiwany: sprawdź przed projektem

Otwierasz portal, wdrażasz Windows Server 2022 w podsieci, a rola Remote Access instaluje się bez problemów. Ta sekwencja dowodzi, że instalator działa, a nie że Microsoft obsługuje tę konfigurację. Opublikowane wytyczne pomocy technicznej dla oprogramowania serwerowego na maszynach wirtualnych Azure wymieniają RRAS wśród funkcji Windows Server, które nie są obsługiwane na maszynach wirtualnych Azure, i jest to decyzja architektoniczna, a nie szczegół rozwiązywania problemów. Tunel, który się podnosi, nie przenosi wdrożenia do wnętrza granicy obsługi.

Poniższy przewodnik zaczyna się na stronie pomocy technicznej, a następnie przechodzi do wymagań i opcji zamiany.

Zacznij na stronie pomocy technicznej, nie w laboratorium

Przeczytaj wytyczne pomocy technicznej dla maszyn wirtualnych Azure, zanim cokolwiek zwymiarujesz. Oddzielają one obsługiwane produkty, role i funkcje, zamiast traktować Windows Server jako jeden niepodzielny blok. Zwróć uwagę, do którego wiersza faktycznie należy planowane obciążenie, ponieważ dwa komponenty, które w konsoli wyglądają na powiązane, mogą znajdować się w różnych wierszach.

Zapisz cytat w dokumencie projektowym, dopóki strona jest otwarta. Status obsługi jest faktem ze źródłem, a przegląd projektu, który nie potrafi go zacytować, zostanie zakwestionowany przez osobę mającą demonstrację.

Oddziel obsługę systemu operacyjnego od obsługi ról i funkcji

Te same wytyczne wymieniają Network Policy and Access Services wśród obsługiwanych ról, a jednocześnie podają RRAS osobno jako nieobsługiwany. Te dwa wpisy opisują różne rzeczy, a łączenie ich w „dostęp zdalny jest obsługiwany” to sposób, w jaki projekt bywa zatwierdzany na podstawie błędnego odczytu. To, że system operacyjny jest obsługiwany, nic nie mówi o funkcji, która ma własny wiersz.

Ograniczenie jest też węższe, niż bywa cytowane. Dotyczy tej funkcji działającej wewnątrz maszyny wirtualnej Azure; nie oznacza, że sieć prywatna nie może połączyć się z Azure, ani nie mówi, że RRAS nie jest obsługiwany nigdzie. Starsze laboratorium, które poprawnie przekazuje pakiety, jest dowodem w sprawie pakietów, a nie oświadczenia o obsłudze.

Trzymaj te dwa pytania oddzielnie przez resztę projektu: czy to działa, i czy jest obsługiwane. Będziesz potrzebować różnych odpowiedzi, a czasem różnych właścicieli dla każdego.

Zapisz, co projekt musi faktycznie robić

Zanim wybierzesz zamiennik, zamień listę lokalizacji w wymagania, według których można mierzyć produkt:

• Protokoły tunelowania, którymi już mówią urządzenia w oddziałach, oraz czy jakakolwiek lokalizacja potrzebuje routingu dynamicznego.
• Prefiksy zdalne, w tym każda nakładająca się przestrzeń adresowa, która wymaga translacji, a nie routingu.
• Wymiana tras z Azure i to, kto jest właścicielem każdego wpisu w tabeli routingu.
• Przepustowość i liczba połączeń, które musi utrzymać najbardziej zajęta godzina.
• Zachowanie przy przełączeniu awaryjnym uzgodnione przez właścicieli lokalizacji, nie tylko to, które możesz zbudować.

NAT to element, który się pomija, a potem rozstrzyga cały projekt. Urządzenie, które potrafi ustanowić IPsec, nadal może tłumaczyć adresy inaczej niż zastępowane wdrożenie RRAS, co zmienia to, co oddział widzi jako adresy źródłowe i co zapisują twoje dzienniki.

Zanieś listę właścicielom sieci i potwierdź ją przed jakąkolwiek dyskusją o produktach. Niejasne wymagania zamieniają każde porównanie dostawców w spór o preferencje.

Oceń zamienniki według tych wymagań

Zarządzane usługi łączności Azure i obsługiwane przez dostawców wirtualne urządzenia sieciowe trzeba oceniać według tej samej listy. Nie zakładaj, że którekolwiek z nich jest bezpośrednim odpowiednikiem maszyny wirtualnej z RRAS tylko dlatego, że potrafi zakończyć IPsec: model NAT i własność tras oraz projekt wysokiej dostępności decydują, jak łączą się istniejące lokalizacje i dokąd wracają ich odpowiedzi. Oceń każdego kandydata na papierze według listy i zapisz, których wymagań nie spełnia, ponieważ właśnie ta notatka czyni wybór możliwym do przeglądu później.

Moduł równoważenia obciążenia przed dwiema maszynami wirtualnymi urządzeń nie jest sam w sobie wysoką dostępnością. Zapewnia front end, a nie zsynchronizowany stan tuneli, a przełączenie, które zrywa każdą sesję, jest decyzją projektową, którą ktoś musi podjąć świadomie. Zapytaj dostawcę urządzenia, jaki wzorzec HA jest obsługiwany i czy odpowiada dostępności obiecanej lokalizacjom. Przetestuj przełączenie, zanim te lokalizacje zaczną od niego zależeć, i traktuj każdą utraconą sesję jako ustalenie, a nie niespodziankę.

Tam, gdzie wymaganie jest naprawdę proste — jedna lokalizacja, jeden prefiks, brak nakładania — usługa zarządzana zwykle wygrywa kosztem operacyjnym. Tam, gdzie zarówno translacja, jak i routing dynamiczny wchodzą w grę, ścieżka przez urządzenie może być jedyną odpowiednią, i to jest powód, by zaplanować dłuższą migrację zamiast utrzymywać nieobsługiwaną maszynę wirtualną.

Jeśli maszyna wirtualna z RRAS już działa

Odkrycie nie jest powodem, by ją usunąć. Zaplanuj zmianę wokół zależności, które ta maszyna zgromadziła: tras, na których polegają inne podsieci, reguł NAT ukrywających adresy źródłowe i wszystkiego, czego monitoring nauczył się oczekiwać od jej adresu. Zachowaj wymagane trasy i przetestowaną ścieżkę odzyskiwania, podczas gdy obsługiwany cel jest projektowany i walidowany obok.

Przez cały czas trzymaj obsługiwalność i diagnostykę techniczną jako odrębne ustalenia. Nieobsługiwany układ może mieć również zwykły błąd routingu, a naprawienie tego błędu nie zmienia jego statusu obsługi. Oba stwierdzenia należą do raportu i żadne nie unieważnia drugiego.

Zakończ przewodnik, zapisując cytat pomocy technicznej, listę wymagań, wybrany zamiennik i kolejność przełączenia. Te cztery pozycje to pierwsze, o co zapyta audytor lub nowy członek zespołu.