Защо Azure VPN „точка към сайт“ не променя публичния ви IP адрес

Свързвам клиента Azure VPN на лаптоп с Windows, отварям страница за отразяване на адреса и виждам същия публичен адрес, който домашният ми рутер е раздал. Междувременно скоковата машина на 10.20.0.4 отговаря и име на частна крайна точка се разрешава, значи тунелът не е счупен. Шлюзът „точка към сайт“ прави точно това, което казва конфигурацията му по подразбиране: пренася частните префикси и оставя всичко останало на локалната връзка. Получаването на изходящ адрес, притежаван от Azure, е промяна в дизайна на маршрутизацията, а не ремонт.

Какво обявява шлюзът по подразбиране

Шлюзът разпространява маршрути за адресното пространство на виртуалната мрежа, плюс партньорски мрежи, където е разрешен транзит през шлюза, и локални префикси, научени през връзка „сайт към сайт“ или BGP. В този набор няма 0.0.0.0/0. Операционната ви система запазва маршрута си по подразбиране на Wi-Fi или Ethernet, затова пакет към публичен API изобщо не влиза в тунела.

Адресът, който клиентът получава в тунела, е частен наем от пула „точка към сайт“. Той идентифицира клиента пред ресурсите в VNet; това не е адрес, който интернет може да види, и никога няма да се появи като източник на изходяща заявка към SaaS API. Запис в списък за разрешение, изграден около този наем, не може да работи, колкото и дълго да чакате да се появи в журналите на доставчика.

Разделен тунел и принудително тунелиране едно до друго

Само вторият ред променя адреса, който вижда отдалечена услуга. Всичко останало в тази таблица е цена и оперативна повърхност, които приемате, когато изходът трябва да се инспектира или транслира в Azure. Ако някой ви помоли да промените публичния IP, той иска цялата дясна колона, а не дребна корекция на клиента.

Има междинен вариант, който си струва да се назове, преди да преустроите нещо. Прокси или шлюзова VM във VNet ви дава контролиран адрес на източника за приложенията, които могат да бъдат насочени към нея, без да местите маршрута по подразбиране на клиента. Така обикновеното разглеждане остава локално и пак удовлетворява партньор, който се нуждае само от едно API извикване от Azure. Проваля се, когато изискването наистина е за целия трафик, защото всичко, което пренебрегне прокси настройката, пак излиза локално.

Накарайте тунела да носи маршрута по подразбиране

На шлюз за виртуална мрежа поддържаният начин да насочите целия интернет трафик на клиента в тунела е да добавите персонализирани маршрути към конфигурацията „точка към сайт“. Две половини покриват цялото IPv4 пространство и всяка е по-специфична от локалния маршрут по подразбиране, затова клиентът ги предпочита, без да изтрива нищо:

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

Този ред е илюстративен, а не готов за копиране: първо вземете обекта на шлюза с Get-AzVirtualNetworkGateway и го поставете вместо GWOBJ, и потвърдете, че SKU и моделът на разгръщане приемат персонализирани маршрути, преди да го изпълните. Същите префикси се появяват в портала на страницата за конфигурация „точка към сайт“, което е по-безопасното място да ги зададете, ако още не управлявате шлюза със скриптове.

Промяната на тези префикси обезсилва клиентския пакет. Изтеглете отново пакета на VPN клиента и го преинсталирайте, защото маршрутите пътуват в профила. Клиент, който се свърже отново със стария профил, запазва стария набор от маршрути и може да загубите час в отстраняване на промяна, която така и не е стигнала до него.

В защитен център на виртуална WAN еквивалентът е маршрут по подразбиране в таблицата с маршрути на центъра, свързана с шлюза „точка към сайт“, като трафика поема Azure Firewall в центъра. Защитната стена транслира връзките към интернет към собствените си публични IP адреси и именно от тази транслация идва новият изходящ адрес. Когато една защитна стена има няколко публични IP, всеки от тях може да се появи като източник, затова списъкът за разрешение трябва да съдържа всички.

И двата дизайна по-горе са IPv4. Двата префикса /1 не правят нищо за IPv6, а поддръжката на IPv6 при „точка към сайт“ е достатъчно тясна, че да тествате комбинацията, преди да обещаете паритет.

Проверете маршрута, после изхода

След преинсталиране на пакета и повторно свързване потвърдете, че клиентът наистина е инсталирал половините. В 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 са на тунелния интерфейс, частна дестинация все още отговаря и журналът на отдалечената услуга показва адреса на защитната стена.