Статична 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.
• Тестирајте повторно по секоја промена на базен, автентикација или порта, бидејќи тие промени го препишуваат мапирањето без да го најават.