Туннель поднят, интернета нет: где останавливается перенаправление

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

Убедитесь, что выход в интернет вообще был задуман

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

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

Проследите один публичный запрос

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Если шлюз вообще не видит пакет, неверен маршрут клиента или выбор туннеля. Если пакет приходит и не уходит, проблема на шлюзе, и действуют три оставшиеся проверки.

Проверьте пересылку, маршрут и трансляцию

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Трансляция источника — обычный недостающий элемент. С ней шлюз подменяет источник клиента на свой публичный адрес и отслеживает поток; без неё ответу некуда идти. Облачные платформы добавляют вторую границу, где таблица маршрутов или группа безопасности экземпляра могут отбросить трафик, который разрешает гостевой межсетевой экран. Эту границу легко упустить, потому что гостевая система изнутри выглядит настроенной правильно.

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

Обратный путь и сопоставление имён — два разных ответа

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

Сайт, возвращающий ошибку HTTP, доказывает, что пересылка в интернет работает. Имя, которое не разрешается, тогда как доступ по адресу работает, — это проблема сопоставления имён, а не NAT.

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