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

Порівняйте час запуску сокета з позначкою часу відключення. З’єднання, старше за збій, — доказ повторного використання сокета, а не утечі, і повідомлення про нього як про збій відправляє наступну людину шукати помилку, якої немає.

Запишіть результат у формі, яка переживе оновлення

Запишіть тригер, розрив у секундах, чи вдався якийсь незаблокований запит, чи вдалося розв’язання імен, а також версії клієнта й операційної системи. Цей набір із п’яти фактів можна порівнювати між випусками, чого абзац прози не може.

Повторіть той самий тест після оновлення клієнта або зміни профілю, бо поведінка блокування — деталь реалізації, і вона зміщується. Сенс запису — помітити зміщення до того, як воно стане інцидентом, а не засвідчити клієнт одного разу.

Схожі статті