Клиенты VPN подключаются, но интернета нет: три недостающих части

Туннелю, отвечающему на ping, всё ещё нужны пересылка, трансляция и правило пересылки. Выясните, какой из трёх частей не хватает, прежде чем снова править клиент.

Клиент получает адрес, сервер отвечает на ping, и всё равно каждая страница завершается по тайм-ауту. Большинство людей на этом этапе начинает править профиль клиента, что обычно напрасная работа: как только туннель поднят, сервер должен вести себя как маршрутизатор. Три условия должны выполняться одновременно, прежде чем пакет выйдет и вернётся ответ, и симптом одинаков, какой бы из них ни отсутствовал.

Почему работающий туннель всё ещё не имеет выхода

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

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

Поэтому проверяйте три уровня, а не клиент, и меняйте по одному, чтобы результат что-то значил.

Пересылка — это переключатель ядра, который нужно сделать постоянным

Проверьте текущее значение перед изменением, затем задайте его и убедитесь, что изменение вступило в силу.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

Сделайте его постоянным в файле в /etc/sysctl.d/, а затем примените этот файл вместо перезагрузки, чтобы узнать результат. В FreeBSD эквивалент — net.inet.ip.forwarding, а для постоянства — gateway_enable=YES в rc.conf. Устройство, сообщающее об отключённой пересылке, объясняет целый класс отчётов «пакеты приходят, а ничего не возвращается». Проверяйте настройку и после каждого обновления, потому что пересобранное ядро или заменённый образ устройства могут сбросить её, никому не сказав.

Выберите masquerade или один фиксированный адрес трансляции

При динамическом внешнем адресе masquerading — самая простая правильная форма. Назовите подсеть туннеля источником, а внешний интерфейс — выходом.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

При статическом публичном адресе трансляция источника именно в этот адрес предсказуемее и легче проверяется.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

Таблица фильтров — третьи ворота

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Мостовой туннель требует другого ответа. Адрес принадлежит мосту, а не физическому порту, поэтому подчинение интерфейса убирает адрес, который у него был раньше, и хост выглядит недоступным, пока сам мост не получит адрес, что может обеспечить dhclient br0. Этот сбой выглядит как проблема VPN, а на деле это проблема второго уровня. Проверьте собственный адрес моста, прежде чем трогать межсетевой экран, потому что изменение фильтра не исправит хост, у которого больше нет адреса для отправки.

Куда смотреть, когда страница так и не загружается

Пропингуйте адрес туннеля сервера, чтобы доказать, что туннель существует. Затем запустите traceroute с клиента на публичный адрес и прочитайте, где он останавливается: на сервере пакет приходит, но не пересылается и не транслируется; за сервером проблема выше по потоку и вне ваших рук.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

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

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

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