iptables: доступ к подключенному клиенту openvpn из локальной сети с помощью сервера VPN

После очередного изнурительного раунда безумного онлайн-обучения iptables я нашел решение.

Во-первых, однако, есть неверное предположение относительно iptables. Мой первоначальный подход к правилам заключался в том, что при получении пакета он проходил через цепочки INPUT и OUTPUT. Не так; Как только правило соответствует пакету, оно покидает таблицу. Поскольку предполагается, что таблица фильтров не указана (например, "-t nat"), большинство перечисленных правил выполняется в таблице фильтров.

Что касается цепей

• ВВОД : запускать пакеты, предназначенные для сервера
• ВЫВОД : запускать пакеты, исходящие от сервера
• ВПЕРЕД : все остальное - если здесь совпадает правило, и "прыгать" (мне нравится думать, если -j as "job";) равно ACCEPT, пакет будет маршрутизирован соответствующим образом

Нарушение правил

Это описание правил под текущие настройки выше

iptables -t filter -F
iptables -t nat -F

Эти правила просто смывают фильтр и нац таблицы. Обратите внимание, что существует больше таблиц и более тщательный способ очистки правил iptables.

iptables -A INPUT -i tun+ -j ACCEPT

Это правило ничего не делает, потому что:

• он работает с трафиком, предназначенным для VPN1, а не для другой сети
• для входящего трафика не задана политика, поэтому она разрешена по умолчанию

двигаться дальше ...

iptables -A FORWARD -i tun+ -j ACCEPT

Это правило разрешает маршрутизацию трафика из 10.8.8.0/24. Правила в нац table запускается на пакетах, соответствующих этому правилу.

iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24

Это правило также не влияет на желаемую маршрутизацию, поскольку трафик 10.8.8.0/24 не предназначен для сервера VPN1.

iptables -A FORWARD -i eth0 -j ACCEPT

Это правило разрешает маршрутизацию трафика с 10.10.10.0/16.

iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE

Это правило приводит к тому, что трафик, предназначенный для VPN с 10.10.10.0/16, выглядит так, как будто он исходит от VPN1, что фактически приводит к тому, что VPN1 выглядит как шлюз.

В чем дело?

Правила должны быть "ОК", как и для передачи трафика из одной сети в другую. Нет никакой реальной защиты - например, политика "DROP" по умолчанию и т. д., но вопрос не в этом.

Если iptables настроен так, что он может маршрутизировать трафик через VPN, что может привести к его отправке обратно через eth0 к шлюзу? Если бы VPN1 не знал о 10.8.8.0/24. Если VPN-сервер не знает об этой сети, он будет рассматриваться как интернет-трафик и отправлен обратно на шлюз.

Исправление

Решением было сообщить VPN-серверу о сети (это сервер openvpn). Есть два способа сделать это; если сервер обслуживает только одну сеть, это простая настройка конфигурации:

server 10.8.8.0 255.255.255.0

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

server 10.5.5.0 255.255.255.0
route 10.8.8.0 255.255.255.0

Это оно! Как только у VPN1 есть маршрут к сети, цепочка FORWARD может маршрутизировать трафик.

Лучшая настройка iptables

После очистки iptables лучшая конфигурация будет выглядеть примерно так:

# Forward established traffic so that (in the above case) VPN1 doesn't
# drop responses from the client, A.K.A. "the magic"
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A FORWARD     -s 10.10.10.0/16 -d 10.8.8.0/24  -j ACCEPT
iptables -t nat    -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24  -j MASQUERADE

# Drop everything else that wants to be forwarded
iptables -P FORWARD DROP

Обратите внимание, что нет явных правил для трафика, поступающего из 10.8.8.0/24, что означает, что по умолчанию трафик не достигает сети 10.10.10.0/16 - за исключением трафика в ответ на трафик, отправленный с 10.10.10.0/16. . Теперь, когда iptables настроен, клиентам может быть назначен IP-адрес в конфигурации VPN и добавлен в DNS для полного решения.