To offentlege IP-adresser på éin Azure VPN-VM: kva gjer kvar av dei

To offentlege IP-adresser på éin Azure VPN-VM skapar ei forventning som sjeldan held: adressa klientane koplar til, blir også adressa nettsider ser. Tre uavhengige avgjerder gir dette resultatet, og berre den første handlar om lyttaren til tunnelen. Den andre er gjestekjelda som blir brukt for vidaresendt klienttrafikk, og den tredje er Azures utgåande metode som gjeld for den kjelda. Endre éi, og dei to andre blir der dei var, så avgjer kvar av dei eksplisitt.

Avgjerd 1: kvar tunnelen blir avslutta

Ein offentleg Azure-IP er knytt til ein privat IP-konfigurasjon på NIC-en; det er ikkje ei adresse du legg til inne i operativsystemet til gjesten. Les koplinga i staden for å gå ut frå ho: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Kva privat adresse den spørjinga enn returnerer, er det den adressa gjesten faktisk må ha.

Éin NIC kan bera fleire IP-konfigurasjonar, så to offentlege adresser krev ikkje to NIC-ar. Viss designet likevel brukar to NIC-ar, fører kvar si eiga gjesterute og neste hopp, og du har lagt til eit rutingsvedtak i staden for å forenkle eit.

For ein teneste med eksplisitt lokal binding skal du binde til den verkelege private adressa til gjesten, aldri til den offentlege plasshaldaren. Ein lyttar som godtek alle adresser, får trafikk gjennom kvar IP-konfigurasjon som når han, så avgrens inngangen med nettverkssikkerheitsgruppa og brannmuren til verten i staden for å håpe at bindingsrekkjefølgja avgjer.

Avgjerd 2: kva kjelde den vidaresende klienten brukar

Etter at gatewayen har dekryptert ei klientførespurnad, er pakken han vidaresender ein annan enn den som kom til VPN-lyttaren. Gjesten treng vidaresending slått på, ein brannmurpolitikk som tillèt straumen, og ei kjeldeadresse som skydesignet tillèt. Viss du omset den indre adressa til klienten, er det den omsette kjelda Azure vurderer, ikkje den indre adressa til klienten.

Ein smal SNAT-regel kan velje ei privat gjestekjelde, men han kan ikkje overstyre ei nedstraums Azure-omsetjing. Vel SNAT når du treng ansvarlegheit per klient inne i VM-en; hopp over det når det utgåande designet til undernettet alt gir ei stabil offentleg kjelde og ei andre omsetjing berre ville leggje til tilstand.

Avgjerd 3: kva Azure-utgåande metode som vinn

Microsoft dokumentererprioritetsrekkjefølgja for utgåande trafikk: ei gjeldande rute til ein eining eller ein gateway har prioritet, og NAT Gateway-tilkoplinga til undernettet har prioritet over ein offentleg IP på instansnivå på den aktuelle vegen. Den rekkjefølgja er grunnen til at omsetjing til 10.20.0.5 ikkje beviser at ei nettside vil sjå 198.51.100.20. Les den effektive rutetabellen, NAT Gateway-tilknytinga og den offentlege IP-en til NIC-en saman før du godtek utgangsdesignet.

Haldinnstillinga for vidaresending på Azure-NIC-enskild frå vidaresending i Linux. Skyflagg tillet pakkar der kjelda eller destinasjonen ikkje er tildelt NIC-en; det slår ikkje på net.ipv4.ip_forward, og gjesteinnstillinga gir ikkje løyve frå skyen.

Sokkelen til tunnelen har si eiga kjeldeavgjerd

Address til WireGuard under wg-quick tildeler ei adresse til WireGuard-grensesnittet; det er ikkje ein instruks om ekstern UDP-binding. Kjelda til den krypterte sokkelen følgjer rutetabellen, så ei policyrute eller ei andre standardrute kan flytte han utan å røre grensesnittadressa.OpenVPN: alternativet local og UDP multihome oppfører seg likt: dei gjeld lyttaren og svara hans, ikkje internettkjelda til kvar vidaresend klient.

Hald på underlagsruta som ber tunnelen, og stadfest at klienten framleis får autentiserte svar frå den forventa inngangsordninga. Ikkje stol på rekkjefølgja i adresselista som ein permanent kjeldevalpolitikk, for den neste adressa som blir lagd til NIC-en kan endre kven som vinn.

Kva som skal godtakast, og i kva rekkjefølgje

Godta tre resultat kvar for seg. For det første når ein ekstern klient den tiltenkte VPN-inngangen. For det andre forlèt ei ny tillaten førespurnad frå den VPN-klienten den dokumenterte internettutgangen. For det tredje blir utilsikta lyttar- og vidaresendingsvegar framleis avviste. Registrer tilordningane frå offentleg til privat og gjeste- og skyeigarane for kvar avgjerd på same stad.

Ein vellykka tunnel beviser berre den første delen. Test utgangen med ein ny straum, fordi ei bufra tilkopling kan halde fram med å bruke den gamle kjelda lenge etter at ruta er endra.