Статична IP у Azure P2S VPN-у: зашто се адреса клијента мења

Сваки Azure point-to-site клијент добије адресу из скупа када се аутентификује и задржи је само док траје та веза. Нема табеле резервација, нема мапирања по кориснику и нема подешавања приступника које значи „увек дај овој особи 172.16.0.10”. Тај један механизам објашњава оба симптома на која људи касније наилазе: NSG правило које престане да одговара кориснику коме је пре одговарало, и списак дозвољених који тихо пропушта рачунар који нико није намерно додао. Замена правила паметнијим IP правилом не поправља ниједно, јер се оно што правило именује додељује према распореду који не контролишете.

Скуп је капацитет, не идентитет. Постоји зато да паралелни тунели добију јединствене адресе и рециклира их у тренутку када се најам заврши. Кад је то јасно, корисно питање престаје да буде „како да прикујем овог клијента” и постаје „према чему могу да напишем правило које приступник неће рециклирати”.

Шта приступник заиста ради када се клијент повеже

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

Величина скупа скрива понашање. Лабораторијски скуп једну или две адресе већи од броја тестера изгледа детерминистички, јер се исто преносно рачунар обично поново повезује истим редоследом сваког јутра. Додајте трећи рачунар, промените величину скупа или оставите сесију повезану током ручка и образац се распада. Адреса никада није била стабилна; стабилан је био ред.

Свака промена point-to-site конфигурације такође ресетује простор најмова. Други тип аутентификације, промењена величина скупа, нови распон скупа или приступник који се руши и поново гради — све то враћа клијенте у скуп који више не одговара њиховим старим адресама. Ништа у тој промени не дира ваш NSG, зато квар изгледа спонтано.

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

NSG везан уз IP клијента заправо је правило о редоследу повезивања

Правило које људи прво напишу је очигледно: улазно правило на NIC управљачке VM или на њену подмрежу, с унутрашњом адресом 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-а.
• Поново тестирајте након сваке промене скупа, аутентификације или приступника, јер те промене преписују мапирање без најаве.