Перенаправляется ли ядром сервера исходящее соединение от клиента OpenVPN к локальной сети за сервером OpenVPN?

Question

Трафик между VPN и остальной частью сети, конечно, проходит через tun0. Для этого трафика FORWARDцепь консультируется как обычно, и вы можете контролировать, кто может подключаться куда. Если ip_forwardне включено, трафик не будет пересылаться.

Если client-to-clientне используется, трафик между клиентами проходит по одному и тому же пути: он появляется в ОС сервера из tun0интерфейса, маршрутизируется должным образом с использованием таблицы маршрутизации ОС, проходит через межсетевой экран, и единственное отличие заключается в том, что он решает, что пункт назначения находится за tun0, поэтому пакет передается через него.

Это не очень эффективно, поскольку процесс OpenVPN находится в пространстве пользователя, а tun0 — в пространстве ядра, и это приводит как минимум к двум изменениям контекста для каждого пакета.

Однако при client-to-clientиспользовании пакеты между клиентами не отображаются на tun0, а цепочка брандмауэра сервера FORWARDне проверяется, и ip_forwardуправление не влияет на их пересылку. Сам процесс OpenVPN становится маршрутизатором со своей собственной таблицей маршрутизации, независимой от хостовой ОС. Вы можете увидеть это с помощью команды statusинтерфейса управления или выгрузить ее в файл состояния. Вы можете управлять маршрутами внутри этого «маршрутизатора» с помощью iprouteдирективы (я полагаю, что это означает «внутренний маршрут»), которая действительна только в файле клиента client-config-dirили динамической конфигурации, сгенерированной скриптом.

Самый простой способ — не думать о VPN как о чем-то особенном. Как только туннель установлен, забудьте о нем, теперь это просто дополнительный обычный интерфейс на каждом компьютере (сервере и клиентах), со всеми этими интерфейсами, подключенными к какому-то обычному простому маршрутизатору. И рассмотрите обычную маршрутизацию и брандмауэр.

Я наконец заметил, что вы пингуете адрессам VPN-серверхотя и назначен на другой интерфейс. Этот пакетне будет пересланов любом случае, поскольку его пункт назначения — сам сервер, поэтому ip_forwardне влияет на то, как обрабатывается этот пакет, и он проходит INPUTцепочку брандмауэра, и ответ пройдет OUTPUT(например, не FORWARDцепочку, как если бы они не были предназначены для самой системы). Пакет войдет в систему из tun0(и будет виден там), но вы не увидите его на , eth0поскольку он не будет отправлен. Он будет обработан локально. То же самое верно и для ответов.

Не имеет значения (для кода, связанного с маршрутизацией), где в системе назначен адрес (какой интерфейс), или какой адрес системы вы используете для доступа к нему. Важно то, принадлежит ли он системе или нет.

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

Другая связанная проблема заключается в том, что некоторые люди используют ping -I <local-address> <address-to-ping>или даже ping -I <interface> <address-to-ping>и думают, что они напрямую выбирают, какой интерфейс будет пинговать. Опять же, это неправильно. Таким образом, вы можете выбрать только то, какойадрес источникаping-запросы будут, но не интерфейс для их отправки; интерфейс будет выбран кодом маршрутизации строго в соответствии с таблицей маршрутизации, основанной исключительно на адресе назначения пакета (я предполагаю, что настройка VRF или RPDB не производилась, но это сложная задача, и те, кто ее настраивал, в любом случае знают об этой функции).

Answer 1