Dwa publiczne adresy IP na jednej maszynie Azure VPN VM: który co robi

Dwa publiczne adresy IP na jednej maszynie Azure VPN VM tworzą oczekiwanie, które rzadko się spełnia: adres, z którym łączą się klienci, będzie także adresem widzianym przez witryny. Trzy niezależne decyzje dają ten wynik i tylko pierwsza dotyczy nasłuchu tunelu. Druga to źródło w gościu używane dla przekazywanego ruchu klienta, a trzecia to metoda wyjścia Azure stosowana do tego źródła. Zmień jedną, a pozostałe dwie zostaną tam, gdzie były, więc rozstrzygnij każdą jawnie.

Decyzja 1: gdzie kończy się tunel

Publiczny adres IP Azure jest powiązany z konfiguracją prywatnego adresu IP na karcie NIC; to nie adres dodawany wewnątrz systemu operacyjnego gościa. Czytaj to powiązanie, zamiast je zakładać: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Jakikolwiek prywatny adres zwróci to zapytanie, właśnie ten musi faktycznie mieć gość.

Jedna karta NIC może nieść kilka konfiguracji IP, więc dwa publiczne adresy nie wymagają dwóch kart. Jeśli projekt rzeczywiście używa dwóch kart, każda wnosi własne trasy gościa i następne skoki, a ty dodałeś decyzję o routingu zamiast ją uprościć.

Dla usługi z jawnym powiązaniem lokalnym powiąż się z rzeczywistym prywatnym adresem gościa, nigdy z publicznym symbolem zastępczym. Nasłuch przyjmujący wszystkie adresy odbiera ruch przez każdą konfigurację IP, która do niego dotrze, więc ogranicz wejście grupą zabezpieczeń sieci i zaporą hosta, zamiast liczyć, że rozstrzygnie kolejność powiązania.

Decyzja 2: jakiego źródła używa przekazywany klient

Po odszyfrowaniu żądania klienta przez bramę przekazywany pakiet różni się od pakietu, który dotarł do nasłuchu VPN. Gość potrzebuje włączonego przekazywania, polityki zapory zezwalającej na przepływ oraz adresu źródłowego dozwolonego przez projekt chmury. Jeśli tłumaczysz wewnętrzny adres klienta, to właśnie to przetłumaczone źródło oceni Azure, a nie wewnętrzny adres klienta.

Wąska reguła SNAT może wybrać prywatne źródło gościa, ale nie może nadpisać późniejszego tłumaczenia Azure. Wybierz SNAT, gdy potrzebujesz rozliczalności dla każdego klienta wewnątrz maszyny; pomiń go, gdy projekt wyjścia podsieci już zapewnia stabilne publiczne źródło, a drugie tłumaczenie tylko dodałoby stan.

Decyzja 3: która metoda wyjścia Azure wygrywa

Microsoft dokumentujekolejność pierwszeństwa ruchu wychodzącego: obowiązująca trasa do urządzenia lub bramy ma pierwszeństwo, a łączność podsieci przez NAT Gateway ma pierwszeństwo przed publicznym adresem IP na poziomie wystąpienia na danej ścieżce. Ta kolejność jest powodem, dla którego tłumaczenie na 10.20.0.5 nie dowodzi, że witryna zobaczy 198.51.100.20. Przeczytaj razem efektywną tablicę tras, skojarzenie NAT Gateway i publiczny adres IP karty przed zaakceptowaniem projektu wyjścia.

Trzymajustawienie przekazywania karty Azureosobno od przekazywania w Linuksie. Flaga chmury zezwala na pakiety, których źródło lub cel nie jest przypisane do karty; nie włącza net.ipv4.ip_forward, a ustawienie gościa nie daje uprawnienia chmury.

Gniazdo tunelu ma własną decyzję o źródle

WireGuardowe Address w wg-quick przypisuje adres interfejsowi WireGuard; to nie instrukcja zewnętrznego powiązania UDP. Źródło zaszyfrowanego gniazda podąża za tablicą tras, więc trasa polityki lub druga trasa domyślna może je przesunąć bez dotykania adresu interfejsu.OpenVPN: opcja local i UDP multihome zachowują się tak samo: dotyczą nasłuchu i jego odpowiedzi, a nie źródła internetowego każdego przekazywanego klienta.

Zachowaj trasę warstwy spodu, która niesie tunel, i potwierdź, że klient nadal otrzymuje uwierzytelnione odpowiedzi z oczekiwanego układu wejścia. Nie polegaj na kolejności listy adresów jako stałej polityce wyboru źródła, ponieważ następny adres dodany do karty może zmienić, który wygrywa.

Co zaakceptować i w jakiej kolejności

Zaakceptuj trzy wyniki osobno. Po pierwsze, klient zewnętrzny dociera do zamierzonego wejścia VPN. Po drugie, nowe dozwolone żądanie od tego klienta VPN wychodzi przez udokumentowane wyjście internetowe. Po trzecie, niepożądane ścieżki nasłuchu i przekazywania pozostają odrzucone. Zapisz mapowania publicznego na prywatny oraz odpowiedzialnych po stronie gościa i chmury dla każdej decyzji w jednym miejscu.

Udany tunel dowodzi tylko pierwszej części. Przetestuj wyjście nowym przepływem, ponieważ połączenie w pamięci podręcznej może nadal używać starego źródła długo po zmianie trasy.