Dvije javne IP adrese na jednom Azure VPN VM: koja šta radi
Adresa koja prihvata VPN pakete ne bira javni izvor klijentskog web zahtjeva. Odlučite odvojeno ulaz, izlaz i vezivanje tunela.
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 nezavisne odluke daju taj ishod, a samo prva se 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 sistema. 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 rutiranju umjesto da ste je pojednostavili.
Za servis s izričitim lokalnim vezivanjem vežite se na stvarnu privatnu adresu gosta, nikada na javni rezervisani prikaz. Slušač koji prihvata 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šifruje 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 unutrašnju klijentsku adresu, Azure će vrednovati upravo taj prevedeni izvor, a ne unutrašnju 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 dokumentujeredoslijed prioriteta izlaznog prometa: primjenjiva ruta prema uređaju ili gatewayu ima prioritet, a povezanost podmreže preko NAT Gatewaya ima prioritet nad 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 pomjeriti 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.
Šta 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.