Kāpēc Azure Point-to-Site VPN nemaina jūsu publisko IP

Es pieslēdzu Azure VPN klientu Windows klēpjdatorā, atveru adreses atbalss lapu un redzu to pašu publisko adresi, ko piešķīra mans mājas maršrutētājs. Tikmēr jump box pie 10.20.0.4 atbild un privātā endpoint nosaukums tiek atrisināts, tāpēc tunelis nav salauzts. Point-to-site vārteja dara tieši to, ko saka tās noklusējuma konfigurācija: pārvadā privātos prefiksus un visu pārējo atstāj lokālajā saitē. Azure piederošas izejas adreses iegūšana ir maršrutēšanas dizaina maiņa, nevis remonts.

Ko vārteja paziņo pēc noklusējuma

Vārteja virza maršrutus virtuālā tīkla adrešu telpai, kā arī savienotajiem tīkliem, kur atļauta vārtejas tranzītplūsma, un lokālajiem prefiksiem, kas apgūti site-to-site savienojumā vai ar BGP. Šajā kopā nav 0.0.0.0/0. Jūsu operētājsistēma tur noklusējuma maršrutu uz Wi-Fi vai Ethernet, tāpēc pakete uz publisku API pat neiekļūst tunelī.

Adrese, ko klients saņem tunelī, ir privāta līze no point-to-site baseina. Tā identificē klientu VNet resursiem; tā nav adrese, ko internets var redzēt, un tā nekad neparādīsies kā izejošā pieprasījuma uz SaaS API avots. Apliecinājumu saraksta ieraksts, kas veidots ap šo līzi, nevar darboties, lai cik ilgi jūs gaidītu, kad tas parādīsies piegādātāja žurnālos.

Sadalītais tunelis un piespiedu tunelēšana līdzās

Tikai otrā rinda maina adresi, ko redz attālināts pakalpojums. Viss pārējais šajā tabulā ir izmaksas un operatīvā virsma, ko pieņemat, kad izeja ir jāpārbauda vai jātulko Azure iekšienē. Ja kāds lūdz mainīt publisko IP, viņš lūdz visu labo kolonnu, nevis nelielu klienta pielāgojumu.

Pirms kaut ko pārbūvējat, ir vērts nosaukt starpvariantu. Proxy vai vārtejas VM VNet iekšienē dod jums kontrolētu avota adresi lietojumprogrammām, kuras var vērst uz to, nepārvietojot klienta noklusējuma maršrutu. Tas saglabā parasto pārlūkošanu lokālu un joprojām apmierina partneri, kam nepieciešams tikai viens API izsaukums no Azure. Tas neizdodas, ja prasība patiešām attiecas uz visu trafiku, jo viss, kas ignorē proxy iestatījumu, joprojām iziet lokāli.

Liec tunelim pārvadāt noklusējuma maršrutu

Virtuālā tīkla vārtejā atbalstītais veids, kā virzīt visu klienta interneta trafiku tunelī, ir pievienot pielāgotus maršrutus point-to-site konfigurācijai. Divas puses nosedz visu IPv4 telpu, un katra ir konkrētāka par lokālo noklusējuma maršrutu, tāpēc klients dod priekšroku tām, neko nedzēšot:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Šī rinda ir ilustratīva, nevis gatava kopēšanai: vispirms iegūstiet vārtejas objektu ar Get-AzVirtualNetworkGateway un aizstājiet ar to GWOBJ, un pirms izpildes pārliecinieties, ka SKU un izvietošanas modelis pieņem pielāgotus maršrutus. Tie paši prefiksi parādās portālā point-to-site konfigurācijas lapā, kas ir drošāka vieta to iestatīšanai, ja vēl neskriptojat vārteju.

