Тест на 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'

Сравнете началния час на сокета с времевата марка на изключването. Свързване, по-старо от прекъсването, е доказателство за повторно използване на сокет, а не за изтичане, и докладването му като провал изпраща следващия човек да търси грешка, която не съществува.

Запишете резултата във форма, която оцелява при актуализация

Запишете задействането, пролуката в секунди, дали е успяла някаква неблокирана заявка, дали е успяло разрешаването на имена и версиите на клиента и операционната система. Този набор от пет факта може да се сравнява между издания, което абзац текст не може.

Пуснете същия тест отново след актуализация на клиента или промяна на профил, защото поведението на блокиране е подробност от реализацията и се мести. Смисълът на записа е да забележите преместването, преди то да стане инцидент, а не да удостоверите клиента веднъж.

Подобни статии