OpenVPN client-connect-misferging: is it opromjen by disconnect garandearre?
In ôfwiisde kliïnt makket gjin firewall-regel of skreaun record ûngedien. Ferlykje it callback-kontrakt mei it weromdraaien dat jo hook sels dwaan moat.
As in client-connect-skript mei in net-nul koade einiget, wiist OpenVPN de kliïnt ôf, en behearders geane der meastal fan út dat it byhearrende client-disconnect-skript oprommet. Faaks rint it nea, om’t disconnect-ferwurking ôfhinklik is fan wat de connect-fase wist te foltôgjen. It ôfwizen en it weromdraaien as ien meganisme behannelje is wat in mislearre oanmelding feroaret yn in lekke firewall-regel of in weesrecord. It binne twa aparte ferplichtingen, en mar ien fan beide is automatysk. Lês it eigen útgongspaad fan de hook foardat jo de server beskylgje dat er steat efterlit.
In net-nul útgong wiist de kliïnt ôf; it makket jo wurk net ûngedien
De útgongsstatus fan client-connect is in talittingsbeslissing. Nul betsjut talitte, al it oare betsjut de ynstânsje ôfbrekke foardat dy folslein fêstige is. Neat yn dat kontrakt ûndersiket wat it skript al mei de bûtenwrâld dien hat. As it skript in iptables-regel tafoege hat, in rige skreaun hat of in teller ferhege hat, oerlibje dy feroarings it ôfwizen.
Deselde asymmetry jildt foar tafoegsels, wêr’t ferskate connect-funksjes foar ien ynstânsje rinne kinne. In lettere misferging annulearret net efterôf in eardere sukses, en de eardere funksje hat gjin manier om te witten dat in sustersfunksje mislearre is.
Ôfwizen is automatysk, opromjen net
De hantlieding fan OpenVPN 2.6 ferbynt client-disconnect-ferwurking oan it slagjen fan ’e foarige connect-ferwurking. In dokumintearre útsûndering beslacht kaskadekeatlings: as ien connect-stap al sukses weromjûn hat, rinne de byhearrende disconnect-stappen dochs as de ynstânsje ôfbrutsen wurdt, sels as in lettere connect-stap mislearre is. Dy útsûndering is smel en hinget ôf fan hoefolle callbacks der konfigurearre binne, dêrom seit it testen fan ien shell-skript jo neat oer in keatling.
Yn kaart bringe de echte konfiguraasje foardat jo deromhinne ûntwerpe: hokker skript, hokker tafoegsel en yn hokker folchoarder se rinne. De tabel hjirûnder listet op wat in healôffre set-up efterlit.
| 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 rige einiget itselde foar de kliïnt en oars foar de host. De kliïnt kin net sizze hokker fan beide bard is, dus moat de hook weromdraaie wat er dien hat foardat er de misfergingsstatus weromjout.
Kompensearje binnen it skript dat mislearre
Falidearje alles wat jo kinne foardat jo dielde steat oanreitsje: sertifikaatfjilden, beskikberens fan it adres, de groep dêr’t de kliïnt by heart. It goedkeapste ôfwizen is datjinge dat bart foar elke tawizing. Sadree’t de set-up ferskate eksterne operaasjes omfettet, hâld by hokker foltôge binne en draai se yn omkearde folchoarder werom foardat jo de misfergingsstatus weromjouwe.
In konkreet gefal: it skript makket in firewall-ynfier per kliïnt, en mislearret dan de steatrige te skriuwen dy’t it beskriuwt. De mislearjende tûke moat de ynfier fuortsmite dy’t er krekt makke hat en dan mei in net-nul koade ôfslute. Wachtsje op in disconnect-evenemint dat miskien nea pland wurdt is hoe’t in regel de sesje oerlibbet wêrfoar’t er bedoeld wie.
Meitsje kompensaasje idempotint en eigendom
Opromjen moat feilich wêze om twa kear te rinnen en presys oer wat it fuortsmite mei. In let evenemint fan in eardere poging moat net de tawizing fan in nijere sesje fuortsmite allinnich om’t beide in mienskiplike namme of in recycled tunneladres diele. Registrearje it spesifike handtak of de operaasje-id by de boarne, en smyt fuort op dy kaai ynstee fan op namme. Databasetransaksjes helpe allinnich by de eigen feroarings fan ’e database; in firewall-regel bûten dy grins hat in eksplisite kompensaasjestap nedich.
Nim oan dat it proses stjerre kin tusken de feroaring en it opromjen, en foegje in ferieniger ta dy’t neffens in skema de eksterne steat fergeliket mei de list fan talitten kliïnten.
Test de trije paden dy’t wier ferskille
Oefenje trije gefallen: in ôfwizing foardat der wat tawize is, ien nei in partiele tawizing, en in normale talitten sesje dy’t letter einiget. Dy trije produsearje ferskillende logregels en ferskillende resten. Kontrolearje de eksterne steat nei elk fan beide, net allinnich it misfergingsberjocht fan ’e kliïnt, want it misfergjen fan ’e kliïnt is de ferwachte útkomst yn twa fan ’e trije.
Log de hook-fase, de útgongsstatus en wat tawize of frijlitten is, sûnder de referinsjes. In hook-log dy’t de makke boarne neamt is wat in lekke regel seis moannen letter finber makket.