Divi publiskie IP uz vienas Azure VPN VM: kura ko dara

Divi publiskie IP uz vienas Azure VPN VM rada gaidas, kas reti piepildās: adrese, pie kuras pieslēdzas klienti, būs arī adrese, ko redz vietnes. Šo rezultātu rada trīs neatkarīgi lēmumi, un tikai pirmais attiecas uz tuneļa klausītāju. Otrais ir viesa avots, ko izmanto pārsūtītajai klienta plūsmai, bet trešais ir Azure izejas metode, kas attiecas uz šo avotu. Mainiet vienu, un pārējie divi paliek, kur bija, tāpēc izlemiet katru skaidri.

Lēmums 1: kur tunelis beidzas

Publiskais Azure IP ir saistīts ar privātu IP konfigurāciju uz NIC; tā nav adrese, ko pievienojat viesa operētājsistēmā. Lasiet saistījumu, nevis pieņemiet to: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Kādu privāto adresi šis vaicājums atgriež, tieši tā viesim ir faktiski jābūt.

Viena NIC var nest vairākas IP konfigurācijas, tāpēc divām publiskajām adresēm nav vajadzīgas divas NIC. Ja dizains tomēr izmanto divas NIC, katra nes savus viesa maršrutus un nākamos lēcienus, un jūs esat pievienojis maršrutēšanas lēmumu, nevis to vienkāršojis.

Pakalpojumam ar skaidru lokālo piesaisti piesaistiet faktiskajai viesa privātajai adresei, nekad publiskajam aizstājējam. Klausītājs, kas pieņem visas adreses, saņem plūsmu caur katru IP konfigurāciju, kas to sasniedz, tāpēc ierobežojiet ieeju ar tīkla drošības grupu un resursdatora ugunsmūri, nevis paļaujieties, ka izšķirs piesaistes kārtība.

Lēmums 2: kādu avotu izmanto pārsūtītais klients

Pēc tam, kad vārteja atšifrē klienta pieprasījumu, pārsūtītā pakete atšķiras no tās, kas nonāca VPN klausītājā. Viesim ir vajadzīga ieslēgta pārsūtīšana, ugunsmūra politika, kas atļauj plūsmu, un avota adrese, ko atļauj mākoņa dizains. Ja jūs tulkojat klienta iekšējo adresi, tieši šo tulkoto avotu Azure vērtēs, nevis klienta iekšējo adresi.

Šaurs SNAT noteikums var izvēlēties viesa privāto avotu, bet nevar pārspēt turpmāku Azure tulkojumu. Izvēlieties SNAT, ja jums nepieciešama atbildība par katru klientu VM iekšienē; izlaidiet to, ja apakštīkla izejas dizains jau nodrošina stabilu publisku avotu un otrs tulkojums tikai pievienotu stāvokli.

Lēmums 3: kura Azure izejas metode uzvar

Microsoft dokumentēizejas prioritātes secību: piemērojams maršruts uz ierīci vai vārteju iegūst prioritāti, un apakštīkla NAT Gateway savienojamība iegūst prioritāti pār instances līmeņa publisko IP attiecīgajā ceļā. Šīs secības dēļ tulkošana uz 10.20.0.5 nepierāda, ka vietne redzēs 198.51.100.20. Pirms pieņemat izejas dizainu, lasiet efektīvo maršrutu tabulu, NAT Gateway saistījumu un NIC publisko IP kopā.

TurietAzure NIC pārsūtīšanas iestatījumuatsevišķi no Linux pārsūtīšanas. Mākoņa karodziņš atļauj paketes, kuru avots vai galamērķis nav piešķirts NIC; tas neieslēdz net.ipv4.ip_forward, un viesa iestatījums nedod mākoņa atļauju.

Tuneļa ligzdai ir savs avota lēmums

WireGuard Address sadaļā wg-quick piešķir adresi WireGuard saskarnei; tā nav ārējas UDP piesaistes instrukcija. Šifrētās ligzdas avots seko maršrutu tabulai, tāpēc politikas maršruts vai otrs noklusējuma maršruts var to pārvietot, neaiztiekot saskarnes adresi.OpenVPN: opcija local un UDP multihome uzvedas tāpat: tie attiecas uz klausītāju un tā atbildēm, nevis uz katra pārsūtītā klienta interneta avotu.

Saglabājiet apakšējā slāņa maršrutu, kas nes tuneli, un apstipriniet, ka klients joprojām saņem autentificētas atbildes no gaidītā ieejas izkārtojuma. Neļaujieties adrešu saraksta secībai kā pastāvīgai avota izvēles politikai, jo nākamā NIC pievienotā adrese var mainīt, kura uzvar.

Ko pieņemt un kādā secībā

Pieņemiet trīs rezultātus atsevišķi. Pirmkārt, ārējais klients sasniedz paredzēto VPN ieeju. Otrkārt, jauns atļauts šī VPN klienta pieprasījums iziet caur dokumentēto interneta izeju. Treškārt, neparedzētie klausītāja un pārsūtīšanas ceļi paliek noraidīti. Pierakstiet publiskā-uz-privāto saistījumus un katra lēmuma viesa un mākoņa atbildīgos vienā vietā.

Veiksmīgs tunelis pierāda tikai pirmo daļu. Pārbaudiet izeju ar jaunu plūsmu, jo kešatmiņā saglabāts savienojums var izmantot veco avotu vēl ilgi pēc maršruta maiņas.