Тұрақты OpenVPN мекенжайлары сәйкестікке сүйенуі керек, бастапқы IP-ге емес

«Бұл ноутбук 10.90.0.10 алады» дейтін мекенжай жоспарлары шын мәнінде сәйкестік туралы мәлімдемелер: қай расталған құрылғы бұл мекенжайды ұстай алады. Сол құрылғының қазіргі жария IP-інің бұған еш қатысы жоқ, өйткені NAT және роуминг пайдаланушының кім екенін өзгертпей-ақ оны өзгертеді. Жоспарды бастапқы мекенжайға құру бірінші қонақүй желісінде бұзылатын ережелерді тудырады. Оны расталған сәйкестікке құру сапарға төтеп беретін жоспар жасайды.

Сервер тексере алатыннан бастаңыз, содан кейін мекенжайдың не үшін екенін шешіңіз.

Мекенжайдан бұрын сәйкестік кілтін таңдаңыз

Әр құрылғыға жеке клиент сертификаты серверге әр мүшеге тұрақты, тексерілетін кілт береді, бұл статикалық тағайындауға таза негіз. Пайдаланушы бойынша аутентификацияны қолданатын орналастыру оның орнына пайдаланушы атына сүйенуі мүмкін, егер конфигурация таңдауы сол өріске бағынса. Екі модельді араластыру бір клиентке сертификатқа, екіншісіне пайдаланушы атына сәйкес келетін тағайындаулар жасайды және қайсысы жеңетінін ешкім болжай алмайды. Бір резервтеуді жазбас бұрын жоспардың қай кілтті қолданатынын шешіңіз.

duplicate-cn кезінде бірнеше қатар жүрген сессиялар бір ортақ атауды ұсына алады, сондықтан бір бекітілген мекенжай оларды жеке анықтай алмайды. Бұл сәйкестік моделінің қасиеті, жақсырақ мекенжай жоспары түзете алатын нәрсе емес.

Мекенжайларды динамикалық диапазоннан тыс резервтеңіз

10.90.0.0/24 сияқты ішкі желі топологиясы бар желіде төменгі мекенжайларды аталған мүшелерге қалдырып, динамикалық пулды бөлек диапазонға қойыңыз. Бекітілген мүшеге тағайындау сервер сол сәйкестік үшін таңдайтын файлда былай көрінеді: ifconfig-push 10.90.0.10 255.255.255.0. Екінші аргумент net30 жағдайында басқа мағына береді, сондықтан мысал топологияға қатысты бейтарап емес. Көшіруден бұрын топологияны оқыңыз.

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

Тағайындау басымдығы кім жеңетінін шешеді

Нұсқаулық тәртіпті құжаттайды: client-connect кезінде жасалған айқын тағайындау client-config-dir жазбасынан бұрын күшіне енуі мүмкін, ол өз кезегінде әдеттегі пул бөлуден бұрын келеді. Бұл тәртіп «бекітілген мекенжай қолданылмады» деген есептердің көбін түсіндіреді. Бұл сондай-ақ әр сессия үшін конфигурация жазатын динамикалық бөлгіш сіз беделді деп санаған статикалық файлды үнсіз басып кете алатынын білдіреді.

Тағайындауларды иеленетін бір қабатты таңдаңыз, қалғандарын тек оқуға болатын етіңіз. Екеуі де шешім қабылдаймын деп мәлімдейтін екі қабат уақытқа тәуелді тағайындаулар жасайды.

Динамикалық бөлгішке де сол модель керек

Әр сессияға мекенжайлар тарататын client-connect интеграциясы әдеттегі бөлгіш мәселелері бар шағын бөлгіш. Ол сұраушы сәйкестікті тексеруі, мекенжайды атомдық түрде резервтеуі, тек қолдау көрсетілетін қосылымдық шығысты шығаруы және ажырату немесе сәтсіздік кезінде резервтеуді босатуы керек. Қатар келген сұраныстарға құлып немесе дерекқор шектеуі керек, оқу-содан кейін жазу тізбегі емес. Тазалаусыз пул қайта іске қосылғанша мекенжайларды ағызады.

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

Мекенжай саясат па әлде ыңғайлылық па екенін шешіңіз

Егер брандмауэр ережесі немесе маршрут бір туннель мекенжайынан трафикті рұқсат етсе, онда мекенжай қатынау саясатына қатысады және қайта тағайындау сол рұқсатты мұралайды. Сәйкестік, мекенжай және брандмауэр өмірлік циклін үйлестіріңіз немесе ережені қайта тағайындауға болмайтын нәрсеге байлаңыз. Тұрақты мекенжайлау конфигурацияны оқылатын етеді; ол аутентификацияны алмастырмайды.

Жоспарды әр жазба үшін иесі бар тізім ретінде жазыңыз, содан кейін құрылғы пайдаланудан шығарылғанда оны қайта қараңыз. Пайдаланылмаған резервтеу — кездейсоқ қайта пайдаланылатын резервтеу.