OpenVPN client-connect tõrge: kas disconnect’i koristamine on tagatud?
Tagasilükatud klient ei võta tagasi tulemüürireeglit ega kirjutatud kirjet. Võrrelge callback-lepingut tagasipööramisega, mille teie hook peab ise tegema.
Kui client-connect skript väljub nullist erineva koodiga, lükkab OpenVPN kliendi tagasi ja administraatorid eeldavad tavaliselt, et vastav client-disconnect skript koristab. Sageli ei käivitu see kunagi, sest disconnect’i töötlemine sõltub sellest, mida connect’i etapp suutis lõpule viia. Tagasilükkamise ja tagasipööramise käsitlemine ühe mehhanismina muudab ebaõnnestunud sisselogimise lekkivaks tulemüürireegliks või orvuks jäänud kirjeks. Need on kaks eraldi kohustust ja ainult üks neist on automaatne. Lugege hooki enda väljumisteekonda enne, kui süüdistate serverit oleku maha jätmises.
Nullist erinev väljumine lükkab kliendi tagasi, kuid ei võta teie tööd tagasi
client-connect’i väljumisolek on vastuvõtuotsus. Null tähendab vastu võtta, mis tahes muu tähendab instantsi lammutamist enne, kui see on täielikult loodud. Miski selles lepingus ei uuri, mida skript on välismaailmas juba teinud. Kui skript lisas iptables-reegli, kirjutas rea või suurendas loendurit, jäävad need muudatused tagasilükkamisele vaatamata alles.
Sama asümmeetria kehtib pluginate puhul, kus ühe instantsi jaoks võib käivituda mitu connect-funktsiooni. Hilisem tõrge ei tühista tagasiulatuvalt varasemat õnnestumist ja varasemal funktsioonil pole võimalust teada saada, et sõsfunktsioon ebaõnnestus.
Tagasilükkamine on automaatne, koristamine ei ole
OpenVPN 2.6 käsiraamat seob client-disconnect’i töötlemise eelneva connect’i töötlemise õnnestumisega. Dokumenteeritud erand hõlmab kaskaadseid ahelaid: kui üks connect’i samm on juba tagastanud õnnestumise, käivituvad vastavad disconnect’i sammud instantsi lammutamisel siiski, isegi kui hilisem connect’i samm ebaõnnestus. See erand on kitsas ja sõltub sellest, kui palju callback’e on seadistatud, mistõttu ühe shell-skripti testimine ei ütle teile ahela kohta midagi.
Kaardistage tegelik konfiguratsioon enne selle ümber projekteerimist: milline skript, milline plugin ja mis järjekorras need käivituvad. Allolev tabel loetleb, mida poolik seadistus enda järel hoiab.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Iga rida lõpeb kliendi jaoks ühtemoodi ja hosti jaoks erinevalt. Klient ei saa aru, milline neist juhtus, seega peab hook enne tõrkeoleku tagastamist tagasi pöörama selle, mida ta tegi.
Hüvitage skripti sees, mis ebaõnnestus
Valideerige kõik, mida saate, enne jagatud oleku puudutamist: sertifikaadi väljad, aadressi kättesaadavus, grupp, kuhu klient kuulub. Odavaim tagasilükkamine on see, mis juhtub enne igasugust eraldamist. Kui seadistus hõlmab mitut välist toimingut, pidage arvestust selle üle, millised lõpetati, ja pöörake need tagasi vastupidises järjekorras enne tõrkeoleku tagastamist.
Konkreetne juhtum: skript loob iga kliendi jaoks tulemüürikirje ja seejärel ebaõnnestub seda kirjeldava olekurea kirjutamisel. Ebaõnnestuv haru peaks eemaldama äsja loodud kirje ja seejärel väljuma nullist erineva koodiga. Ootamine disconnect-sündmusele, mida ei pruugita kunagi ajastada, on viis, kuidas reegel elab üle sessiooni, mille jaoks see mõeldud oli.
Tehke hüvitamine idempotentseks ja omanikuga
Koristamine peab olema ohutu kaks korda käivitada ja täpne selle suhtes, mida tohib kustutada. Varasema katse hiline sündmus ei tohiks eemaldada uuema sessiooni eraldist ainult seetõttu, et mõlemal on ühine nimi või ringlussevõetud tunneliaadress. Salvestage konkreetne käepide või toimingu id koos ressursiga ja kustutage selle võtme järgi, mitte nime järgi. Andmebaasi tehingud aitavad ainult andmebaasi enda muudatuste puhul; väljaspool seda piiri olev tulemüürireegel vajab selgesõnalist hüvitamissammu.
Eeldage, et protsess võib surra muudatuse ja koristamise vahel, ning lisage lepitaja, mis võrdleb välist olekut lubatud klientide loendiga ajakava järgi.
Testige kolme teed, mis tegelikult erinevad
Harjutage kolme juhtumit: tagasilükkamine enne mis tahes eraldamist, tagasilükkamine pärast osalist eraldamist ja tavaline lubatud sessioon, mis hiljem lõpeb. Need kolm annavad erinevad logiread ja erinevad jäägid. Kontrollige välist olekut igaühe järel, mitte ainult kliendi tõrketeavitust, sest kliendi tõrge on oodatav tulemus kahel juhul kolmest.
Logige hooki etappi, väljumisolekut ja seda, mis eraldati või vabastati, ilma mandaatideta. Hooki logi, mis nimetab loodud ressursi, on see, mis teeb lekkinud reegli kuus kuud hiljem leitavaks.