Неуспешен client-connect во OpenVPN: дали е гарантирано чистењето при disconnect?
Одбиен клиент не го враќа правилото на огнениот ѕид ниту запишаниот запис. Споредете го договорот за повратен повик со враќањето што вашиот hook мора да го изврши сам.
Кога скрипта client-connect излегува со ненулти код, OpenVPN го одбива клиентот, а администраторите обично претпоставуваат дека соодветната скрипта client-disconnect ќе го среди сето тоа. Често таа воопшто не се извршува, бидејќи обработката на disconnect зависи од тоа што успеала да заврши фазата connect. Третирањето на одбивањето и враќањето како еден механизам е она што неуспешната најава ја претвора во истечено правило на огнениот ѕид или во осамениот запис. Тоа се две одделни обврски, а само едната е автоматична. Прочитајте ја сопствената излезна патека на hook-от пред да го обвините серверот дека оставил состојба.
Ненултиот излез го одбива клиентот; не ја враќа вашата работа
Излезниот статус на client-connect е одлука за прием. Нула значи прими, сѐ друго значи уривање на инстанцата пред целосно да се воспостави. Ништо во тој договор не проверува што скриптата веќе направила во надворешниот свет. Ако скриптата додала правило за iptables, запишала ред или зголемила бројач, тие промени го преживуваат одбивањето.
Истата асиметрија важи за приклучоците, каде што за една инстанца може да се извршат неколку функции connect. Подоцнежниот неуспех не го откажува ретроактивно претходниот успех, а претходната функција нема начин да дознае дека сестринската функција не успеала.
Одбивањето е автоматско, чистењето не е
Прирачникот за OpenVPN 2.6 ја врзува обработката на client-disconnect со претходно успешната обработка на connect. Документиран исклучок покрива каскадни синџири: ако еден чекор connect веќе вратил успех, соодветните чекори disconnect сепак се извршуваат при уривањето на инстанцата, дури и ако подоцнежниот чекор connect не успеал. Тој исклучок е тесен и зависи од тоа колку повратни повици се конфигурирани, затоа тестирањето на една shell скрипта не ви кажува ништо за синџир.
Мапирајте ја вистинската конфигурација пред да дизајнирате околу неа: која скрипта, кој приклучок и по кој редослед се извршуваат. Табелата подолу наведува што остава половично завршеното поставување.
| 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 |
Секој ред завршува исто за клиентот и поинаку за домаќинот. Клиентот не може да каже кој од нив се случил, затоа hook-от мора да го врати она што го направил пред да го врати статусот на неуспех.
Надоместете во скриптата што не успеала
Проверете сѐ што можете пред да допрете споделена состојба: полињата на сертификатот, достапноста на адресата, групата на која ѝ припаѓа клиентот. Најевтиното одбивање е она што се случува пред каква било распределба. Кога поставувањето опфаќа неколку надворешни операции, водете евиденција кои се завршени и вратете ги по обратен редослед пред да го вратите статусот на неуспех.
Конкретен случај: скриптата создава запис на огнениот ѕид за секој клиент, потоа не успева да го запише редот на состојбата што го опишува. Гранката што не успеала треба да го отстрани записот што штотуку го создала и потоа да излезе со ненулти код. Чекањето на настан disconnect што можеби никогаш нема да биде закажан е начинот на кој правилото ја надживува сесијата за која било наменето.
Направете надоместокот идемпотентен и со сопственик
Чистењето мора да биде безбедно за двократно извршување и прецизно за тоа што смее да избрише. Доцен настан од претходен обид не смее да ја отстрани распределбата на понова сесија само затоа што двете делат заедничко име или рециклирана адреса на тунел. Запишете ја конкретната рачка или идентификаторот на операцијата со ресурсот и бришете по тој клуч, а не по име. Трансакциите на базата на податоци помагаат само со сопствените промени на базата; правило на огнениот ѕид надвор од таа граница бара експлицитен чекор на надоместок.
Претпоставете дека процесот може да умре помеѓу промената и чистењето и додадете усогласувач што по распоред ја споредува надворешната состојба со списокот примени клиенти.
Тестирајте ги трите патеки што навистина се разликуваат
Вежбајте три случаи: одбивање пред ништо да биде распределено, едно по делумна распределба и нормална примена сесија што подоцна завршува. Тие три даваат различни линии во дневникот и различни остатоци. Проверете ја надворешната состојба по секој од нив, не само пораката за неуспех на клиентот, бидејќи неуспехот на клиентот е очекуваниот исход во два од трите случаи.
Запишете ја фазата на hook-от, излезниот статус и што е распределено или ослободено, без акредитивите. Дневникот на hook-от што го именува создадениот ресурс е она што го прави истеченото правило пронајдливо шест месеци подоцна.