Проверка 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 рядом с использованными селекторами семейства и таблицу из четырёх строк вместе с результатами.