Зошто 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 проверката опстана во прв ред.