Прокси всё ещё на старом адресе туннеля после переподключения VPN?

Переподключение может оставить ваш форвардер привязанным к адресу, которым туннель больше не владеет. Четыре упорядоченные проверки, нумерованная передача и настоящий тестовый запрос.

Перезапуск клиента VPN доказывает только то, что туннель вернулся. Он ничего не говорит о прокси, которому было велено выходить через него. Squid, tinyproxy и большинство других форвардеров держат локальный адрес источника, полученный при запуске, пока что-то не заставит их перезагрузиться. Когда переподключение выдаёт новый адрес туннеля, форвардер либо терпит неудачу при каждом исходящем соединении, либо начинает выходить через ваш обычный маршрут.

Второй сбой и есть опасный: туннель работает, страницы загружаются, и только адрес выхода неверен.

Начните со слушателя, а не с туннеля

В игре три адреса, и переподключение сдвигает только некоторые. Слушатель — это то, куда указывает ваш браузер, обычно 127.0.0.1 или адрес локальной сети, и ему всё равно, что туннель изменился. Исходящий локальный источник — это то, что форвардер просит ядро использовать при наборе следующего хопа, и он привязан к устройству туннеля. Публичный выход — это то, что пишет в журнал веб-сервер, и это может быть транслированный адрес в нескольких хопах отсюда.

Поиск публичного IP отвечает только на последний вопрос. Он не может сказать, к какому локальному адресу должен привязаться форвардер, потому что один публичный выход может скрывать несколько внутренних источников. Читайте адрес у того, кто владеет соединением: из вывода состояния клиента, из самого интерфейса или из пространства имён, где живёт туннель. Захват первого интерфейса с похожим на туннель именем даёт неверный ответ, как только существует второй профиль.

Схемы с контейнерами и пространствами имён тихо ломают это допущение. Форвардер в одном сетевом пространстве имён не может привязаться к туннелю, существующему в другом, и никакое редактирование конфигурации это не исправит.

Четыре проверки, прежде чем что-то менять

Проходите их по порядку. Первая неудачная проверка — это место, где вы останавливаетесь, потому что последующие предполагают, что предыдущие выполняются.

  1. Убедитесь, что используемый туннель — это профиль, вокруг которого строился прокси, а не второй профиль, подключившийся сам.
  2. Выведите адрес, который сейчас на этом устройстве, и сравните его с адресом в работающей конфигурации.
  3. Спросите форвардер, какой источник он определил, а не что утверждает файл на диске.
  4. Убедитесь, что трафик от форвардера действительно подчиняется той политике маршрутизации и межсетевого экрана, которую вы ожидаете.

Адрес устройства прост: ip -4 addr show dev tun0 выводит текущий, а ip -4 route get 1.1.1.1 показывает, какой интерфейс ядро выбрало бы для этого назначения. Форвардер, привязанный к точному адресу, громко падает, когда адрес исчезает. Форвардер, привязанный к устройству или откатывающийся к источнику по умолчанию, продолжает работать и течёт, и это тихий результат.

Согласуйте документацию с той версией, которую вы запускаете, а не с первым результатом поиска. Директива исходящего адреса Squid документирована для v7 и более ранних, а документация v8 прямо говорит, что там директива недоступна, поэтому скрипт, построенный вокруг неё, не переживает эту границу (смотрите справку Squid tcp_outgoing_address). Проверьте собственным анализатором продукта, прежде чем что-либо перезагружать: squid -k parse сообщает об ошибках и завершается, не трогая работающий процесс.

Пронумеруйте каждый туннель и отбрасывайте устаревшие замены

Переподключение — это передача, а передача требует порядка. Помечайте каждое наблюдаемое соединение счётчиком или отметкой времени, которая растёт при каждом успешном установлении, и затем несите эту метку внутри конфигурации-кандидата. Когда метка на кандидате старее текущей, отбросьте кандидата вместо применения, иначе медленное обновление, написанное для предыдущего туннеля, перезапишет настройки текущего. Объединяйте всплески событий, чтобы мигающий канал давал один переход, а не пятнадцать.

Выстройте работу в четыре шага: аннулируйте старое состояние выхода, дождитесь от владельца соединения сообщения о завершении, соберите только управляемый фрагмент, затем проверьте и активируйте через менеджер служб. Перегенерация всего файла из двух значений адреса — это способ, которым тихо исчезают ограничения слушателя, аутентификация и политика назначения. Уважайте и намеренную остановку. Помощник, который продолжает набирать туннель, выключенный пользователем, — это ошибка, а не устойчивость.

Открытые сокеты не пойдут за новым адресом

Переконфигурирование форвардера ничего не говорит о уже установленных соединениях. Иссякнут они или умрут — зависит от продукта, поэтому наблюдайте поведение, а не предполагайте.

Запрос, обслуженный через сокет, открытый до замены, всё равно выходит старым путём, даже когда новая конфигурация верна. Если это важно, решите явно: дайте короткое окно исчерпания и перестаньте принимать новую работу, или закройте старые сокеты и примите ошибки. Затем проверьте свежим соединением и держите этот результат отдельно от проверки исчерпания. Привязка к источнику тоже не граница безопасности. Когда трафик никогда не должен касаться обычного маршрута, обеспечьте это метками и правилами межсетевого экрана, включая DNS и IPv6, чтобы неудачная перезагрузка оставила прокси явно выключенным, а не открытым.

Докажите новый выход свежим запросом

Важен запрос, открытый после активации, а не ping и не уже закэшированная страница. Попросите прокси реальный URL и прочитайте адрес выхода, который сообщает дальняя сторона, затем сравните его с собственным представлением клиента о туннеле, когда провайдер его показывает.

Держите разбор, перезагрузку и запрос отдельными командами, чтобы сбой указывал на один шаг. Первые две ничего не меняют при неудаче, и именно поэтому они выполняются до перезапуска.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Если перезагрузка не удалась, остановите службу и исправьте фрагмент; прокси, работающий с устаревшим выходом, хуже короткого перерыва. Если перезагрузка удалась, но свежий запрос всё равно выходит куда-то неожиданно, вернитесь к проверке маршрутизации, а не правьте адреса снова. Запишите поколение туннеля, относительно которого проверяли, чтобы следующему переподключению было с чем конкретно сравнить.

Похожие статьи