Неге Azure Point-to-Site VPN сіздің жария IP-іңізді өзгертпейді

Мен Windows ноутбугінде Azure VPN клиентін қосамын, мекенжай-жаңғырық бетін ашамын және үй маршрутизаторым берген сол жария мекенжайды көремін. Сол уақытта 10.20.0.4 мекенжайындағы jump box жауап береді және жеке endpoint атауы шешіледі, яғни туннель бұзылмаған. Point-to-site шлюзі әдепкі конфигурациясы айтқанын дәл орындап тұр: жеке префикстерді тасымалдайды, қалғанын жергілікті байланыста қалдырады. Azure-ға тиесілі шығыс мекенжайын алу — маршруттау дизайнының өзгеруі, жөндеу емес.

Шлюз әдепкі бойынша нені жариялайды

Шлюз виртуалдық желінің мекенжай кеңістігі үшін маршруттарды, сондай-ақ шлюз транзитіне рұқсат етілген тең желілерді және site-to-site қосылымы немесе BGP арқылы үйренген жергілікті префикстерді жібереді. Бұл жиында 0.0.0.0/0 жоқ. Операциялық жүйеңіз әдепкі маршрутын Wi-Fi немесе Ethernet-те ұстайды, сондықтан жария API-ге бара жатқан пакет туннельге мүлде кірмейді.

Клиент туннель ішінде алатын мекенжай — point-to-site пулынан алынған жеке жалдау. Ол клиентті VNet ресурстарына танытады; бұл интернет көре алатын мекенжай емес және SaaS API-ге баратын шығыс сұраныстың көзі ретінде ешқашан көрінбейді. Осы жалдауға негізделген allowlist жазбасы жұмыс істей алмайды, оның жеткізуші журналдарында пайда болуын қанша күтсеңіз де.

Бөлінген туннель және мәжбүрлі туннельдеу қатар

Тек екінші жол қашықтағы қызмет көретін мекенжайды өзгертеді. Кестедегі қалғанның бәрі — шығуды Azure ішінде тексеру немесе аудару қажет болғанда қабылдайтын шығын мен операциялық бет. Егер біреу сізден жария IP-ні өзгертуді сұраса, ол бүкіл оң бағанды сұрап отыр, клиенттегі кішкене түзетуді емес.

Бірдеңе қайта салмас бұрын атап өтуге тұрарлық аралық нұсқа бар. VNet ішіндегі proxy немесе шлюз VM сізге сол жаққа бағыттауға болатын қосымшалар үшін бақыланатын бастапқы мекенжай береді, клиенттің әдепкі маршрутын жылжытпай. Бұл қарапайым шолуды жергілікті күйінде қалдырады және Azure-дан бір ғана API шақыруы келуін қажет ететін серіктесті қанағаттандырады. Талап шынымен бүкіл трафикке қатысты болса, ол сәтсіз болады, өйткені proxy параметрін елемейтіннің бәрі бәрібір жергілікті шығады.

Туннельге әдепкі маршрутты тасымалдатыңыз

Виртуалдық желі шлюзінде клиенттің барлық интернет трафигін туннельге бағыттаудың қолдау көрсетілген жолы — point-to-site конфигурациясына теңшелген маршруттар қосу. Екі жарты бүкіл IPv4 кеңістігін қамтиды және әрқайсысы жергілікті әдепкі маршруттан нақтырақ, сондықтан клиент ештеңені жоймай оларды қалайды:

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

Бұл жол көшіруге дайын емес, мысал ретінде берілген: әуелі Get-AzVirtualNetworkGateway арқылы шлюз нысанын алып, оны GWOBJ орнына қойыңыз, және іске қоспас бұрын SKU мен орналастыру үлгісі теңшелген маршруттарды қабылдайтынын растаңыз. Сол префикстер порталда point-to-site конфигурациясы бетінде көрінеді, ал шлюзді әлі скрипттемейтін болсаңыз, оларды сол жерде орнату қауіпсіздеу.

