To offentlige IP-adresser på én Azure VPN-VM: hvad gør hvilken

To offentlige IP-adresser på én Azure VPN-VM skaber en forventning, der sjældent holder: den adresse, klienter opretter forbindelse til, bliver også den adresse, websteder ser. Tre uafhængige beslutninger giver det resultat, og kun den første handler om tunnelens lytter. Den anden er gæstens kilde til videresendt klienttrafik, og den tredje er Azures udgående metode, der gælder for den kilde. Ændr én, og de to andre bliver, hvor de var, så beslut hver især eksplicit.

Beslutning 1: hvor tunnelen slutter

En offentlig Azure-IP er knyttet til en privat IP-konfiguration på NIC'en; det er ikke en adresse, du tilføjer inde i gæstens operativsystem. Læs koblingen i stedet for at antage den: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Hvilken privat adresse den forespørgsel end returnerer, er det den, gæsten faktisk skal have.

Én NIC kan bære flere IP-konfigurationer, så to offentlige adresser kræver ikke to NIC'er. Hvis designet alligevel bruger to NIC'er, bringer hver sin egen gæsterute og næste hop, og du har tilføjet en routingbeslutning i stedet for at forenkle en.

For en tjeneste med en eksplicit lokal binding skal du binde til gæstens reelle private adresse, aldrig til den offentlige pladsholder. En lytter, der accepterer alle adresser, modtager trafik gennem hver IP-konfiguration, der når den, så begræns indgangen med netværkssikkerhedsgruppen og værtens firewall i stedet for at håbe på, at bindingsrækkefølgen afgør det.

Beslutning 2: hvilken kilde den videresendte klient bruger

Når gatewayen har dekrypteret en klientanmodning, er den pakke, den videresender, en anden pakke end den, der ankom til VPN-lytteren. Gæsten skal have videresendelse aktiveret, en firewallpolitik, der tillader strømmen, og en kildeadresse, som clouddesignet tillader. Hvis du oversætter klientens indre adresse, er det den oversatte kilde, Azure vurderer, ikke klientens indre adresse.

En snæver SNAT-regel kan vælge en privat gæstekilde, men den kan ikke tilsidesætte en nedstrøms Azure-oversættelse. Vælg SNAT, når du har brug for ansvarlighed pr. klient inde i VM'en; spring den over, når undernettets udgående design allerede giver en stabil offentlig kilde, og en anden oversættelse kun ville tilføje tilstand.

Beslutning 3: hvilken Azure-udgående metode der vinder

Microsoft dokumentererprioritetsrækkefølgen for udgående trafik: en gældende rute til et apparat eller en gateway har prioritet, og undernettets NAT Gateway-forbindelse har prioritet over en offentlig IP på instansniveau på den relevante vej. Den rækkefølge er grunden til, at oversættelse til 10.20.0.5 ikke beviser, at et websted vil se 198.51.100.20. Læs den effektive rutetabel, NAT Gateway-tilknytningen og NIC'ens offentlige IP sammen, før du accepterer udgangsdesignet.

Holdindstillingen for videresendelse på Azure NICadskilt fra videresendelse i Linux. Cloudflaget tillader pakker, hvis kilde eller destination ikke er tildelt NIC'en; det aktiverer ikke net.ipv4.ip_forward, og gæsteindstillingen giver ikke cloudtilladelsen.

Tunnelsocket har sin egen kildebeslutning

WireGuards Address under wg-quick tildeler en adresse til WireGuard-interfacet; det er ikke en instruktion om ekstern UDP-binding. Den krypterede sockets kilde følger rutetabellen, så en politikrute eller en anden standardrute kan flytte den uden at røre interfaceadressen.OpenVPN: indstillingen local og UDP multihome opfører sig på samme måde: de handler om lytteren og dens svar, ikke om internetkilden for hver videresendt klient.

Bevar underlagsruten, der bærer tunnelen, og bekræft, at klienten stadig modtager autentificerede svar fra den forventede indgangsopsætning. Stol ikke på adresselistens rækkefølge som en permanent kildevalgspolitik, for den næste adresse, der føjes til NIC'en, kan ændre, hvilken der vinder.

Hvad skal accepteres, og i hvilken rækkefølge

Accepter tre resultater hver for sig. For det første når en ekstern klient den tilsigtede VPN-indgang. For det andet forlader en ny tilladt anmodning fra den VPN-klient den dokumenterede internetudgang. For det tredje forbliver utilsigtede lytter- og videresendelsesveje afvist. Registrér koblingerne fra offentlig til privat adresse og gæste- og cloudejerne af hver beslutning samme sted.

En vellykket tunnel beviser kun den første del. Test udgangen med en ny strøm, fordi en cachet forbindelse kan blive ved med at bruge den gamle kilde længe efter, at ruten er ændret.