Зошто Azure Point-to-Site VPN не ја менува вашата јавна IP адреса

Го поврзувам клиентот Azure VPN на преносен сметач со Windows, отворам страница за одглас на адресата и ја гледам истата јавна адреса што ја даде мојот домашен рутер. Во меѓувреме скок-кутијата на 10.20.0.4 одговара и името на приватна крајна точка се решава, значи тунелот не е расипан. Point-to-site портата го прави токму она што го вели нејзината стандардна конфигурација: ги носи приватните префикси и сѐ друго го остава на локалната врска. Добивањето излезна адреса сопственост на Azure е промена на дизајнот на рутирање, не поправка.

Што објавува портата по стандард

Портата турка рути за адресниот простор на виртуелната мрежа, плус партнерски мрежи каде е дозволен транзит низ портата и локални префикси научени преку site-to-site врска или BGP. Во тој сет нема 0.0.0.0/0. Вашиот оперативен систем ја држи стандардната рута на Wi-Fi или Ethernet, па пакетот кон јавно API воопшто не влегува во тунелот.

Адресата што клиентот ја добива внатре во тунелот е приватно изнајмување од базенот point-to-site. Ја идентификува клиентот пред ресурсите во VNet; тоа не е адреса што интернетот може да ја види и никогаш нема да се појави како извор на излезно барање до SaaS API. Записот во списокот за дозвола изграден околу тоа изнајмување не може да работи, колку и да чекате да се појави во дневниците на добавувачот.

Поделен тунел и присилно тунелирање еден до друг

Само вториот ред ја менува адресата што ја гледа оддалечена услуга. Сѐ друго во таа табела е трошок и оперативна површина што ја прифаќате кога излезот мора да се провери или преведе внатре во Azure. Ако некој ве замоли да ја промените јавната IP, тој ја бара целата десна колона, не мала дотерања на клиентот.

Има средна опција што вреди да се именува пред да изградите нешто повторно. Proxy или порта VM внатре во VNet ви дава контролирана изворна адреса за апликациите што можат да се насочат кон неа, без да ја поместите стандардната рута на клиентот. Тоа го задржува нормалното прелистување локално и сепак задоволува партнер на кој му треба само еден API повик да дојде од Azure. Не успева кога барањето навистина се однесува на целиот сообраќај, бидејќи сѐ што го игнорира поставувањето на 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 во центарот го презема сообраќајот. Огнениот ѕид ги преведува врските кон интернет во сопствените јавни IP адреси и токму од тој превод доаѓа новата излезна адреса. Кога еден огнен ѕид има неколку јавни IP, која било од нив може да се појави како извор, па списокот за дозвола мора да ги содржи сите.

Двата дизајна погоре се IPv4. Двата префикса /1 не прават ништо за IPv6, а поддршката за IPv6 кај point-to-site е доволно тесна за да го тестирате комбото пред да ветите паритет.

Проверете ја рутата, потоа излезот

Откако ќе го инсталирате пакетот повторно и ќе се поврзете, потврдете дека клиентот навистина ги инсталирал половините. На Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 и истото барање за 128.0.0.0/1 треба да го именуваат интерфејсот на тунелот, а route print ги покажува двете покрај вашата оригинална стандардна рута. На Linux ip route show мора да ги наведе двата префикса; ако не, профилот никогаш не ги пренел.

Потоа проверете ја повторно јавната адреса од клиентот и прочитајте го дневникот на огнениот ѕид за истата врска. Изворот треба да биде јавната IP на огнениот ѕид со преведен порт. Клиент што сѐ уште излегува локално додека постојат двете рути значи дека пакетите стигнале до Azure и излегле по друг пат: рута дефинирана од корисникот на подмрежата на портата, огнен ѕид што самиот е присилно тунелиран кон локалната мрежа, или политика што го отфрла текот пред преводот.

Повторно тестирајте едно приватно одредиште во истата сесија. Скок-домаќин што престанува да одговара по промената е вообичаениот знак дека новите префикси истиснале нешто, или потесна локална рута што претходно се објавуваше, или решавање на имиња што сега оди кон резолвер без препраќач за вашите приватни зони.

Кога да го оставите поделениот тунел на мир

Ако целта е само да се стигне до приватно API, приватна крајна точка или внатрешна административна страница, стандардното однесување е поевтино и потивко. Присилното тунелирање додава часови на огнениот ѕид и трошоци за обработка на податоци, подолг пат и уште едно место каде секој клиентски тек може да падне. Тоа исто така фаќа многу повеќе сообраќај отколку единственото одредиште за кое ви беше грижа.

Посегнете по него кога барањето е изразено во смисла на излез: партнерот мора да види фиксна Azure адреса, безбедноста сака врските да бидат евидентирани и прегледани, или податоците мора да излезат низ една контролирана точка. Дури и тогаш дизајнот му дава на секој корисник заеднички излез, па одговорноста по корисник мора да дојде од идентитетот во апликацијата, не од изворната адреса.

Пред да ја затворите промената, потврдете четири работи: инсталираниот клиентски пакет е новиот, двете рути /1 се на интерфејсот на тунелот, приватното одредиште сѐ уште одговара, и дневникот на оддалечената услуга ја покажува адресата на огнениот ѕид.