Тест на kill switch: измерете ја празнината, не само повторното поврзување

Брзото повторно поврзување докажува дека клиентот е брз. Запишете што ја напуштило машината за време на празнината, заедно со активаторот што го користевте, инаку тестот измерил само половина.

Повторно поврзување што завршува за секунда ви кажува дека клиентот е брз. Не ви кажува дали нешто излегло додека тунелот бил исклучен. Повторно поврзување што трае една минута ви кажува дека клиентот е бавен, и се уште не ви кажува дали директниот сообраќај бил дозволен во празнината. Тоа се две мерења, а тест на kill switch што известува само за првото не го тестирал прекинувачот.

Две набљудувања, две одделни пресуди

Прашањето за достапност е едноставно: кога тунелот повторно стана употреблив и дали заштитената апликација имаше потреба од нова врска за да стигне таму. Прашањето за спроведување е поинакво: кои пакети ја напуштиле машината од моментот кога заштитата падна до моментот кога се врати.

Одговорете им со одделни записи. Една линија вели дека празнината траела одреден број секунди. Друга линија вели дали некое незаштитено барање успеало за време на таа празнина. Нивното спојување во едно помина или не помина го крие случајот што е најважен: брзо повторно поврзување со истекување.

Изградете сонда што може да се мери со време

Користете барање што е безопасно, евтино и независно од сопствениот контролен канал на тунелот. Јамката долу печати временска ознака, HTTP статус и поминато време еднаш во секунда, и гласно пропаѓа наместо да виси:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Читајте ги излезните кодови на curl, не само статусот. 28 значи дека барањето истече, така изгледа блокиран пат. 6 значи дека разрешувањето имиња не успеа, што е друг наод и често поинтересен. 200 со кратко поминато време во празнината значи дека сообраќајот бил пуштен надвор.

Запишете го излезот во датотека и чувајте ја. Историјата на терминалот не е доказ, а интересниот дел обично се три линии во средината.

Предизвикајте вистински дефект, не уреден

Исклучувањето од сопственото мени на клиентот го тестира кооперативниот пат, каде клиентот има време да ги инсталира своите правила за блокирање. Наместо тоа убијте го процесот, или прекинете ја долната врска, и ќе го тестирате патот што го поминува вистински дефект.

Секој активатор вежба различен коден пат. Дефект на страната на серверот, губење на локална врска и пад на клиентот можат секој да остават различно состојба, и еден од нив веројатно е случајот со кој на крајот ќе се сретнете. Пуштете ја сондата со најмалку два активатори и означете ги резултатите по активатор.

Читајте го дневникот за да видите како изгледа дозволениот сообраќај

200 или брз неуспех на врската во празнината е истекување, во која и да покажува насока. Истекувањата на времето во текот на целата празнина се очекуваната форма на политика за блокирање. Успешното разрешување имиња додека врските пропаѓаат укажува дека резолверот е се уште достапен, што е истекување од друг вид.

Постојните сокети бараат внимание. Програмата може да продолжи да користи врска што ја отворила пред исклучувањето, така што навидум живиот сообраќај може да не докаже дека нов пат бил дозволен. Списокот на сокети покажува дали врската е постара од настанот:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Споредете го времето на започнување на сокетот со временската ознака на исклучувањето. Врска постара од дефектот е доказ за повторна употреба на сокетот, не за истекување, а известувањето за неа како дефект го праќа следниот човек да бара грешка што не постои.

Запишете го резултатот во форма што го преживува ажурирањето

Запишете го активаторот, празнината во секунди, дали успеало некое неблокирано барање, дали успеало разрешувањето имиња, и верзиите на клиентот и оперативниот систем. Овој сет од пет факти може да се споредува меѓу изданија, што еден пасус проза не може.

Пуштете го истиот тест повторно по ажурирање на клиентот или промена на профилот, бидејќи однесувањето при блокирање е детаљ од имплементацијата и се поместува. Смислата на записот е да ја забележите промената пред таа да стане инцидент, а не да го сертифицирате клиентот еднаш.

Поврзани статии