Защо 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 проверката е оцеляла на първо място.