Маршрутизировать клиентов OpenVPN через Cloudflare? Сначала проверьте роль
Клиент устройства — не маршрутизатор. Убедитесь, что роль Cloudflare пересылает пакеты других хостов, и оставьте собственный туннель сервера на его старом пути.
У вас есть работающий OpenVPN-сервер и хост, на котором также работает программное обеспечение устройства Cloudflare, и очевидный следующий шаг выглядит как направление клиентского трафика к нему. Два работающих соединения на одной машине не образуют транзитный шлюз. Не хватает роли, документированной для пересылки пакетов, принадлежащих кому-то другому, и политики, которая классифицирует эти пакеты при их поступлении.
Перед любым правилом стоят четыре вопроса: какой трафик входит, куда он идёт дальше, как ответы находят обратный путь и что делает дизайн, когда этот второй путь отказывает. Первые два — вопросы возможностей.
Два сервиса на одном хосте — не транзитный путь
Клиент устройства создан для обработки трафика, который возникает на машине, где он работает. Он перехватывает разрешение имён или выбранный трафик приложений и отправляет его через собственный туннель, а его политика написана для пользователя этого устройства и процессов этого устройства. Пакет, пересланный от клиента OpenVPN, не является локальным выводом, поэтому те же правила его не классифицируют. Это не деталь конфигурации, которую можно закрыть более широким правилом, потому что именно она решает, видит ли программа пакет вообще.
Поэтому вопрос дизайна — это вопрос возможностей. Либо у установленного продукта есть документированная роль, которая пересылает трафик для других сетей, либо функция транзита относится совсем к другому месту.
Какая роль Cloudflare имеет право пересылать
Клиент устройства Cloudflare предлагает режимы, различающиеся по охвату: только разрешение имён, трафик от устройства и иногда оба. Ни один из этих режимов не превращает хост в маршрутизатор для частного диапазона, который приходит через другой туннель. Выделенная роль маршрутизации — отдельный продукт с собственным коннектором, регистрацией и сетевой моделью.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Проверьте установленную роль, прежде чем проектировать маршруты вокруг неё. Прочитайте, какой интерфейс создаёт коннектор, объявляет ли он конкретные префиксы или маршрут по умолчанию и применяется ли локальная политика к пересланным пакетам так же, как к локальным. Если обрабатывается только локальный трафик, сервер OpenVPN не может быть точкой транзита, как бы ни было написано правило трансляции.
Здесь же требование к публичному выходу должно быть сформулировано точно. Выход, который предоставляет Cloudflare для пересланного клиентского трафика, — конкретный случай использования, и его нужно подтвердить относительно сервиса, который у вас действительно есть.
Держите внешний туннель независимым от нового маршрута
В тот момент, когда вы добавляете маршрут по умолчанию к новому интерфейсу, собственный исходящий трафик сервера начинает конкурировать за него, и это включает ответы клиентам OpenVPN и вашу SSH-сессию к машине. Обычный симптом — туннель, который устанавливается и затем умирает, или администратор, заблокированный снаружи, пока изменение выглядит сработавшим. Сравните ip route get для конечной точки до и после, и используйте маршрутизацию по политике или маршрут к хосту, чтобы оставить собственный транспорт сервера там, где он был. Выполните это сравнение с самой машины, потому что именно собственный взгляд сервера на его маршрут имеет значение.
Исключение для публичного адреса сервера само по себе недостаточно, потому что обратный путь каждого удалённого администратора — это отдельный поток. Решите, какие из этих потоков должны пережить изменение, и затем проверьте каждый, вместо того чтобы предполагать, что первый покрывает остальные.
Ограничьте пересылку и трансляцию одним потоком
Полученные пакеты следуют пути пересылки, а не локального вывода, поэтому важное правило живёт в хуке forward. Там, где следующему интерфейсу нужна трансляция, ограничьте источник пулом клиентов, назначение разрешённым, а выход — тем единственным интерфейсом. Правило masquerade, привязанное только к интерфейсу, само не выбирает маршрут и не разрешает пересылку в обход любого другого фильтра.
Решите поведение при отказе заранее, а затем проверьте его. Остановите дальнейший путь и убедитесь, что клиенты теряют предназначенный выход, а не тихо возвращаются к обычному восходящему каналу, потому что это тот результат, которого никто не замечает, пока трафик не начинает выходить через неправильную дверь. Повторите проверку для разрешения имён и для IPv6, потому что набор правил только для v4 оставляет путь v6 открытым.
Запишите четыре ответа, на которых вы остановились, и наблюдение, которое доказывает каждый. Транзитный путь, который вы можете описать, — это тот, который вы сможете защитить на следующем разборе инцидентов.