OpenVPN client-connect mislukking: is disconnect-opruiming gewaarborg?
’n Afgekeurde kliënt maak nie ’n firewall-reël of ’n geskrewe rekord ongedaan nie. Vergelyk die callback-kontrak met die terugrol wat jou hook self moet doen.
Wanneer ’n client-connect-skrip nie-nul uitgang gee, verwerp OpenVPN die kliënt, en operateurs aanvaar gewoonlik dat die ooreenstemmende client-disconnect-skrip opruim. Dikwels loop dit nooit nie, want disconnect-verwerking is voorwaardelik op wat die connect-stadium kon voltooi. Om verwerping en terugrol as een meganisme te behandel, is wat ’n mislukte aanmelding in ’n gelekde firewall-reël of ’n weesrekord verander. Dit is twee aparte verpligtinge, en net een daarvan is outomaties. Lees die hook se eie uitgangspad voordat jy die bediener blameer dat hy toestand agterlaat.
’n Nie-nul uitgang verwerp die kliënt; dit maak nie jou werk ongedaan nie
Die uitgangstatus van client-connect is ’n toelatingsbeslissing. Nul beteken toelaat; enigiets anders beteken die instansie word afgebreek voordat dit volledig gevestig is. Niks in daardie kontrak ondersoek wat die skrip reeds aan die buitewêreld gedoen het nie. As die skrip ’n iptables-reël bygevoeg het, ’n ry geskryf het of ’n teller verhoog het, oorleef daardie veranderinge die verwerping.
Dieselfde asimmetrie geld vir inproppe, waar verskeie connect-funksies vir een instansie kan loop. ’n Latere mislukking kanselleer nie terugwerkend ’n vroeëre sukses nie, en die vroeëre funksie het geen manier om te weet dat ’n suster misluk het nie.
Verwerping is outomaties, opruiming is nie
Die OpenVPN 2.6-handleiding koppel client-disconnect-verwerking aan die voorwaarde dat vorige connect-verwerking geslaag het. ’n Gedokumenteerde uitsondering dek kaskade-kettings: as een connect-stap reeds sukses teruggegee het, loop die ooreenstemmende disconnect-stappe steeds wanneer die instansie afgebreek word, selfs al het ’n latere connect-stap misluk. Daardie uitsondering is smal en hang af van hoeveel callbacks opgestel is, en daarom sê die toets van een shell-skrip vir jou niks oor ’n ketting nie.
Karteer die werklike konfigurasie voordat jy daaromheen ontwerp: watter skrip, watter inprop en in watter volgorde hulle loop. Die tabel hieronder lys wat ’n halfvoltooide opstelling agterlaat.
| 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 |
Elke ry eindig dieselfde vir die kliënt en anders vir die gasheer. Die kliënt kan nie sê watter een gebeur het nie, so die hook moet terugrol wat dit gedoen het voordat dit die mislukkingstatus teruggee.
Vergoed binne die skrip wat misluk het
Valideer alles wat jy kan voordat jy gedeelde toestand aanraak: sertifikaatvelde, adresbeskikbaarheid, die groep waaraan die kliënt behoort. Die goedkoopste verwerping is die een wat voor enige toekenning plaasvind. Sodra die opstelling verskeie eksterne bewerkings oorspan, hou ’n rekord van watter voltooi is en rol dit in omgekeerde volgorde terug voordat jy die mislukkingstatus teruggee.
’n Konkrete geval: die skrip skep ’n per-kliënt-firewall-inskrywing en misluk dan om die toestandry te skryf wat dit beskryf. Die tak wat misluk, moet die inskrywing verwyder wat hy pas geskep het en dan nie-nul uitgaan. Om te wag vir ’n disconnect-gebeurtenis wat dalk nooit geskeduleer word nie, is hoe ’n reël die sessie oorleef waarvoor dit bedoel was.
Maak vergoeding idempotent en toegeëien
Opruiming moet veilig wees om twee keer te loop en presies oor wat dit mag verwyder. ’n Late gebeurtenis van ’n vroeëre poging moet nie ’n nuwer sessie se toekenning verwyder net omdat albei ’n gemeenskaplike naam of ’n herwinde tonneladres deel nie. Teken die spesifieke handvatsel of bewerkings-id saam met die hulpbron aan, en verwyder op daardie sleutel eerder as op naam. Databasis-transaksies help net met die databasis se eie veranderinge; ’n firewall-reël buite daardie grens het ’n eksplisiete vergoedingstap nodig.
Aanvaar dat die proses kan sterf tussen die verandering en die opruiming, en voeg ’n versoeningsproses by wat eksterne toestand op ’n skedule met die toegelate kliëntelys vergelyk.
Toets die drie paaie wat werklik verskil
Oefen drie gevalle: ’n verwerping voordat enigiets toegeken is, een ná ’n gedeeltelike toekenning, en ’n normale toegelate sessie wat later eindig. Dié drie lewer verskillende loglyne en verskillende oorblyfsels. Stel vas op die eksterne toestand ná elkeen, nie net op die kliënt se mislukkingsboodskap nie, want die kliënt wat misluk, is in twee van die drie die verwagte uitkoms.
Log die hook-stadium, die uitgangstatus en wat toegeken of vrygestel is, met geloofsbriewe weggelaat. ’n Hook-log wat die hulpbron noem wat dit geskep het, is wat ’n gelekde reël ses maande later vindbaar maak.