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

To offentlige IP-adresser på én Azure VPN-VM skaper en forventning som sjelden holder: adressen klientene kobler til, blir også adressen nettsteder ser. Tre uavhengige beslutninger gir dette resultatet, og bare den første handler om tunnelets lytter. Den andre er gjestekilden som brukes for videresendt klienttrafikk, og den tredje er Azures utgående metode som gjelder for den kilden. Endre én, og de to andre blir der de var, så bestem hver av dem eksplisitt.

Beslutning 1: hvor tunnelen avsluttes

En offentlig Azure-IP er knyttet til en privat IP-konfigurasjon på NIC-en; det er ikke en adresse du legger til inne i gjestens operativsystem. Les koblingen i stedet for å anta den: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Hvilken privat adresse den spørringen enn returnerer, er det den gjesten faktisk må ha.

Én NIC kan bære flere IP-konfigurasjoner, så to offentlige adresser krever ikke to NIC-er. Hvis designet likevel bruker to NIC-er, bringer hver sin egen gjesterute og neste hopp, og du har lagt til en rutingsbeslutning i stedet for å forenkle en.

For en tjeneste med en eksplisitt lokal binding skal du binde til gjestens virkelige private adresse, aldri til den offentlige plassholderen. En lytter som godtar alle adresser, mottar trafikk gjennom hver IP-konfigurasjon som når den, så begrens inngangen med nettverkssikkerhetsgruppen og vertens brannmur i stedet for å håpe at bindingsrekkefølgen avgjør.

Beslutning 2: hvilken kilde den videresendte klienten bruker

Etter at gatewayen har dekryptert en klientforespørsel, er pakken den videresender en annen enn den som ankom VPN-lytteren. Gjesten trenger videresending aktivert, en brannmurpolicy som tillater strømmen, og en kildeadresse som skydesignet tillater. Hvis du oversetter klientens indre adresse, er det den oversatte kilden Azure vurderer, ikke klientens indre adresse.

En smal SNAT-regel kan velge en privat gjestekilde, men den kan ikke overstyre en nedstrøms Azure-oversettelse. Velg SNAT når du trenger ansvarlighet per klient inne i VM-en; hopp over det når undernettets utgående design allerede gir en stabil offentlig kilde og en andre oversettelse bare ville legge til tilstand.

Beslutning 3: hvilken Azure-utgående metode som vinner

Microsoft dokumentererprioritetsrekkefølgen for utgående trafikk: en gjeldende rute til et apparat eller en gateway har prioritet, og undernettets NAT Gateway-tilkobling har prioritet over en offentlig IP på instansnivå på den aktuelle veien. Den rekkefølgen er grunnen til at oversettelse til 10.20.0.5 ikke beviser at et nettsted vil se 198.51.100.20. Les den effektive rutetabellen, NAT Gateway-tilknytningen og NIC-ens offentlige IP sammen før du godtar utgangsdesignet.

Holdinnstillingen for videresending på Azure-NIC-enatskilt fra videresending i Linux. Skyflagget tillater pakker hvis kilde eller destinasjon ikke er tilordnet NIC-en; det aktiverer ikke net.ipv4.ip_forward, og gjesteinnstillingen gir ikke skyens tillatelse.

Tunnelets socket har sin egen kildebeslutning

WireGuards Address under wg-quick tildeler en adresse til WireGuard-grensesnittet; det er ikke en instruksjon om ekstern UDP-binding. Den krypterte socketens kilde følger rutetabellen, så en policyrute eller en annen standardrute kan flytte den uten å berøre grensesnittadressen.OpenVPN: alternativet local og UDP multihome oppfører seg likt: de gjelder lytteren og svarene dens, ikke internettkilden for hver videresendt klient.

Bevar underlagsruten som bærer tunnelen, og bekreft at klienten fortsatt mottar autentiserte svar fra den forventede inngangsordningen. Ikke stol på rekkefølgen i adresselisten som en permanent kildevalgspolicy, for den neste adressen som legges til NIC-en kan endre hvilken som vinner.

Hva som skal godtas, og i hvilken rekkefølge

Godta tre resultater hver for seg. For det første når en ekstern klient den tiltenkte VPN-inngangen. For det andre forlater en ny tillatt forespørsel fra den VPN-klienten den dokumenterte internettutgangen. For det tredje forblir utilsiktede lytter- og videresendingsveier avvist. Registrer tilordningene fra offentlig til privat og gjeste- og skyeierne for hver beslutning på samme sted.

En vellykket tunnel beviser bare den første delen. Test utgangen med en ny strømning, fordi en bufret tilkobling kan fortsette å bruke den gamle kilden lenge etter at ruten er endret.