Kāpēc nc -uz nevar pierādīt, ka OpenVPN serveris ir gatavs

Palaižot nc -uz pret OpenVPN serveri, gandrīz nekas netiek izmērīts, un OpenBSD rokasgrāmata to saka savos brīdinājumos: UDP skenēšana šajā režīmā ziņo par panākumiem neatkarīgi no tā, vai kaut kas klausās. Izejas statuss atspoguļo lokālo sūtīšanu, nevis attālo stāvokli, tāpēc uzraugs, kas tam uzticas, tur mirušu serveri atzīmētu kā veselu tik ilgi, kamēr procesu tabula izskatās ticama. Aizstāšana sākas ar lēmumu, uz kuru jautājumu pārbaudei jāatbild, jo process, klausītājs, autentifikācija un lietotnes sasniedzamība ir četri dažādi novērojumi. Pārbaude, kas nosauc vienu no tiem, ir noderīga; pārbaude, kas norāda uz visiem četriem, ir nasta.

Ko UDP pārbaude var un ko nevar novērot

nc -uz nosūta datagrammu un beidz darbu, un atgrieztais statuss apraksta lokālo sūtīšanu. Slēgts ports var atbildēt ar ICMP port unreachable, bet šī skenēšanas režīma dokumentētā uzvedība to nepārvērš neveiksmē, un filtrēts ports vispār neatbild. Tāpēc klusums un panākumi zvanītājam nozīmē vienu un to pašu.

Tas pārbaudi padara par lokālā steka, nevis servera testu. Tā nenosaka, ka saimnieks ir sasniedzams, ka ports ir piesaistīts, ka OpenVPN process darbojas vai ka klients varētu autentificēties. TCP savienojuma tests ir spēcīgāks, jo rokasspiediens dod skaidru atbildi, bet tikai tad, kad izvietojums patiešām klausās TCP. Pārbaudes pārcelšana uz TCP tajā pašā numurā pārbauda klausītāju, kura var nebūt, un pret serveri, kas darbojas tikai ar UDP, tā liks ciest veselam pakalpojumam.

Pārbaudes saskaņošana ar konfigurēto transportu nāk pirms uzticēšanās jebkuram no diviem rezultātiem. UDP izvietojumam vajadzīgs cits signāls, nevis cits protokols.

Trīs zvanītāji, trīs dažādi jautājumi

Gatavība ir atkarīga no tā, kas jautā. Pakalpojuma pārvaldniekam, kas restartē avarējušu procesu, jāzina, ka instance ir startējusi un piesaistījusi savu klausītāju. Slodzes balansētājam jāzina, ka klients, kas ierodas tagad, tiktu pieņemts. Uzraudzības sistēmai jāzina, ka ceļš no reāla tīkla joprojām nes sesiju uz atļautu resursu.

Tās nav viena un tā pati pārbaude, un viena pārbaude nevar godīgi aptvert visas trīs. Vispirms izvēlieties zvanītāju, pēc tam pierādījumu.

Veidojiet pārbaudi no pašreizējās instances

OpenVPN ieraksta starta rindu, kad instance pabeidz inicializāciju, un šī rinda ir noderīgs pierādījums par lokālo startu. Lasiet to no pašreizējā starta, nevis no pievienotās faila beigām, jo pagājušās nedēļas panākumi nolasās tieši tāpat kā pirms minūtes gūti panākumi. Serveris var arī pabeigt inicializāciju pirms tam, kad kāds klients jebkad ir pievienojies, tāpēc rinda neko nepasaka par autentifikāciju.

Starta pārbaudei savienojiet procesa stāvokli ar pašreizējo žurnāla pierādījumu un klausītāju, kas atbilst konfigurētajam transportam. Pārbaudei jācieš neveiksme, kad process darbojas, bet nav pabeidzis inicializāciju, kas nozīmē, ka žurnāla vaicājums jāierobežo ar šo startu un šo vienību.

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

Trīs izvades, trīs apgalvojumi: vienība ir aktīva, šis starts radīja inicializācijas rindu, un kaut kas tur UDP portu. Neviens no tiem nesaka, ka klients var pievienoties. Turiet tos atsevišķi statusa lapā, lai incidents nesabruktu vienā zaļā punktā.

Salauziet to tīši un vērojiet pārbaudi

Pārbaude ir uzticama tikai tad, kad esat redzējuši, kā tā cieš neveiksmi. Apturiet serveri, palaidiet pārbaudi un apstipriniet gaidīto rezultātu. Pēc tam startējiet to vēlreiz un apstipriniet, ka pārbaude atjaunojas bez jebkādām citām izmaiņām.

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

Lasiet bloku rindu pēc rindas. Netcat komanda izdrukā exit=0 , kamēr nekas nav piesaistīts, un tā ir visa problēma vienā rindā. Pirmā ss neizdrukā neko, restarts izdodas, un otrā ss atkal parāda klausītāju. Ja jūsu pārbaude iztur pret apturēto serveri, tā mēra lokālo steku un neko citu.

Pretējā neveiksme arī ir svarīga. Pārbaude, kas cieš neveiksmi pret veselu serveri, izraisa restartus, kas nekad nebija vajadzīgi, un restartu cilpa pati par sevi ir pārtraukums. Pārbaudiet abus virzienus, pirms pievienojat pārbaudi kaut kam, kas var uz to reaģēt.

Ko statusa rindai vajadzētu teikt

Pierakstiet, kādu robežu sedz katra pārbaude: process, klausītājs, autentifikācija vai lietotne. Viena pārbaude reti sedz vairāk nekā vienu, un statusa lapa, kas tās saspiež “up”, slēpj atšķirību, kas incidenta laikā ir svarīga. Tīkla ceļam izmantojiet īstu klientu ar atsevišķu identitāti, ļaujiet tam pabeigt rokasspiedienu un vienu nekaitīgu atļautu darbību, pēc tam atvienojiet. Tas vienā solī trenē vadības kanālu, autentifikācijas politiku un klausītāju.

Turiet šo identitāti atsevišķi no īstiem lietotājiem un dodiet tai minimālās atļaujas, kas pārbaudei vajadzīgas. Gatavības pārbaude ar plašu piekļuvi ir jauna uzbrukuma virsma, kas pievienota ērtības dēļ. Rotējiet tās akreditācijas datus kā jebkuram citam kontam, jo pārbaude, kas pārstāj autentificēties, izskatās tieši tāpat kā serveris, kas pārstājis pieņemt klientus.

Nosauciet robežu brīdinājuma tekstā, lai pirmais reaģētājs zinātu, vai skatīties uz vienību, ligzdu, sertifikātu vai maršrutu. Pārbaudei, kas nevar pateikt, ko tā pierādīja, uzticēsies nepareiza iemesla dēļ, un tieši tā netcat pārbaude sākotnēji izdzīvoja.