Неге nc -uz OpenVPN серверінің дайын екенін дәлелдей алмайды

Іске қосу nc -uz OpenVPN серверіне қарсы іс жүзінде ештеңе өлшемейді, және OpenBSD нұсқаулығы мұны өз ескертулерінде айтады: бұл режимдегі UDP скандары бірдеңе тыңдаса да, тыңдамаса да сәттілік туралы хабарлайды. Шығу мәртебесі қашықтағы күйді емес, жергілікті жіберуді көрсетеді, сондықтан оған сенетін бақылаушы процестер кестесі сенімді көрінгенше өлі серверді сау деп белгілеп ұстайды. Оны ауыстыру тексеру қай сұраққа жауап беруі керегін шешуден басталады, өйткені процесс, тыңдаушы, аутентификация және қосымшаның қолжетімділігі төрт түрлі бақылау болып табылады. Олардың біреуін атайтын тексеріс пайдалы; төртеуін де меңзейтін тексеріс жүк.

UDP тексерісі нені байқай алады және нені байқай алмайды

nc -uz дерекграмма жіберіп, шығып кетеді, ал қайтаратын мәртебе жергілікті жіберуді сипаттайды. Жабық порт ICMP port unreachable-пен жауап беруі мүмкін, бірақ бұл сканерлеу режимінің құжатталған мінез-құлқы мұны сәтсіздікке айналдырмайды, ал сүзілген порт мүлде жауап бермейді. Сондықтан үнсіздік пен сәттілік шақырушы үшін бірдей мағына береді.

Бұл тексерісті жергілікті стектің сынағына айналдырады, сервердің емес. Ол хосттың қолжетімді екенін, порттың байланғанын, OpenVPN процесінің жұмыс істеп тұрғанын немесе клиенттің аутентификация жасай алатынын анықтамайды. TCP қосылым сынағы күштірек, өйткені қол алысу нақты жауап береді, бірақ орналастыру шын мәнінде TCP-де тыңдағанда ғана. Тексерісті сол нөмірде TCP-ге ауыстыру бар болмауы мүмкін тыңдаушыны сынайды, ал тек UDP серверіне қарсы ол сау қызметті сәтсіз етеді.

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

Үш шақырушы, үш түрлі сұрақ

Дайындық кім сұрайтынына байланысты. Құлаған процесті қайта іске қосатын қызмет менеджері дананың іске қосылғанын және өз тыңдаушысын байлағанын білуі керек. Жүктеме теңгерушісі қазір келген клиенттің қабылданатынын білуі керек. Мониторинг жүйесі нақты желіден келетін жол әлі де рұқсат етілген ресурсқа сессия тасымалдайтынын білуі керек.

Бұлар бір тексеріс емес, және бір тексеріс үшеуін де адал жаба алмайды. Алдымен шақырушыны, содан кейін дәлелді таңдаңыз.

Тексерісті ағымдағы данадан құрыңыз

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

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

Тексеріс оның сәтсіздігін көргеннен кейін ғана сенімді болады. Серверді тоқтатыңыз, тексерісті іске қосыңыз және күткен нәтижені растаңыз. Содан кейін оны қайта іске қосыңыз және тексерістің басқа өзгеріссіз қалпына келетінін растаңыз.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Блокты жол бойынша оқыңыз. netcat командасы мынаны басып шығарады exit=0 ал ештеңе байланбаған, және бұл бүкіл мәселе бір жолда. Бірінші ss ештеңе басып шығармайды, қайта іске қосу сәтті болады, ал екіншісі ss тыңдаушыны қайта көрсетеді. Егер тексерісіңіз тоқтатылған серверге қарсы өтсе, ол жергілікті стекті өлшейді, басқа ештеңені емес.

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

Күй жолы не айтуы керек

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

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

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