Зашто 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 провера уопште преживела.