Зашто 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, а point-to-site подршка за IPv6 је довољно уска да комбинацију треба тестирати пре него што обећате паритет.

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

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

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

Поново тестирајте једно приватно одредиште у истој сесији. Скок-домаћин који престане да одговара после промене уобичајен је знак да су нови префикси нешто потиснули: или ужу локалну руту која се раније објављивала, или разрешавање имена које сада иде ка resolver-у без прослеђивача за ваше приватне зоне.

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

Ако је циљ само да стигнете до приватног API-ја, приватне крајње тачке или интерне административне странице, подразумевано понашање је јефтиније и тише. Присилно тунелирање додаје сате заштитног зида и трошкове обраде података, дужи пут и још једно место где сваки клијентски ток може да падне. Оно такође хвата много више саобраћаја од јединог одредишта за које сте бринули.

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

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