Šo prefiksu maiņa padara klienta pakotni nederīgu. Lejupielādējiet VPN klienta pakotni vēlreiz un instalējiet to no jauna, jo maršruti ceļo profila iekšienē. Klients, kas atkārtoti pieslēdzas ar savu veco profilu, saglabā veco maršrutu kopu, un jūs varat zaudēt stundu, atkļūdojot izmaiņas, kas to nekad nesasniedza.

Aizsargātā virtuālajā WAN centrā ekvivalents ir noklusējuma maršruts centra maršrutu tabulā, kas saistīta ar point-to-site vārteju, un trafiku pārņem Azure Firewall centrā. Ugunsmūris pārveido uz internetu vērstos savienojumus savās publiskajās IP adresēs, un tieši no šī pārveidojuma nāk jaunā izejas adrese. Ja ugunsmūrim ir vairākas publiskās IP, jebkura no tām var parādīties kā avots, tāpēc apliecinājumu sarakstā jābūt visām.

Abi iepriekš minētie risinājumi ir IPv4. Divi /1 prefiksi neko nedara IPv6, un point-to-site IPv6 atbalsts ir tik šaurs, ka kombinācija jāpārbauda pirms paritātes solīšanas.

Pārbaudiet maršrutu, tad izeju

Pēc pakotnes atkārtotas instalēšanas un atkārtotas pieslēgšanās pārliecinieties, ka klients tiešām instalēja abas puses. Windows Get-NetRoute -DestinationPrefix 0.0.0.0/1 un tas pats vaicājums 128.0.0.0/1 ir jānorāda tuneļa saskarne, un route print rāda abus blakus sākotnējam noklusējuma maršrutam. Linux ip route show ir jāuzskaita divi prefiksi; ja ne, profils tos nekad nav pārvadājis.

Pēc tam vēlreiz pārbaudiet publisko adresi no klienta un izlasiet ugunsmūra žurnālu tam pašam savienojumam. Avotam jābūt ugunsmūra publiskajai IP ar pārveidotu portu. Klients, kas joprojām iziet lokāli, lai gan pastāv abi maršruti, nozīmē, ka paketes sasniedza Azure un izgāja pa citu ceļu: lietotāja definēts maršruts vārtejas apakštīklā, ugunsmūris, kas pats ir piespiedu tunelī uz lokālo tīklu, vai politika, kas atmet plūsmu pirms pārveidojuma.

Vēlreiz pārbaudiet vienu privātu galamērķi tajā pašā sesijā. Jump host, kas pēc izmaiņām pārstāj atbildēt, ir ierastā zīme, ka jaunie prefiksi kaut ko izspieda, vai nu šaurāku lokālo maršrutu, kas iepriekš tika paziņots, vai nu nosaukumu atrisināšanu, kas tagad iet uz risinātāju bez pārsūtītāja jūsu privātajām zonām.

Kad atstāt sadalīto tuneli mierā

Ja mērķis ir tikai sasniegt privātu API, privātu endpoint vai iekšēju administrācijas lapu, noklusējuma uzvedība ir lētāka un klusāka. Piespiedu tunelēšana pievieno ugunsmūra stundas un datu apstrādes maksas, garāku ceļu un vēl vienu vietu, kur katra klienta plūsma var neizdoties. Tā arī uztver daudz vairāk trafika nekā vienīgais galamērķis, kas jums rūpēja.

Izmantojiet to, kad prasība ir formulēta izejas izteiksmē: partnerim jāredz fiksēta Azure adrese, drošībai savienojumi jāreģistrē un jāpārbauda, vai datiem jāiziet caur vienu kontrolētu punktu. Pat tad dizains katram lietotājam dod kopīgu izeju, tāpēc atbildība par lietotāju jānāk no identitātes lietojumprogrammā, nevis no avota adreses.

Pirms aizverat izmaiņas, pārliecinieties par četrām lietām: instalētā klienta pakotne ir jaunā, divi /1 maršruti ir tuneļa saskarnē, privātais galamērķis joprojām atbild, un attālinātā pakalpojuma žurnāls rāda ugunsmūra adresi.