Dve verejné IP adresy na jednom Azure VPN VM: ktorá čo robí

Dve verejné IP adresy na jednom Azure VPN VM vytvárajú očakávanie, ktoré sa málokedy splní: adresa, na ktorú sa klienti pripájajú, bude aj adresou, ktorú vidia weby. Tri nezávislé rozhodnutia tento výsledok vytvárajú a iba prvé sa týka poslucháča tunela. Druhé je zdroj v hostovi použitý na preposielanú klientsku prevádzku a tretie je metóda odchádzajúcej prevádzky v Azure, ktorá sa na tento zdroj vzťahuje. Zmeňte jedno a zvyšné dve zostanú tam, kde boli, preto každé rozhodnite výslovne.

Rozhodnutie 1: kde tunel končí

Verejná IP adresa v Azure je priradená ku konfigurácii súkromnej IP na NIC; nie je to adresa, ktorú pridávate vnútri hostovaného operačného systému. Čítajte mapovanie, namiesto toho, aby ste ho predpokladali: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Akúkoľvek súkromnú adresu ten dotaz vráti, práve tú musí host skutočne mať.

Jedna NIC môže niesť niekoľko konfigurácií IP, takže dve verejné adresy nevyžadujú dve NIC. Ak návrh naozaj používa dve NIC, každá prináša vlastné trasy v hostovi a ďalšie skoky, a vy ste pridali rozhodnutie o smerovaní namiesto toho, aby ste ho zjednodušili.

Pre službu s výslovným lokálnym naviazaním sa naviažte na skutočnú súkromnú adresu hosta, nikdy na verejný zástupný symbol. Poslucháč prijímajúci všetky adresy prijíma prevádzku cez každú konfiguráciu IP, ktorá k nemu dorazí, preto obmedzte vstup sieťovou bezpečnostnou skupinou a hostiteľským firewallom, namiesto toho, aby ste dúfali, že rozhodne poradie naviazania.

Rozhodnutie 2: aký zdroj používa preposielaný klient

Po tom, čo brána dešifruje klientsku požiadavku, paket, ktorý preposiela, je iný ako ten, ktorý dorazil na poslucháč VPN. Host potrebuje zapnuté preposielanie, politiku firewallu, ktorá tok povoľuje, a zdrojovú adresu, ktorú návrh cloudu povoľuje. Ak preložíte vnútornú adresu klienta, Azure bude vyhodnocovať práve tento preložený zdroj, nie vnútornú adresu klienta.

Úzke pravidlo SNAT môže zvoliť súkromný zdroj hosta, ale nemôže prepísať neskorší preklad v Azure. Zvoľte SNAT, keď potrebujete zodpovednosť za jednotlivých klientov vnútri VM; vynechajte ho, keď odchádzajúci návrh podsiete už poskytuje stabilný verejný zdroj a druhý preklad by len pridal stav.

Rozhodnutie 3: ktorá metóda odchádzajúcej prevádzky v Azure vyhrá

Microsoft dokumentujeporadie priority odchádzajúcej prevádzky: platná trasa k zariadeniu alebo bráne má prioritu a konektivita podsiete cez NAT Gateway má prioritu pred verejnou IP na úrovni inštancie na príslušnej ceste. Kvôli tomuto poradiu preklad na 10.20.0.5 nedokazuje, že web uvidí 198.51.100.20. Prečítajte efektívnu routovaciu tabuľku, priradenie NAT Gateway a verejnú IP NIC spoločne, než návrh výstupu prijmete.

Držtenastavenie preposielania Azure NICoddelene od preposielania v Linuxe. Príznak v cloude povoľuje pakety, ktorých zdroj alebo cieľ nie je priradený NIC; nezapína net.ipv4.ip_forward a nastavenie v hostovi nedáva cloudové oprávnenie.

Tunelový socket má vlastné rozhodnutie o zdroji

Address vo WireGuarde pod wg-quick priraďuje adresu rozhraniu WireGuard; nie je to pokyn na vonkajšie naviazanie UDP. Zdroj šifrovaného socketu sleduje routovaciu tabuľku, takže ho politická trasa alebo druhá predvolená trasa môže posunúť bez toho, aby sa dotkla adresy rozhrania.OpenVPN: voľba local a UDP multihome sa správajú rovnako: týkajú sa poslucháča a jeho odpovedí, nie internetového zdroja každého preposielaného klienta.

Zachovajte trasu spodnej vrstvy, ktorá nesie tunel, a potvrďte, že klient stále dostáva overené odpovede z očakávaného usporiadania vstupu. Nespoliehajte sa na poradie zoznamu adries ako trvalú politiku výberu zdroja, pretože ďalšia adresa pridaná k NIC môže zmeniť, ktorá vyhrá.

Čo prijať a v akom poradí

Prijmite tri výsledky oddelene. Po prvé, externý klient dosiahne zamýšľaný vstup VPN. Po druhé, nová povolená požiadavka od tohto VPN klienta odíde dokumentovaným internetovým výstupom. Po tretie, nechcené cesty poslucháča a preposielania zostanú odmietnuté. Zaznamenajte mapovania verejnej na súkromnú adresu a vlastníkov každého rozhodnutia na strane hosta aj cloudu na rovnakom mieste.

Úspešný tunel dokazuje len prvú časť. Testujte výstup novým tokom, pretože uložené spojenie môže naďalej používať starý zdroj ešte dlho po zmene trasy.