Zergatik ez duen nc -uz(e)k frogatzen OpenVPN zerbitzaria prest dagoenik

nc -uz OpenVPN zerbitzari baten aurka exekutatzeak ia ezer ez du neurtzen, eta OpenBSD eskuliburuak dio bere oharretan: modu horretako UDP eskaneatzeek arrakasta jakinarazten dute, entzuten duen ezer egon ala ez. Irteera-egoerak bidalketa lokala islatzen du, ez urruneko egoera, beraz hari fidatzen den gainbegiratzaile batek hildako zerbitzari bat osasuntsu markatuta mantentzen du prozesuen taula sinesgarria dirudien bitartean. Ordezkatzeak probak zein galderari erantzun behar dion erabakiz hasten da, prozesua, entzulea, autentifikazioa eta aplikazioaren irisgarritasuna lau behaketa desberdinak baitira. Horietako bat izendatzen duen proba erabilgarria da; laurak iradokitzen dituena zama da.

Zer behatu dezakeen UDP proba batek eta zer ez

nc -uz datagrama bat bidali eta irteten da, eta itzultzen duen egoerak bidalketa lokala deskribatzen du. Portu itxi batek ICMP port unreachable-rekin erantzun dezake, baina eskaneatze modu honen dokumentatutako jokabideak ez du hori hutsegite bihurtzen, eta iragazitako portu batek ez du erantzunik ematen. Beraz, isiltasunak eta arrakastak gauza bera esan nahi dute deitzailearentzat.

Horrek proba tokiko pila proba bihurtzen du, ez zerbitzariarena. Ez du ezartzen ostalaria irisgarria denik, portua lotuta dagoenik, OpenVPN prozesua martxan dagoenik edo bezero batek autentifikatu ahal izango zuenik. TCP konexio proba indartsuagoa da, esku-emateak erantzun zehatza ematen duelako, baina hedapenak benetan TCPn entzuten duenean bakarrik. Proba zenbaki berean TCPra aldatzeak agian existitzen ez den entzule bat probatzen du, eta UDP soilik duen zerbitzari baten aurka zerbitzu osasuntsu bat hutsaraziko du.

Proba konfiguratutako garraioarekin bat etortzea bi emaitzetako edozein fidatzea baino lehen dator. UDP hedapenak beste seinale bat behar du, ez beste protokolo bat.

Hiru deitzaile, hiru galdera desberdin

Prest egotea nork galdetzen duen araberakoa da. Prozesu bat berrabiarazten duen zerbitzu-kudeatzaileak jakin behar du instantzia abiatu eta bere entzulea lotu duela. Karga-balantzatzaileak jakin behar du orain iristen den bezero bat onartua izango litzatekeela. Monitorizazio-sistemak jakin behar du sare erreal batetik datorren bideak oraindik sesio bat daramala baimendutako baliabide bateraino.

Hauek ez dira proba bera, eta proba batek ezin ditu hirurak zintzotasunez estali. Aukeratu lehenik deitzailea, gero froga.

Eraiki proba uneko instantziatik

OpenVPNek abiarazte-lerro bat idazten du instantzia batek hasieratzea amaitzen duenean, eta lerro hori tokiko abiarazteari buruzko froga erabilgarria da. Irakurri uneko abiaraztetik eta ez erantsitako fitxategi baten buztinetik, joan den asteko arrakastak duela minutu bateko arrakasta bezalaxe irakurtzen baitira. Zerbitzari batek hasieratzea amaitu dezake bezero batek inoiz konektatu aurretik ere, beraz lerroak ez du ezer esaten autentifikazioari buruz.

Abiarazte-proba bat egiteko, elkartu prozesuaren egoera uneko erregistro-frogarekin eta konfiguratutako garraioarekin bat datorren entzule batekin. Probak huts egin behar du prozesua martxan dagoenean baina hasieratzea amaitu ez duenean, eta horrek esan nahi du erregistro-kontsulta abiarazte honetara eta unitate honetara mugatu behar dela.

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

Hiru irteera, hiru baieztapen: unitatea aktibo dago, abiarazte honek hasieratze-lerroa sortu du, eta zerbait UDP portua edukitzen ari da. Horietako batek ere ez du esaten bezero batek konektatu dezakeenik. Eutsi horiek bereizita egoera-orrian, gertaera bat puntu berde bakarrera ez dadin erori.

Hautsi nahita eta begiratu probari

Proba bat fidagarria da huts egiten ikusi ondoren bakarrik. Gelditu zerbitzaria, exekutatu proba eta berretsi espero duzun emaitza. Ondoren abiarazi berriro eta berretsi probak beste aldaketarik gabe errekuperatzen duela.

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

Irakurri blokea lerroz lerro. netcat komandoak hau inprimatzen du: exit=0 , ezer lotuta ez dagoen bitartean, eta hori da arazo osoa lerro bakarrean. Lehenengo ss komandoak ez du ezer inprimatzen, berrabiarazteak arrakasta du, eta bigarrenak ss entzulea erakusten du berriro. Zure probak gelditutako zerbitzariaren aurka pasatzen badu, tokiko pila neurtzen ari da eta ez beste ezer.

Aurkako hutsegitea ere garrantzitsua da. Zerbitzari osasuntsu baten aurka huts egiten duen probak inoiz behar ez ziren berrabiarazteak eragiten ditu, eta berrabiarazte-begizta bat berez da etena. Probatu bi noranzkoak proba harekin jardun dezakeen edozerekin konektatu aurretik.

Zer esan behar duen egoera-lerroak

Erregistratu zer muga estaltzen duen proba bakoitzak: prozesua, entzulea, autentifikazioa edo aplikazioa. Proba batek gutxitan estaltzen du bat baino gehiago, eta horiek “up” bihurtzen dituen egoera-orriak gertaera batean garrantzitsua den aldea ezkutatzen du. Sare-biderako, erabili benetako bezero bat identitate dedikatu batekin, utzi esku-ematea eta operazio kaltegabe baimendu bat amaitzen, eta gero deskonektatu. Horrek kontrol-kanala, autentifikazio-politika eta entzulea ariketan jartzen ditu urrats bakarrean.

Eduki identitate hori benetako erabiltzaileengandik bereizita eta eman probak behar duen gutxieneko baimenak. Sarbide zabaleko prestasun-proba bat erosotasunagatik gehitutako eraso-azalera berria da. Birakatu bere kredentzialak beste edozein kontutan bezala, autentifikatzeari uzten dion proba bat bezeroak onartzeari utzi dion zerbitzari bat bezalaxe ikusten baita.

Izendatu muga alertaren testuan, lehen erantzuleak jakin dezan unitateari, socketari, ziurtagiriari edo ibilbideari begiratu behar dion. Frogatu zuenaren berri eman ezin duen proba batean arrazoi okerragatik fidatuko da, eta horrelaxe iraun zuen netcat probak hasieran.