Azure P2S VPN ішіндегі статикалық IP: клиент мекенжайы неге өзгереді

Әрбір Azure point-to-site клиенті аутентификация кезінде пулдан мекенжай алады және оны тек сол қосылымның ұзақтығында ғана ұстайды. Резервтеу кестесі де, пайдаланушы бойынша салыстыру да, «бұл адамға әрқашан 172.16.0.10 бер» дегенді білдіретін шлюз параметрі де жоқ. Дәл осы бір механизм адамдар кейінірек кездесетін екі белгіні түсіндіреді: бұрын сәйкес келген пайдаланушыға енді сәйкес келмейтін NSG ережесі және ешкім әдейі қоспаған машинаны үнсіз жіберетін рұқсат тізімі. Ережені ақылдырақ IP ережемен ауыстыру екеуін де түзетпейді, өйткені ереже атайтын нәрсе сіз бақыламайтын кесте бойынша қайта тағайындалады.

Пул — сыйымдылық, сәйкестік емес. Ол бір мезгілдегі туннельдер бірегей мекенжайлар алуы үшін бар және жалдау аяқталған сәтте оларды қайта пайдаланады. Бұл анық болғанда, пайдалы сұрақ «бұл клиентті қалай бекітемін» болудан қалады да, «шлюз қайта пайдаланбайтын нәрсеге қарсы қандай ереже жаза аламын» болады.

Клиент қосылғанда шлюз шын мәнінде не істейді

Шлюз конфигурацияланған клиент мекенжайларының пулын ұстайды және оны жалдау кестесі ретінде қарастырады. Қосылу кезінде келесі бос мекенжайды, іс жүзінде ең төмен қолжетімдісін алады да, клиент ажыратылғанша немесе жалдау біткенше оны туннель адаптеріне тағайындайды. Шешімді тәртіп қабылдайды, сәйкестік емес: тыныш кезеңнен кейін бірінші қосылған адам сол сәтте кездейсоқ бос болған ең төмен мекенжайды алады.

Пулдың өлшемі мінез-құлықты жасырады. Тестілеушілер санынан бір-екі мекенжайға үлкен зертханалық пул детерминді болып көрінеді, өйткені сол ноутбук әр таңда бірдей тәртіппен қайта қосылады. Үшінші машина қосыңыз, пул өлшемін өзгертіңіз немесе түскі ас кезінде сессияны қосылған күйде қалдырыңыз — үлгі бұзылады. Мекенжай ешқашан тұрақты болған емес; кезек тұрақты болды.

point-to-site конфигурациясының кез келген өзгерісі жалдау кеңістігін де қалпына келтіреді. Басқа аутентификация түрі, өлшемі өзгерген пул, жаңа пул ауқымы немесе бұзылып қайта салынған шлюз — бәрі клиенттерді ескі мекенжайларына сәйкес келмейтін пулға қайтарады. Бұл өзгерістің ешбір бөлігі сіздің NSG-ге қатыспайды, сондықтан ақау өздігінен пайда болғандай көрінеді.

Мұны шамамен бір минутта байқауға болады. Қосылыңыз, клиенттің қосылым мәліметтеріндегі туннель мекенжайын жазып алыңыз, ажыратыңыз, екінші машинаны қосыңыз, содан кейін біріншісін қайта қосыңыз. Қайтарылатын мекенжай екінші машина ұстап тұрған нәрсеге байланысты және ешбір портал параметрі алдыңғысын сұраныс бойынша қалпына келтірмейді.

Клиент IP-сіне негізделген NSG шын мәнінде қосылу тәртібі туралы ереже

Адамдар бірінші жазатын ереже айқын: басқару VM-нің NIC-іне немесе оның ішкі желісіне кіретін ереже, дереккөз ретінде VPN клиентінің ішкі мекенжайы. Ол қысқа, жазылған күні тесттен өтеді және пулда бірден көп бос мекенжай болғанда бірден істен шығады.

Осыдан екі ақау режимі шығады және олардың тек біреуі қатеге ұқсайды. Заңды пайдаланушыға бас тартылады, өйткені ереже атайтын мекенжайды сол сәтте басқа біреу ұстап тұр, және бұл мазасыз қолдау билеті ретінде келеді. Немесе ниет етілмеген пайдаланушы жіберіледі, өйткені ол ереже әлі сенетін мекенжайды мұра еткен, және бұл біреу қатынауды тексермейінше ештеңе ретінде келмейді.

Ереже жалдауды ұстанатындықтан, тиімді саясат «бірінші қосылған адам басқару қатынауын алады» деп оқылады. Бұл ниеттің киімін киген қосылу тәртібінің сипаттамасы және ешбір ереже гигиенасы оны ниетті білдіруге айналдырмайды.

Клиенттің жалдауы мен шлюз мекенжайы — әртүрлі нысандар

Шатасудың көбі бір сөзден шығады. Шлюздің салыстырмалы тұрақты жария IP-сі бар; клиенттердің пулдан алатын жеке мекенжайлары тұрақты емес. Аймақтық резервтелуі жоқ VPN шлюзі үшін жария IP динамикалық түрде бөлінеді, бірақ ол өлшем өзгерісінен, қайта жүктеуден және күнделікті қызмет көрсетуден аман қалады — ол шлюздің өзі жойылып қайта жасалғанда өзгереді. Аймақтық резервтелген және аймақтық шлюз SKU-лары Standard SKU-ның жария IP-сін пайдаланады және бұл бөлу статикалық болуы керек.

Дәл осы тұрақтылық жергілікті серіктеске конфигурациясында қажет және ол жеке клиентті сәйкестендіру туралы ештеңе айтпайды. Серіктес қандай мекенжайды көретінін сұрағанда, жауап — site-to-site кезіндегі шлюздің жария IP-сі немесе ортақ 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 анықтамаларымен бір қоймада жазыңыз.
• Пул, аутентификация немесе шлюз өзгерістерінен кейін қайта тексеріңіз, өйткені бұл өзгерістер сәйкестендіруді жарияламай-ақ қайта жазады.