Pse nc -uz nuk mund të provojë se një server OpenVPN është gati

Ekzekutimi i nc -uz kundër një serveri OpenVPN pothuajse nuk mat asgjë, dhe manual i OpenBSD e thotë këtë në rezervat e tij: skanimet UDP në atë mënyrë raportojnë sukses pavarësisht nëse diçka dëgjon apo jo. Statusi i daljes pasqyron dërgimin lokal, jo gjendjen e largët, prandaj një mbikëqyrës që i beson e mban një server të vdekur të shënuar si të shëndetshëm për sa kohë tabela e proceseve duket e besueshme. Zëvendësimi fillon me vendimin se cilës pyetje duhet t’i përgjigjet kontrolli, sepse procesi, dëgjuesi, vërtetimi dhe arritshmëria e aplikacionit janë katër vëzhgime të ndryshme. Një sondë që emërton njërën prej tyre është e dobishme; një sondë që nënkupton të katërtat është barrë.

Çfarë mund dhe çfarë nuk mund të vëzhgojë një sondë UDP

nc -uz dërgon një datagram dhe del, dhe statusi që kthen përshkruan dërgimin lokal. Një port i mbyllur mund të përgjigjet me ICMP port unreachable, por sjellja e dokumentuar e këtij mënyre skanimi nuk e kthen atë në dështim, dhe një port i filtruar nuk jep fare përgjigje. Prandaj heshtja dhe suksesi nënkuptojnë të njëjtën gjë për thirrësin.

Kjo e bën sondën një test të stivës lokale, jo të serverit. Ajo nuk vërteton se hosti është i arritshëm, se porti është i lidhur, se procesi OpenVPN po punon apo se një klient mund të vërtetohej. Një test lidhjeje TCP është më i fortë, sepse shtrëngimi i duarve jep një përgjigje të qartë, por vetëm kur vendosja dëgjon vërtet në TCP. Kalimi i sondës në TCP në të njëjtin numër teston një dëgjues që mund të mos ekzistojë, dhe kundër një serveri vetëm me UDP do të dështojë një shërbim të shëndetshëm.

Përputhja e sondës me transportin e konfiguruar vjen përpara besimit në cilindo nga dy rezultatet. Një vendosje UDP ka nevojë për një sinjal tjetër, jo për një protokoll tjetër.

Tre thirrës, tre pyetje të ndryshme

Gatishmëria varet nga kush pyet. Menaxheri i shërbimit që rinis një proces të rrëzuar duhet të dijë se instanca filloi dhe lidhi dëgjuesin e saj. Balancuesi i ngarkesës duhet të dijë se një klient që vjen tani do të pranohej. Sistemi i monitorimit duhet të dijë se rruga nga një rrjet i vërtetë ende mbart një sesion drejt një burimi të lejuar.

Këto nuk janë i njëjti kontroll, dhe një sondë nuk mund t’i mbulojë të treja me ndershmëri. Zgjidhni së pari thirrësin, pastaj provën.

Ndërtoni sondën nga instanca aktuale

OpenVPN shkruan një rresht nisjeje kur një instancë përfundon inicializimin, dhe ai rresht është provë e dobishme për nisjen lokale. Lexojeni nga nisja aktuale dhe jo nga fundi i një skedari që shtohet, sepse një sukses i javës së kaluar lexohet saktësisht si një sukses i një minute më parë. Një server mund ta përfundojë inicializimin edhe para se ndonjë klient të jetë lidhur ndonjëherë, prandaj rreshti nuk thotë asgjë për vërtetimin.

Për një kontroll nisjeje, bashkoni gjendjen e procesit me provën aktuale të regjistrit dhe një dëgjues që përputhet me transportin e konfiguruar. Kontrolli duhet të dështojë kur procesi po punon, por nuk e ka përfunduar inicializimin, që do të thotë se pyetja në regjistër duhet të kufizohet në këtë nisje dhe këtë njësi.

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

Tre dalje, tre pohime: njësia është aktive, kjo nisje prodhoi rreshtin e inicializimit, dhe diçka mban portin UDP. Asnjëra prej tyre nuk thotë se një klient mund të lidhet. Mbani ato të ndara në faqen e statusit, që një incident të mos shembet në një pikë të gjelbër.

Thyejeni qëllimisht dhe shikoni sondën

Një sondë është e besueshme vetëm pasi ta keni parë të dështojë. Ndaloni serverin, ekzekutoni sondën dhe konfirmoni rezultatin që prisni. Më pas rinisni atë dhe konfirmoni se sonda rikuperohet pa asnjë ndryshim tjetër.

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

Lexoni bllokun rresht për rresht. Komanda netcat shtyp exit=0 ndërsa asgjë nuk është e lidhur, dhe ky është i gjithë problemi në një rresht. I pari ss nuk shtyp asgjë, rinisja ka sukses, dhe i dyti ss tregon përsëri dëgjuesin. Nëse sonda juaj kalon kundër serverit të ndalur, ajo po mat stivën lokale dhe asgjë tjetër.

Dështimi i kundërt gjithashtu ka rëndësi. Një sondë që dështon kundër një serveri të shëndetshëm shkakton rinisje që nuk ishin kurrë të nevojshme, dhe një cikël rinisjesh është në vetvete një ndërprerje. Testoni të dy drejtimet përpara se ta lidhni sondën me diçka që mund të veprojë mbi të.

Çfarë duhet të thotë rreshti i statusit

Shënoni cilën kufi mbulon çdo kontroll: proces, dëgjues, vërtetim ose aplikacion. Një kontroll rrallë mbulon më shumë se një, dhe një faqe statusi që i ngjesh në “up” fsheh ndryshimin që ka rëndësi gjatë një incidenti. Për rrugën e rrjetit, përdorni një klient të vërtetë me identitet të dedikuar, lëreni të përfundojë shtrëngimin e duarve dhe një veprim të lejuar të padëmshëm, pastaj shkëputeni. Kjo ushtron kanalin e kontrollit, politikën e vërtetimit dhe dëgjuesin në një hap.

Mbani atë identitet të ndarë nga përdoruesit e vërtetë dhe jepini lejet minimale që i nevojiten kontrollit. Një sondë gatishmërie me akses të gjerë është një sipërfaqe e re sulmi e shtuar për lehtësi. Rrotulloni kredencialet e saj si për çdo llogari tjetër, sepse një sondë që ndalon së vërtetuari duket saktësisht si një server që ndaloi së pranuari klientë.

Emërtoni kufirin në tekstin e alarmit, që i pari që përgjigjet të dijë nëse duhet të shohë njësinë, soketin, certifikatën apo rrugën. Një sondë që nuk mund të thotë çfarë provoi do të besohet për arsyen e gabuar, dhe kështu kontrolli me netcat mbijetoi në radhë të parë.