Kaks avalikku IP-d ühel Azure VPN VM-il: milline mida teeb

Kaks avalikku IP-d ühel Azure VPN VM-il loovad ootuse, mis harva täitub: aadress, millele kliendid ühenduvad, on ka aadress, mida veebisaidid näevad. Selle tulemuse annavad kolm sõltumatut otsust ja ainult esimene puudutab tunneli kuulajat. Teine on külalise allikas, mida kasutatakse edastatud kliendiliikluse jaoks, ja kolmas on Azure'i väljaminev meetod, mis kehtib selle allika kohta. Muutke ühte ja ülejäänud kaks jäävad sinna, kus nad olid, seega otsustage igaüks selgesõnaliselt.

Otsus 1: kus tunnel lõpeb

Azure'i avalik IP on seotud NIC-i privaatse IP-konfiguratsiooniga; see ei ole aadress, mille lisate külalise operatsioonisüsteemi sees. Lugege vastet, selle asemel et seda eeldada: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Millise privaatse aadressi see päring ka tagastab, just see peab külalisel tegelikult olema.

Üks NIC võib kanda mitut IP-konfiguratsiooni, seega kaks avalikku aadressi ei nõua kahte NIC-i. Kui disain siiski kasutab kahte NIC-i, toob kumbki oma külalise marsruudid ja järgmised hüpped ning olete lisanud marsruutimisotsuse, mitte seda lihtsustanud.

Selgesõnalise kohaliku sidemega teenuse puhul siduge külalise tegeliku privaatse aadressiga, mitte kunagi avaliku kohahoidjaga. Kõiki aadresse vastuvõttev kuulaja saab liiklust iga IP-konfiguratsiooni kaudu, mis temani jõuab, seega piirake sissepääsu võrguturberühmaga ja hosti tulemüüriga, selle asemel et loota sidumise järjekorrale.

Otsus 2: millist allikat edastatud klient kasutab

Pärast seda, kui lüüs on kliendi päringu dekrüpteerinud, on edastatav pakett erinev sellest, mis jõudis VPN-i kuulajani. Külalisel peab olema edastamine lubatud, voogu lubav tulemüürireegel ja allikaaadress, mille pilvedisain lubab. Kui tõlgite kliendi sisemise aadressi, hindab Azure just seda tõlgitud allikat, mitte kliendi sisemist aadressi.

Kitsas SNAT-reegel võib valida külalise privaatse allika, kuid ei saa tühistada hilisemat Azure'i tõlget. Valige SNAT, kui vajate vastutust iga kliendi eest VM-i sees; jätke see vahele, kui alavõrgu väljaminev disain pakub juba stabiilset avalikku allikat ja teine tõlge lisaks ainult olekut.

Otsus 3: milline Azure'i väljaminev meetod võidab

Microsoft dokumenteeribväljamineva liikluse prioriteedijärjekorra: rakendatav marsruut seadmele või lüüsile on prioriteetsem ja alavõrgu ühenduvus NAT Gateway kaudu on prioriteetsem kui eksemplari tasandi avalik IP asjaomasel teel. See järjekord on põhjus, miks tõlkimine aadressile 10.20.0.5 ei tõenda, et veebisait näeb 198.51.100.20. Lugege kehtivat marsruutimistabelit, NAT Gateway seost ja NIC-i avalikku IP-d koos, enne kui väljundisaini vastu võtate.

HoidkeAzure'i NIC-i edastamise seadetLinuxi edastamisest eraldi. Pilve lipp lubab pakette, mille allikas või sihtkoht ei ole NIC-ile määratud; see ei luba net.ipv4.ip_forward ja külalise seade ei anna pilve luba.

Tunneli soketil on oma allikaotsus

WireGuardi Address wg-quickis määrab aadressi WireGuardi liidesele; see ei ole välimise UDP-sidumise juhis. Krüpteeritud soketi allikas järgib marsruutimistabelit, seega poliitikamarsruut või teine vaikemarsruut võib seda liigutada liidese aadressi puutumata.OpenVPN: valik local ja UDP multihome käituvad samamoodi: need puudutavad kuulajat ja selle vastuseid, mitte iga edastatud kliendi internetiallikat.

Hoidke alles aluskihi marsruut, mis tunnelit kannab, ja kinnitage, et klient saab endiselt autenditud vastuseid oodatud sissepääsu paigutusest. Ärge toetuge aadressiloendi järjekorrale kui püsivale allikavaliku poliitikale, sest järgmine NIC-ile lisatud aadress võib muuta, milline võidab.

Mida ja mis järjekorras vastu võtta

Võtke kolm tulemust eraldi vastu. Esiteks jõuab väline klient kavandatud VPN-i sissepääsu. Teiseks väljub selle VPN-kliendi uus lubatud päring dokumenteeritud internetiväljapääsu kaudu. Kolmandaks jäävad soovimatu kuulaja- ja edastusteed keelatuks. Kirjutage avaliku ja privaatse aadressi vasted ning iga otsuse külalise- ja pilveomanikud samasse kohta.

Edukas tunnel tõestab ainult esimest osa. Katsetage väljapääsu uue vooluga, sest vahemällu salvestatud ühendus võib kasutada vana allikat veel kaua pärast marsruudi muutumist.