Windows-та OpenVPN адаптері қайта-қайта үзілуде ме? Қосарланған IP-ны тексеріңіз

Windows-та мекенжайды алып, оны тастап, әр бірнеше секунд сайын мұны қайталайтын OpenVPN адаптері әдетте DHCP қатесі емес. Адаптерге басқа бірдеңе жауап беріп тұрған мекенжайды пайдалану тапсырылады, сондықтан Windows оны жарамсыз деп белгілейді де, клиент қайтадан бастайды. Клиент журналы үнсіз қалады, өйткені қақтығыс оның астында, операциялық жүйенің өз желілік стекінде шешіледі.

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

Клиент журналынан емес, Windows оқиғалар журналынан бастаңыз

Windows мекенжай қақтығыстарын жүйелік журналға 4198 және 4199 оқиға ID-лерімен жазады. Біріншісі мекенжай үшін анықталған қақтығысты хабарлайды, екіншісі интерфейстің өзі конфигурацияланған мекенжайды пайдалана алмағанын хабарлайды. Екеуі де OpenVPN-ды атамайды, сондықтан оларды байқамау оңай.

Соңғы оқиғаларды алып, олардың уақыт белгілерін адаптердің жаңарту циклімен салыстырыңыз: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Әр он бес секунд сайынғы қақтығыс сол мекенжайға жауап беруді жалғастыратын иеге қарсы бір мекенжайды қайта сынап жатқан клиентке сәйкес келеді. Қосылу кезіндегі жалғыз қақтығыс керісінше біржолғы соқтығысқа нұсқайды. Қалай болғанда да, келесі сұрақ — мекенжайды тағы кім ұстап тұр.

Үш орналасу екі хостты бір мекенжайға қояды

Серверден мекенжайды кім ұстап тұр деп ойлайтынын сұраңыз, содан кейін желіден оған кім жауап беретінін сұраңыз. grep -H ifconfig-push /etc/openvpn/ccd/* әр бекітілген туннель мекенжайын және ол тиесілі сертификатты тізіп шығады. ip -4 neigh show dev tap0 көпірдің екінші деңгейде не үйренгенін көрсетеді. Осы екі тізімді салыстыру қосарланулардың көбін бір минуттан аз уақытта табады.

Үш орналасу олардың барлығын дерлік түсіндіреді: client-config-dir жазбасы екі сертификат үшін бір мекенжайды бекітеді, көпірленген tap сегменті машинаға басқа хостта статикалық түрде бар мекенжайды береді, немесе ескірген жалдау файлы әлі қосылған клиент өзінікі деп есептейтін мекенжайды қайтарады. Үшінші жағдай ең қулық, өйткені ifconfig-pool-persist белгілі клиенттер үшін мекенжайларды әдейі қайта пайдаланады.

Мекенжай үшін жарысудың орнына оны бірегей етіңіз

Жүктеу тәртібі тек бүгін кім жеңетінін шешеді, сондықтан қайта жүктеу ретіне негізделген кез келген түзетуді уақытша деп қараңыз. Әр клиентке өзінің ifconfig-push жолын беріңіз немесе ешбір көпір немесе сервер интерфейсі тимейтін ауқымнан статикалық мекенжайлар бөліңіз. Клиенттер тізімін қосарланған ортақ атауларға да тексеріңіз, өйткені duplicate-cn екі сессияға бір сәйкестікті және сол арқылы бір бекітілген мекенжайды бөлісуге мүмкіндік береді. Егер көпірленген құрылғыға шынымен тұрақты мекенжай керек болса, оны өз ішкі желісіне көшіріңіз немесе сервер жазатын жерде пулдан қорыққа қалдырыңыз.

persist файлын қандай жалдауларды ұстайтынын білгеннен кейін ғана жойыңыз, әйтпесе келесі қайта қосылу сол мекенжайларды қайта таратады.

Дұрыс тәртіппен қайта жүктеп, әр мекенжайға бір иесін растаңыз

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

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

Билетті жаппас бұрын толық жаңарту циклін бақылаңыз

Бір таза оқу ештеңені дәлелдемейді. Адаптерді кемінде он минут бақылап, ортасында қайта қосылуды мәжбүрлеңіз: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Мекенжай қайта қосылудан аман өтіп, қалаған күйде қалуы керек.

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

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