Статичен IP в Azure P2S VPN: защо адресът на клиента се променя

Всеки клиент на Azure point-to-site получава адрес от пула при удостоверяване и го запазва само за времетраенето на тази връзка. Няма таблица за резервации, няма съпоставяне по потребител и няма настройка на шлюза, която да означава „винаги давай на този човек 172.16.0.10“. Именно този единствен механизъм обяснява двата симптома, на които хората се натъкват по-късно: правило в NSG, което спира да съвпада с потребител, с когото преди е съвпадало, и списък за разрешаване, който тихомълком допуска машина, която никой не е добавил нарочно. Замяната на правилото с по-умно IP правило не поправя нито едно от двете, защото това, което правилото назовава, се преразпределя по график, който не контролирате.

Пулът е капацитет, не идентичност. Той съществува, за да получават едновременните тунели уникални адреси, и ги рециклира в момента, в който наемът приключи. Щом това е ясно, полезният въпрос престава да бъде „как да закова този клиент“ и става „срещу какво мога да напиша правило, което шлюзът няма да рециклира“.

Какво всъщност прави шлюзът, когато клиент се свърже

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

Размерът на пула прикрива поведението. Лабораторен пул с един-два адреса повече от броя на тестерите изглежда детерминиран, защото същият лаптоп обикновено се свързва в един и същ ред всяка сутрин. Добавете трета машина, променете размера на пула или оставете сесия свързана по обяд и моделът се чупи. Адресът никога не е бил стабилен; опашката беше.

Всяка промяна в конфигурацията на point-to-site също нулира пространството за наеми. Друг тип удостоверяване, променен размер на пула, нов диапазон на пула или шлюз, който е разрушен и изграден наново, връщат клиентите в пул, който вече не съответства на старите им адреси. Нищо в тази промяна не докосва вашия NSG и затова счупването изглежда спонтанно.

Можете да го наблюдавате за около минута. Свържете се, запишете тунелния адрес в подробностите за връзката на клиента, разкачете се, свържете втора машина, после свържете отново първата. Адресът, който получавате, зависи от това какво държи втората машина, и никоя настройка в портала няма да възстанови предишния при поискване.

NSG, обвързан с IP на клиента, всъщност е правило за реда на свързване

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

Следват два режима на отказ и само единият изглежда като дефект. Законен потребител бива отказан, защото някой друг в момента държи адреса, който правилото назовава, и това пристига като досаден тикет в поддръжката. Или нежелан потребител бива допуснат, защото е наследил адрес, на който правилото все още се доверява, и това не пристига като нищо, докато някой не одитира достъпа.

Тъй като правилото следва наема, ефективната политика гласи „първият, който се свърже, получава административен достъп“. Това е описание на реда на свързване, преоблечено като намерение, и никаква хигиена на правилата не го прави израз на намерение.

Наемът на клиента и адресът на шлюза са различни обекти

Повечето объркване идва от една дума. Шлюзът има публичен IP, който е относително стабилен; клиентите имат частни адреси от пула, които не са. За шлюз VPN без зонова избыточност публичният IP се разпределя динамично, но преживява промяна на размера, нулиране и рутинна поддръжка — променя се, когато самият шлюз бъде изтрит и създаден наново. Зоново избыточните и зоналните SKU на шлюза използват публичен IP от Standard SKU и това разпределение трябва да е статично.

Тази стабилност е това, което локалният партньор има нужда в конфигурацията си, и тя не казва нищо за идентифицирането на отделен клиент. Когато партньор попита кой адрес ще види, отговорът е публичният IP на шлюза при site-to-site или споделен NAT диапазон — никога наемът на тунела на лаптоп.

Груповите пулове ви дават диапазон, срещу който си струва да се пишат правила

Virtual WAN point-to-site поддържа потребителски групи и на всяка група може да се назначи собствен пул от адреси на клиенти. Членството се определя от идентичност, така че диапазонът, в който попада клиент, става предвидим: операциите в един диапазон, изпълнителите в друг, а диапазонът е нещо, което правило на защитна стена или NSG може да назове без догадки.

Полученият набор от правила има форма, която можете да прегледате:

• един пул на аудитория, оразмерен за пикови едновременни сесии, а не за брой хора;
• членството в група се управлява чрез идентичност, не чрез редактиране на правила при всяко присъединяване;
• правила на NSG или Azure Firewall, писани срещу диапазони на пула, никога срещу отделни наеми;
• отделен хъб или шлюз за аудитории, които никога не бива да споделят диапазон.

Разрешаването на цял пул е честно, но грубо: всеки свързан клиент в този диапазон получава еднакъв достъп. Това е политическо решение, което си струва да се каже на глас, вместо да се открие при преглед. Всичко, което все още изисква отговор за всеки отделен човек, принадлежи на ресурса, чрез назначения на роли, а не на филтъра на пакетите.

Когато внедряването не може да премине към Virtual WAN

Много шлюзове остават обикновени шлюзове VPN и преминаването към Virtual WAN не е незначителна промяна. Практичният отговор е решението за всеки потребител да се премести от филтъра на пакетите върху нещо, което вече знае кой е потребителят.

Идентичността на ниво ресурс е най-евтиният вариант. Storage, SQL и Key Vault поддържат удостоверяване с Entra ID с назначения на роли за потребител или група, така че VPN трябва само да докаже мрежова достижимост. Скоков хост с именувани акаунти върши същата работа за административни задачи, защото хостът записва човека, а тунелът само пренася пакети. Регистрирането на клиентите в DNS и разрешаването на името, а не на номера, премества правилото едно ниво нагоре. Идентичността на ниво приложение — тема на сертификат, твърдение в токен, членство в група — работи, когато приложението, а не мрежата, е това, което е помолено да реши.

За партньор, който настоява на фиксиран адрес на източника, отговорът е site-to-site или ExpressRoute с определен префикс на партньора. Те разрешават префикса на партньора, адресът, който се появява от тяхната страна, принадлежи на шлюза и не се променя, когато някой рестартира лаптоп.

Проверете пула, преди да редактирате поредния списък за разрешаване

Две свойства на пула причиняват повечето от поведението, за което хората обвиняват клиента. Твърде малкият пул рециклира наемите бързо, така че адресите изглеждат постоянно движещи се и всяко правило, основано на адрес, изглежда нестабилно по замисъл. Пул, който се припокрива с локалните диапазони или с адресното пространство на виртуалната мрежа, създава двусмислие в маршрутизацията, което никое правило на защитна стена не поправя.

Сложете три неща на една страница, преди да докоснете правило: пула point-to-site, адресното пространство на виртуалната мрежа и локалните диапазони. Те не бива да се припокриват, а пулът има нужда от място за всеки едновременен клиент плюс резерв за повторни свързвания.

След това затворете цикъла в този ред:

• Свържете се от две машини в двата реда и сравнете адресите; ако могат да се разменят, никое правило, основано на адрес, не е безопасно.
• Проверете дали шлюзът е Virtual WAN; ако е, използвайте групови пулове вместо правила за отделен адрес.
• Попитайте какво се случва, когато правило съвпадне с грешния човек; ако отговорът е инцидент с достъпа, преместете контрола към идентичността.
• Запишете кой диапазон принадлежи на коя група в същото хранилище като дефинициите на NSG.
• Тествайте отново след всяка промяна на пула, удостоверяването или шлюза, защото тези промени пренаписват съпоставянето, без да го обявяват.