Проверить, что разделённый туннель работает: одного результата IP недостаточно
Запишите, какие потоки должны идти через туннель, а какие оставаться прямыми, затем проверьте обе стороны, разделение DNS и сценарий отказа.
Одна страница браузера, показывающая IP-адрес, почти ничего не доказывает о разделённом туннеле. Видимый адрес может быть правильным по неправильной причине, а исключённый поток она никогда не проверяет. Запишите ожидаемый результат до проверки: какое приложение или назначение должно использовать туннель, что должно оставаться прямым и что должно остановиться при отказе туннеля. Без этого плана любое правдоподобное число выглядит как успех.
Миф: запрос адреса доказывает покрытие
Проверка IP отвечает на один вопрос: что внешний мир видит из одного приложения в один момент. Она ничего не говорит о внутреннем префиксе, втором профиле браузера или имени, которое должно разрешаться приватно. Она также ничего не говорит об отказе, а это та половина схемы разделённого туннеля, которая ломается в эксплуатации.
Страница адреса также не может показать маршрут, резолвер или политику отказа. Относитесь к ней как к одному наблюдению, а не как к приговору.
Проверьте включённый и исключённый поток
Отправьте безобидный запрос из приложения, которое должно быть включено, или на префикс, который, как вы ожидаете, пойдёт через туннель, и зафиксируйте источник, назначение, семейство адресов и наблюдаемый путь. Сделайте то же для потока, который должен оставаться прямым. Исключённая сторона — та, которую люди пропускают, и это единственное доказательство того, что разделение сделано намеренно, а не случайно. Вспомогательный процесс может нести отдельную идентичность политики, поэтому проверяйте в процессе, который владеет сокетом.
flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct
Поэтому проверка в неправильном приложении может показать противоположное тому, что задумано. Запишите четыре поля для обеих сторон, прежде чем делать какой-либо вывод.
Добавьте DNS и сценарий отказа
Опросите системный резолвер и резолвер, который использует приложение, а затем сравните эти ответы с адресом выхода, который сообщает сайт. Два уровня могут расходиться намеренно, и один запрос браузера не проверяет политику операционной системы. Оболочка делает сравнение воспроизводимым: Разорвите туннель намеренно, затем выполните запрос, который браузер не кэшировал; страница, отданная из кэша, ничего не говорит о том, куда ушёл резервный путь. Записывайте то, что действительно произошло, а не то, что предсказывала схема.
curl -s https://ifconfig.me
nslookup intranet.example
Разделённый туннель, который отказывает закрыто, и тот, который отказывает открыто, выглядят одинаково, пока вы намеренно не разорвёте туннель. Запишите, какое поведение вы наблюдали, а не какое ожидали.
Повторите после изменения состояния
Повторите те же наблюдения после переподключения, смены сети и соответствующего обновления приложения. Сохранённое исключение может продолжать указывать на путь или идентичность приложения, которых больше нет, и схема тихо перестаёт соответствовать своей документации. Эти три события — места, где разделённые туннели дрейфуют, и каждое из них дёшево проверить заново. Проверка, которая выполняется только один раз при развёртывании, описывает конфигурацию, которой больше нет.
Если результат отличается, найдите владельца правила и этап обработки, прежде чем менять несколько настроек сразу. Изменить пять вещей и увидеть один результат — не диагностика, а новая конфигурация.
Что должен установить результат
Свяжите наблюдения с политикой и версией клиента, которые вы действительно проверяли. Цель — показать, что это развёртывание соответствует заявленному покрытию, а не что каждое будущее приложение будет приватным. Это более узкое утверждение, и именно его вы действительно можете подкрепить доказательствами. Запишите утверждение, версию и результаты по четырём полям в журнал изменений.
Тогда следующий проверяющий сможет понять, изменилась ли схема или проверка. Разделённый туннель проверен, когда обе стороны, разделение резолвера и поведение при отказе соответствуют тому, что вы записали в начале. Один результат IP не подтверждает ни одного из них.