Dvije javne IP adrese na jednom Azure VPN VM: koja što radi

Dvije javne IP adrese na jednom Azure VPN VM stvaraju očekivanje koje se rijetko ostvari: adresa na koju se klijenti spajaju bit će i adresa koju vide web stranice. Tri neovisne odluke daju taj ishod, a samo se prva tiče slušača tunela. Druga je izvor u gostu koji se koristi za proslijeđeni klijentski promet, a treća je Azure metoda izlaznog prometa koja se primjenjuje na taj izvor. Promijenite jednu i druge dvije ostaju gdje su bile, zato svaku odlučite izričito.

Odluka 1: gdje tunel završava

Javna IP adresa u Azureu povezana je s konfiguracijom privatne IP adrese na NIC-u; to nije adresa koju dodajete unutar gostujućeg operativnog sustava. Pročitajte mapiranje umjesto da ga pretpostavljate: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Koja god privatna adresa da vrati taj upit, upravo je ona koju gost mora stvarno imati.

Jedan NIC može nositi nekoliko IP konfiguracija, pa dvije javne adrese ne zahtijevaju dva NIC-a. Ako dizajn ipak koristi dva NIC-a, svaki donosi vlastite rute u gostu i sljedeće hopove, a vi ste dodali odluku o usmjeravanju umjesto da ste je pojednostavili.

Za servis s izričitim lokalnim vezivanjem vežite se na stvarnu privatnu adresu gosta, nikada na javni rezervirani prikaz. Slušač koji prihvaća sve adrese prima promet kroz svaku IP konfiguraciju koja do njega dođe, zato ograničite ulaz mrežnom sigurnosnom grupom i host firewallom, umjesto da se nadate da će redoslijed vezivanja odlučiti.

Odluka 2: koji izvor koristi proslijeđeni klijent

Nakon što gateway dešifrira klijentski zahtjev, paket koji prosljeđuje razlikuje se od paketa koji je stigao na VPN slušač. Gostu treba omogućeno prosljeđivanje, firewall pravilo koje dopušta tok i izvorna adresa koju dizajn oblaka dopušta. Ako prevedete unutarnju klijentsku adresu, Azure će vrednovati upravo taj prevedeni izvor, a ne unutarnju adresu klijenta.

Usko SNAT pravilo može odabrati privatni izvor u gostu, ali ne može nadjačati nizvodno Azure prevođenje. Odaberite SNAT kada vam treba odgovornost po klijentu unutar VM-a; preskočite ga kada izlazni dizajn podmreže već daje stabilan javni izvor i drugo prevođenje bi samo dodalo stanje.

Odluka 3: koja Azure metoda izlaznog prometa pobjeđuje

Microsoft dokumentiraredoslijed prioriteta izlaznog prometa: primjenjiva ruta prema uređaju ili gatewayu ima prioritet, a povezanost podmreže preko NAT Gatewaya ima prioritet pred javnom IP adresom na razini instance na relevantnoj putanji. Zbog tog redoslijeda prevođenje na 10.20.0.5 ne dokazuje da će web stranica vidjeti 198.51.100.20. Pročitajte efektivnu tablicu ruta, povezanost s NAT Gatewayom i javnu IP adresu NIC-a zajedno prije nego prihvatite dizajn izlaza.

Držitepostavku prosljeđivanja Azure NIC-aodvojeno od Linux prosljeđivanja. Zastavica u oblaku dopušta pakete čiji izvor ili odredište nije dodijeljen NIC-u; ona ne omogućuje net.ipv4.ip_forward, a postavka u gostu ne daje dopuštenje oblaka.

Tunelski socket ima vlastitu odluku o izvoru

Address u WireGuardu pod wg-quick dodjeljuje adresu WireGuard sučelju; to nije uputa za vanjsko UDP vezivanje. Izvor šifriranog socketa slijedi tablicu ruta, pa ga politička ruta ili druga zadana ruta može pomaknuti bez diranja adrese sučelja.OpenVPN: opcija local i UDP multihome ponašaju se isto: tiču se slušača i njegovih odgovora, a ne internetskog izvora svakog proslijeđenog klijenta.

Sačuvajte rutu donjeg sloja koja nosi tunel i potvrdite da klijent i dalje prima autentificirane odgovore iz očekivanog rasporeda ulaza. Ne oslanjajte se na redoslijed liste adresa kao trajnu politiku odabira izvora, jer sljedeća adresa dodana NIC-u može promijeniti koja pobjeđuje.

Što prihvatiti i kojim redom

Prihvatite tri rezultata odvojeno. Prvo, vanjski klijent dosegne predviđeni VPN ulaz. Drugo, novi dopušteni zahtjev tog VPN klijenta izađe kroz dokumentirani internetski izlaz. Treće, neželjeni putevi slušača i prosljeđivanja ostaju odbijeni. Zabilježite mapiranja javne u privatnu adresu i vlasnike svake odluke na strani gosta i oblaka na istom mjestu.

Uspješan tunel dokazuje samo prvi dio. Testirajte izlaz novim tokom, jer keširana veza može nastaviti koristiti stari izvor dugo nakon promjene rute.