Перевірка VPN без інтерфейсу: по одному потоку за раз, з доказами
Безголовому пристрою потрібен запит, відповідь на який можна прочитати. Перевірте кожну родину адрес, контекст і призначення, потім запишіть, що результат не покрив.
На безголовому пристрої немає браузера, який можна відкрити, і замка, на який можна подивитися, тож перевірка має бути запитом, відповідь на який можна прочитати. Це звучить тривіально, доки ви не помітите, що один-єдиний результат адреси виходу використовується для засвідчення пристрою, на якому працюють десяток служб, дві родини адрес і проксі. Наведений нижче розбір вибудовує по одному обмеженому доказу за раз, у тому самому контексті, у якому робоче навантаження справді працює.
Вирішіть, що має довести тест
Перш ніж щось запускати, запишіть очікування одним рядком: який потік, через який інтерфейс, до якого призначення і що має спостерігатися на іншому кінці. Тест без заявленого очікування дає число, яке ніхто не зможе витлумачити.
Найкорисніший варіант називає затверджену кінцеву точку, яка повідомляє побачену адресу джерела.
Ця кінцева точка — єдина частина, яку потрібно організувати. Усе інше — спостереження на боці клієнта, а спостереження на боці клієнта ламаються цікавими способами.
Виконуйте спостереження в правильному контексті
Оболонка адміністратора — не середовище робочого навантаження. У ній може бути інша змінна проксі, інша таблиця маршрутизації в іншому просторі імен або файл середовища іншого користувача. Виконуйте тест у тому самому контексті хоста, контейнера, простору імен або служби, що й об'єкт перевірки. Інакше ви вимірюєте власну оболонку.
На звичайному хості це означає того самого користувача і той самий юніт. У контейнерному середовищі це означає вхід у мережевий простір імен контейнера замість тестування з хоста. На службі systemd це може означати тимчасовий юніт з тими самими налаштуваннями.
Наступний запит має сенс лише тоді, коли ви в правильному контексті.
Перевіряйте родини адрес окремо
Запитуйте кожну родину явно, бо успішний запит IPv4 взагалі не задіює шлях IPv6. Селектори --ipv4 і --ipv6 примушують до вибору, а різниця між двома результатами сама по собі є інформацією.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceНевдалий запит IPv6 не є доказом дієвого блокування. Він може означати, що кінцева точка не має адреси IPv6, що DNS не повернув нічого придатного або що пристрій узагалі не має маршруту IPv6. Прочитайте невдачу, перш ніж робити висновок. Успішний запит IPv6 через тунель — єдиний результат, що доводить, що шлях IPv6 покрито.
Запишіть обидві відповіді поряд. Одна з них сама по собі — половина факту.
Додайте чотири речі, які проґавить перевірка виходу
Адреса виходу відповідає на одне питання. Ще чотири вирішують, чи поводиться тунель так, як задумано.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
Політика призначень іде першою: перевірте потік, який має бути включений, і той, який має бути виключений, якщо проєкт має поділ. Далі DNS, де ви вивчаєте фактичний шлях резолвера, а не налаштоване значення, бо кешована відповідь або надруковане налаштування нічого не говорить про те, куди пішов новий запит.
Поведінка при збої потребує плану й збереженого шляху відновлення. Спостерігайте новий запит, доки тунель недоступний, і пам'ятайте, що старе відкрите з'єднання не є доказом про політику збою. Життєвий цикл іде останнім: повторіть спостереження після повторного підключення або перезапуску служби, якщо ці події впливають на вимогу.
Записуйте докази, а не вирок
Для кожного результату зберігайте контекст процесу, призначення, родину адрес, час і спостережуване джерело. Цей набір — обмежений доказ про потоки, які ви задіяли, і він захищається саме тому, що каже, що покрив.
Це не аудит записів оператора VPN і не сертифікат для кожного майбутнього застосунку на пристрої.
Запишіть межі поряд із результатом. Тест, який заявляє, що не покрив, проходить перевірку, а той, що стверджує, ніби пристрій перевірено, не проходить. Тримайте посібник із curl поряд з використаними селекторами родини і таблицю з чотирьох рядків разом із результатами.