Dvě veřejné IP adresy na jednom Azure VPN VM: která co dělá

Dvě veřejné IP adresy na jednom Azure VPN VM vytvářejí očekávání, které se málokdy splní: adresa, na kterou se klienti připojují, bude i adresou, kterou vidí weby. Tři nezávislá rozhodnutí tento výsledek vytvářejí a jen první se týká posluchače tunelu. Druhé je zdroj v hostu použitý pro předávaný klientský provoz a třetí je metoda odchozího provozu v Azure, která se na tento zdroj vztahuje. Změňte jedno a zbývající dvě zůstanou tam, kde byla, proto každé rozhodněte výslovně.

Rozhodnutí 1: kde tunel končí

Veřejná IP adresa v Azure je přidružena ke konfiguraci privátní IP na NIC; není to adresa, kterou přidáváte uvnitř hostovaného operačního systému. Čtěte mapování, místo abyste ho předpokládali: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Ať ten dotaz vrátí jakoukoli privátní adresu, právě tu musí host skutečně mít.

Jedna NIC může nést několik konfigurací IP, takže dvě veřejné adresy nevyžadují dvě NIC. Pokud návrh opravdu používá dvě NIC, každá přináší vlastní trasy v hostu a další skoky, a vy jste přidali rozhodnutí o směrování, místo abyste ho zjednodušili.

Pro službu s výslovným lokálním navázáním se navažte na skutečnou privátní adresu hosta, nikdy na veřejný zástupný symbol. Posluchač přijímající všechny adresy přijímá provoz přes každou konfiguraci IP, která k němu dorazí, proto omezujte vstup síťovou bezpečnostní skupinou a hostitelským firewallem, místo abyste doufali, že rozhodne pořadí navázání.

Rozhodnutí 2: jaký zdroj používá předávaný klient

Poté co brána dešifruje klientský požadavek, paket, který předává, je jiný paket než ten, který dorazil na posluchač VPN. Host potřebuje zapnuté předávání, politiku firewallu, která tok povoluje, a zdrojovou adresu, kterou návrh cloudu povoluje. Pokud přeložíte vnitřní adresu klienta, Azure bude vyhodnocovat právě tento přeložený zdroj, nikoli vnitřní adresu klienta.

Úzké pravidlo SNAT může zvolit privátní zdroj hosta, ale nemůže přebít následný překlad v Azure. Zvolte SNAT, když potřebujete odpovědnost za jednotlivé klienty uvnitř VM; vynechte ho, když odchozí návrh podsítě už poskytuje stabilní veřejný zdroj a druhý překlad by jen přidal stav.

Rozhodnutí 3: která metoda odchozího provozu v Azure vyhraje

Microsoft dokumentujepořadí priority odchozího provozu: platná trasa k zařízení nebo bráně má prioritu a konektivita podsítě přes NAT Gateway má prioritu před veřejnou IP na úrovni instance na příslušné cestě. Kvůli tomuto pořadí překlad na 10.20.0.5 nedokazuje, že web uvidí 198.51.100.20. Přečtěte efektivní routovací tabulku, přidružení NAT Gateway a veřejnou IP NIC společně, než návrh výstupu přijmete.

Držtenastavení předávání Azure NICodděleně od předávání v Linuxu. Příznak v cloudu povoluje pakety, jejichž zdroj nebo cíl není NIC přiřazen; nezapíná net.ipv4.ip_forward a nastavení v hostu nedává cloudové oprávnění.

Tunelový socket má vlastní rozhodnutí o zdroji

Address ve WireGuardu pod wg-quick přiřazuje adresu rozhraní WireGuard; není to pokyn k vnějšímu navázání UDP. Zdroj šifrovaného socketu sleduje routovací tabulku, takže ho politická trasa nebo druhá výchozí trasa může posunout, aniž by se dotkla adresy rozhraní.OpenVPN: volba local a UDP multihome se chovají stejně: týkají se posluchače a jeho odpovědí, ne internetového zdroje každého předávaného klienta.

Zachovejte trasu spodní vrstvy, která nese tunel, a potvrďte, že klient stále dostává ověřené odpovědi z očekávaného uspořádání vstupu. Nespoléhejte na pořadí seznamu adres jako trvalou politiku výběru zdroje, protože další adresa přidaná k NIC může změnit, která vyhraje.

Co přijmout a v jakém pořadí

Přijměte tři výsledky odděleně. Za prvé, externí klient dosáhne zamýšleného vstupu VPN. Za druhé, nový povolený požadavek tohoto VPN klienta odejde dokumentovaným internetovým výstupem. Za třetí, nechtěné cesty posluchače a předávání zůstanou odmítnuté. Zaznamenejte mapování veřejné na privátní adresu a vlastníky každého rozhodnutí na straně hosta i cloudu na stejném místě.

Úspěšný tunel dokazuje jen první část. Testujte výstup novým tokem, protože uložené spojení může používat starý zdroj ještě dlouho po změně trasy.