Осы префикстерді өзгерту клиент пакетін жарамсыз етеді. VPN клиент пакетін қайта жүктеп, қайта орнатыңыз, өйткені маршруттар профиль ішінде жүреді. Ескі профилімен қайта қосылған клиент ескі маршрут жиынын сақтайды, ал оған ешқашан жетпеген өзгерісті жөндеуге бір сағат жоғалтуыңыз мүмкін.

Қорғалған виртуалды WAN хабында балама — point-to-site шлюзімен байланысқан хаб маршруттар кестесіндегі әдепкі маршрут, ал трафикті хабтағы Azure Firewall қабылдайды. Firewall интернетке бағытталған қосылымдарды өзінің жария IP мекенжайларына аударады, жаңа шығыс мекенжайы осы аудармадан шығады. Firewall-дың бірнеше жария IP-і болса, олардың кез келгені көз ретінде көрінуі мүмкін, сондықтан allowlist олардың барлығын қамтуы керек.

Жоғарыдағы екі дизайн да IPv4. Екі /1 префиксі IPv6 үшін ештеңе істемейді, ал point-to-site-тің IPv6 қолдауы паритетке уәде бермес бұрын комбинацияны тексеруге туратындай тар.

Маршрутты тексеріңіз, содан кейін шығысты

Пакетті қайта орнатып, қайта қосылғаннан кейін клиенттің екі жартыны шынымен орнатқанын растаңыз. Windows-та Get-NetRoute -DestinationPrefix 0.0.0.0/1 және 128.0.0.0/1 үшін сол сұрау туннель интерфейсін атауы керек, ал route print екеуін де бастапқы әдепкі маршрутыңыздың жанында көрсетеді. Linux-та ip route show екі префиксті тізімдеуі керек; тізімдемесе, профиль оларды ешқашан тасымалдамаған.

Содан кейін клиенттен жария мекенжайды қайта тексеріп, сол қосылым үшін firewall журналын оқыңыз. Көзі аударылған портпен firewall-дың жария IP-і болуы керек. Екі маршрут та бар болғанда әлі де жергілікті шығып жатқан клиент пакеттердің Azure-ға жетіп, басқа жолмен шыққанын білдіреді: шлюз ішкі желісіндегі пайдаланушы анықтаған маршрут, өзі жергілікті желіге мәжбүрлі туннельделген firewall, немесе ағынды аудармаға дейін тастайтын саясат.

Сол сессияда бір жеке мақсатты қайта сынап көріңіз. Өзгерістен кейін жауап беруді тоқтататын jump host — жаңа префикстер бірдеңені ығыстырғанының әдеттегі белгісі: не бұрын жарияланған тар жергілікті маршрут, не енді жеке аймақтарыңыз үшін форвардері жоқ resolver-ге баратын атау шешімі.

Бөлінген туннельді қашан тыныш қалдыру керек

Мақсат тек жеке API-ге, жеке endpoint-ке немесе ішкі әкімші бетіне жету болса, әдепкі мінез-құлық арзанырақ және тынышырақ. Мәжбүрлі туннельдеу firewall сағаттары мен деректерді өңдеу төлемдерін, ұзағырақ жолды және әр клиент ағыны сәтсіз болуы мүмкін тағы бір орынды қосады. Ол сізді алаңдатқан жалғыз мақсаттан әлдеқайда көп трафикті де ұстайды.

Оған талап шығыс тұрғысынан айтылғанда жүгініңіз: серіктес тұрақты Azure мекенжайын көруі керек, қауіпсіздік қосылымдардың журналға жазылып, тексерілуін қалайды, немесе деректер бір бақыланатын нүктеден шығуы керек. Сонда да дизайн әр пайдаланушыға ортақ шығыс береді, сондықтан пайдаланушы бойынша жауапкершілік бастапқы мекенжайдан емес, қосымшадағы сәйкестендіруден келуі керек.

Өзгерісті жаппас бұрын төрт нәрсені растаңыз: орнатылған клиент пакеті жаңа, екі /1 маршруты туннель интерфейсінде, жеке мақсат әлі де жауап береді, және қашықтағы қызметтің журналы firewall мекенжайын көрсетеді.