После смены провайдера меняются внешний IP, тип NAT, маршрут, MTU и иногда доступность входящих протоколов. Старый VPN-туннель может продолжать отображаться в конфигурации, но peer отправляет трафик на прежний адрес или согласование блокируется carrier-grade NAT. Диагностику нужно разделить на достижимость, установление туннеля и маршрутизацию внутри него.

Сначала не меняйте одновременно ключи, шифры и маршруты. Проверьте новый внешний адрес, наличие CGNAT, доступность peer и время устройства. Затем изучите логи первой фазы туннеля и только после ее успеха переходите к маршрутам и firewall.

Что проверить в первую очередь

Начните с одного воспроизводимого сценария. Зафиксируйте точное время, идентификатор объекта, пользователя или операции, версию приложения и последнее известное рабочее состояние. Не меняйте несколько параметров одновременно: один контролируемый шаг должен подтверждать или исключать одну гипотезу. Перед работой с данными и конфигурацией подготовьте резервную копию и проверенный способ отката.

  • Сравните фактический WAN IP с адресом, который видит удаленная сторона.
  • Проверьте, публичный ли адрес выдан и не используется ли двойной NAT.
  • Уточните, обновлен ли peer IP или DNS-имя на обеих сторонах.
  • Проверьте UDP-порты, NAT-T и исходящие ограничения нового провайдера.
  • Сверьте локальные и удаленные подсети на пересечения.

Почему возникает проблема

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

  • Удаленный peer продолжает ожидать соединение со старого IP.
  • Новый провайдер использует CGNAT и блокирует входящее установление.
  • NAT-T или keepalive не настроены, поэтому mapping быстро закрывается.
  • Статический маршрут остался привязан к старому интерфейсу или gateway.
  • MTU и фрагментация позволяют handshake, но ломают полезный трафик.

Пошаговая диагностика

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

  • Проверьте DNS peer и маршрутизацию до его публичного адреса вне туннеля.
  • Снимите pcap на WAN и убедитесь, что запросы уходят и ответы возвращаются.
  • Сопоставьте IKE или WireGuard логи обеих сторон по времени.
  • После handshake проверьте таблицу маршрутов, policy rules, NAT exemptions и counters firewall.
  • Проведите ping с заданным source и размером, затем тест TCP для реального сервиса.

Три уровня проверки частной сети

Статус интерфейса сам по себе не доказывает работоспособность. Каждый уровень должен иметь отдельный измеримый тест.

  • Underlay: публичные адреса достигаются через нового провайдера.
  • Tunnel: ключи согласованы, handshake свежий и счетчики шифрованного трафика растут.
  • Routing: нужные подсети направляются в туннель без ошибочного NAT.
  • Policy: firewall разрешает ожидаемые направления и сервисы.
  • Application: DNS, TCP и прикладной запрос проходят из реального сегмента.

Как исправить проблему

Исправление делите на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, проверку сертификатов, валидацию или аудит ради быстрого исчезновения симптома.

  • Обновите peer endpoint или DNS и согласуйте разрешенные адреса на удаленной стороне.
  • При CGNAT инициируйте туннель изнутри, запросите публичный IP либо используйте промежуточный узел.
  • Настройте persistent keepalive или DPD с разумными интервалами.
  • Исправьте маршруты и исключения NAT для частных подсетей.
  • Подберите MTU по измерению и зафиксируйте рабочее значение на туннельном интерфейсе.

Безопасный порядок внедрения

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

Как проверить результат

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

  • Туннель автоматически поднимается после перезагрузки и краткого обрыва WAN.
  • Handshake и двусторонние counters обновляются.
  • Узлы обеих подсетей доступны по нужным портам, а не только ping с роутера.
  • Публичный интернет не уходит случайно в частный туннель.
  • Мониторинг обнаруживает устаревший handshake и недоступность внутреннего сервиса.

Типичные ошибки при исправлении

  • Отключать firewall целиком для проверки и забывать вернуть правила.
  • Менять PSK до подтверждения сетевой достижимости.
  • Считать зеленый статус интерфейса доказательством корректных маршрутов.
  • Добавлять masquerade на весь трафик и скрывать ошибку маршрутизации.
  • Проверять только с самого VPN-шлюза, не тестируя клиентские подсети.

Как предотвратить повторение

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

  • Используйте DNS endpoint или документированную процедуру смены публичного IP.
  • Храните резервную схему доступа к обеим сторонам.
  • Мониторьте внешний IP, handshake, packet loss и прикладной endpoint.
  • Документируйте маршруты, NAT и разрешенные подсети.
  • Проводите тест восстановления после смены канала и перезагрузки оборудования.

Что контролировать после выпуска

  • Количество успешных и ошибочных операций в разрезе версии, канала и типа сценария.
  • Возраст необработанных записей, длину очередей, число повторных попыток и долю окончательных отказов.
  • Расхождение между пользовательским статусом и фактическим состоянием в базе или внешней системе.
  • Появление новых кодов ошибок после релиза и изменение времени выполнения ключевой операции.
  • Сигналы от поддержки и бизнес-метрики, которые могут показать скрытый частичный сбой.

Что подготовить для технического разбора

  • Описание ожидаемого и фактического поведения с точной последовательностью действий.
  • Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
  • Фрагменты журналов до и после ошибки без секретов и персональных данных.
  • Перечень последних изменений и уже выполненных проверок.
  • Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Как понять, что у меня CGNAT?

WAN-адрес роутера отличается от адреса внешнего сервиса или относится к частному диапазону провайдера. Точный ответ даст провайдер.

Почему ping идет, а сайт через VPN не открывается?

Возможны MTU, DNS, асимметричный маршрут или firewall конкретного TCP-порта.

Нужно ли менять ключи после смены провайдера?

Обычно нет, если они не скомпрометированы; сначала исправляют endpoint и сетевую доступность.

Когда нужна помощь специалиста

Если частная сеть не восстановилась после смены канала, я могу проверить underlay, handshake, маршруты, NAT и MTU на обеих сторонах и настроить автоматическое восстановление. Для оценки нужны тип VPN, схема подсетей и обезличенные логи согласования.