OpenVPN с полным туннелем: добавьте интернет-выход на стороне сервера

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

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

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

push "redirect-gateway def1"

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

Пересылка — это настройка сервера, а не настройка VPN

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

Разрешите ровно тот транзит, который вам нужен, и ничего больше

Пересылаемые пакеты проходят по пути forward; трафик, адресованный самому хосту VPN, проходит по input. Это разные решения, и открытие пути input не разрешает транзит через машину. Их смешение — самая частая причина, по которой межсетевой экран как будто разрешает всё, а клиенты всё равно получают тайм-аут.

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Дайте ответам место, куда идти

Адреса пула частные, поэтому публичный сервер не может доставить им ответ напрямую. Либо хост VPN транслирует адрес источника на выходе, либо устройство выше по потоку держит маршрут обратно в пул.

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

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

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

Докажите это с клиента, а не из оболочки сервера

Начните с числового запроса IPv4, затем с запроса имени, затем с приложения. ping доказывает пересылку и трансляцию;он ничего не доказывает про разрешение имён, потому что параметры DNS вступают в силу только когда интеграция клиента их установит.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

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