Чаму 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-праверка выжыла ў першую чаргу.