Två offentliga IP-adresser på en enda Azure VPN-VM: vilken gör vad

Två offentliga IP-adresser på en enda Azure VPN-VM skapar en förväntan som sällan håller: adressen klienterna ansluter till blir också adressen som webbplatser ser. Tre oberoende beslut ger det resultatet, och bara det första handlar om tunnelns lyssnare. Det andra är gästkällan som används för vidarebefordrad klienttrafik, och det tredje är Azures utgående metod som gäller för den källan. Ändra en och de andra två stannar där de var, så bestäm var och en uttryckligen.

Beslut 1: var tunneln slutar

En offentlig Azure-IP är kopplad till en privat IP-konfiguration på NIC:n; det är inte en adress du lägger till i gästens operativsystem. Läs mappningen i stället för att anta den: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Vilken privat adress den frågan än returnerar är det den gästen faktiskt måste ha.

Ett NIC kan bära flera IP-konfigurationer, så två offentliga adresser kräver inte två NIC. Om designen ändå använder två NIC tar var och en med sig sina egna gästrutter och nästa hopp, och du har lagt till ett routingbeslut i stället för att förenkla ett.

För en tjänst med en uttrycklig lokal bindning binder du till gästens verkliga privata adress, aldrig till den offentliga platshållaren. En lyssnare som accepterar alla adresser tar emot trafik via varje IP-konfiguration som når den, så begränsa ingången med nätverkssäkerhetsgruppen och värdens brandvägg i stället för att hoppas att bindningsordningen avgör.

Beslut 2: vilken källa den vidarebefordrade klienten använder

Efter att gatewayen har dekrypterat en klientförfrågan är paketet den vidarebefordrar ett annat än det som anlände till VPN-lyssnaren. Gästen behöver vidarebefordran aktiverad, en brandväggspolicy som tillåter flödet och en källadress som molndesignen tillåter. Om du översätter klientens inre adress är det den översatta källan Azure utvärderar, inte klientens inre adress.

En smal SNAT-regel kan välja en privat gästkälla, men den kan inte åsidosätta en nedströms Azure-översättning. Välj SNAT när du behöver ansvar per klient inne i VM:en; hoppa över det när subnätets utgående design redan ger en stabil offentlig källa och en andra översättning bara skulle lägga till tillstånd.

Beslut 3: vilken Azure-utgående metod som vinner

Microsoft dokumenterarprioritetsordningen för utgående trafik: en gällande rutt till en enhet eller gateway har prioritet, och subnätets NAT Gateway-anslutning har prioritet över en offentlig IP på instansnivå på den aktuella vägen. Den ordningen är anledningen till att översättning till 10.20.0.5 inte bevisar att en webbplats kommer att se 198.51.100.20. Läs den effektiva routtabellen, NAT Gateway-kopplingen och NIC:ns offentliga IP tillsammans innan du accepterar utgångsdesignen.

Hållinställningen för vidarebefordran på Azure-NIC:nåtskild från vidarebefordran i Linux. Molnflaggan tillåter paket vars källa eller destination inte är tilldelad NIC:n; den aktiverar inte net.ipv4.ip_forward, och gästinställningen ger inte molnets tillstånd.

Tunnelns socket har sitt eget källbeslut

WireGuards Address under wg-quick tilldelar en adress till WireGuard-gränssnittet; det är inte en instruktion om extern UDP-bindning. Den krypterade socketens källa följer routtabellen, så en policyrutt eller en andra standardrutt kan flytta den utan att röra gränssnittsadressen.OpenVPN: alternativet local och UDP multihome beter sig likadant: de gäller lyssnaren och dess svar, inte internetkällan för varje vidarebefordrad klient.

Bevara underlagsrutten som bär tunneln och bekräfta att klienten fortfarande tar emot autentiserade svar från den förväntade ingångsanordningen. Förlita dig inte på adresslistans ordning som en permanent källvalspolicy, eftersom nästa adress som läggs till NIC:n kan ändra vilken som vinner.

Vad som ska accepteras, och i vilken ordning

Acceptera tre resultat separat. För det första når en extern klient den avsedda VPN-ingången. För det andra lämnar en ny tillåten förfrågan från den VPN-klienten den dokumenterade internetutgången. För det tredje förblir oavsiktliga lyssnar- och vidarebefordringsvägar nekade. Registrera mappningarna från offentlig till privat adress och gäst- och molnägarna för varje beslut på samma ställe.

En lyckad tunnel bevisar bara den första delen. Testa utgången med ett nytt flöde, eftersom en cachad anslutning kan fortsätta använda den gamla källan långt efter att rutten ändrats.