Твои действия если ты подключаешься к VPN компании и у тебя пропадает интернет

Диагностика и устранение проблемы с потерей интернета при подключении к корпоративному VPN

Когда при подключении к VPN пропадает интернет, это классическая проблема, известная как split-tunnel vs. full-tunnel конфигурация, и мои действия как опытного инженера будут структурированы, системны и направлены на минимализацию времени простоя.

1. Первичный анализ и локализация проблемы

Первым делом я определяю масштаб проблемы:

• Пингую не только внешние ресурсы (например, 8.8.8.8 или ya.ru), но и внутренние адреса компании.

  # Проверяю доступность до подключения к VPN
  ping 8.8.8.8
  ping internal.company.com
  # Подключаюсь к VPN
  sudo openconnect vpn.company.com
  # Повторяю проверки после подключения
  ping 8.8.8.8
  ping internal.company.com
  

• Если внутренние адреса доступны, а внешние — нет, это явный признак Full-Tunnel (полного туннелирования). Весь мой интернет-трафик направляется через VPN-шлюз компании, который, вероятно, блокирует или неправильно маршрутизирует внешние запросы.
• Если не доступно ничего, проблема может быть в конфликте маршрутизации или DNS.

2. Проверка таблицы маршрутизации и DNS

Ключевой шаг — анализ того, как изменилась сетевая конфигурация системы.

• Изучаю таблицу маршрутизации: Команда ip route или netstat -rn покажет, какой маршрут добавлен для VPN и какой шлюз используется по умолчанию.

  # Смотрю таблицу маршрутизации ДО и ПОСЛЕ подключения
  ip route show default
  # Или более подробно
  netstat -rn
  

    Частая проблема: после подключения VPN устанавливает свой маршрут по умолчанию (`0.0.0.0/0`), "перехватывая" весь трафик, но сам VPN-шлюз не имеет выхода в интернет для пользовательского трафика.

• Диагностирую DNS: Проблема с DNS при полном туннеле — обычное дело. VPN-сервер часто переназначает DNS-серверы на корпоративные.

  # Проверяю, какие DNS-серверы сейчас используются
  cat /etc/resolv.conf
  # Пробую резолвить внешний и внутренний домен
  nslookup google.com
  nslookup internal.service.company
  

    Если резолвинг не работает, интернет "пропадает", даже если маршрутизация корректна.

3. Применение тактических решений (в зависимости от политик безопасности)

Здесь я должен балансировать между необходимостью получить доступ и соблюдением корпоративной политики безопасности.

• Если политика позволяет Split-Tunnel: Я могу временно попросить администраторов VPN проверить конфигурацию. Split-Tunnel — это режим, при котором в VPN идёт только трафик к внутренним сетям компании, а остальной трафик идёт напрямую через мой интернет. Это решение проблемы, но не всегда приемлемо с точки зрения безопасности компании.
• Работа с DNS: Если проблема только в DNS, могу временно, для диагностики, прописать публичный DNS (например, 1.1.1.1) в настройках сетевого подключения вне VPN-интерфейса, но это может нарушить доступ к внутренним ресурсам по доменным именам.
• Локальная корректировка маршрутов (как временное решение): Если мне критически нужен одновременный доступ и в интернет, и в корпоративную сеть, я могу вручную добавить маршрут только для внутренней сети через VPN, оставив маршрут по умолчанию на моём локальном шлюзе.

  # Пример: Подключаемся к VPN, но затем возвращаем дефолтный маршрут на локальный шлюз (192.168.1.1)
  # А для сети компании (10.10.0.0/16) указываем шлюзом VPN-интерфейс (tun0)
  sudo ip route add 10.10.0.0/16 dev tun0
  sudo ip route replace default via 192.168.1.1
  

    **ВАЖНО:** Это потенциальное нарушение политики безопасности, и такие действия допустимы только в согласованных рамках и для целей диагностики.

4. Эскалация и сбор логов

Если проблема не локальная и быстрые решения не помогают или неприменимы:

• Собираю логи: Логи клиента VPN, вывод команд ip a, ip route, nslookup до и после подключения.
• Проверяю на других устройствах: Подключаюсь с другого ноутбука или телефона. Если проблема воспроизводится — она точно на стороне инфраструктуры.
• Связываюсь с командой сетевых инженеров или Security-отделом: Четко излагаю проблему: "При подключении по VPN (протокол OpenConnect/IKEv2) из локации X через провайдера Y теряется выход в интернет. Внутренние ресурсы доступны. Дефолтный маршрут меняется на шлюз VPN Z.Z.Z.Z. Проблема воспроизводится на N устройствах. Прилагаю логи и вывод команд диагностики".
• Предлагаю гипотезу: На основе анализа я могу предположить, что проблема в: 1) отсутствии правил NAT или firewall на VPN-шлюзе для пользовательских подсетей, 2) неработающем DNS-резолвере, 3) блокировке внешнего трафика политиками на шлюзе.

Заключение

Мой подход — это последовательность диагностика -> локализация -> тактическое решение (если допустимо) -> эскалация. Я всегда исхожу из того, что конфигурация Full-Tunnel чаще всего является осознанной политикой безопасности компании, направленной на контроль всего исходящего трафика, а не ошибкой. Поэтому моя первостепенная задача — не обойти эту политику, а обеспечить свою работоспособность в её рамках, а при невозможности — оперативно и технически грамотно передать проблему ответственному подразделению, предоставив им максимум полезной информации для быстрого решения.