Я использую роутер DD-WRT 3.0 для подключения через openVPN. В локальной сети 192.168.1.50 - это устройство, которое не должно проходить через VPN.
(Как настроить брандмауэр, чтобы 192.168.1.50 не проходил через VPN и Как заставить все остальные IP-адреса терять WAN-соединение при отключении / отключении VPN?)
ИЛИ
(Создайте две подсети, одну через VPN (устройства Wi-Fi), а другую прямую (проводные устройства). и Подсеть VPN теряет подключение к глобальной сети, когда VPN отключается)
Я не предпочитаю ни один из вариантов. Как бы то ни было, проще.
Это правило не сработало (для 1-го сценария):
iptables -I FORWARD ! -o tun1 -s 192.168.1.50 -j DROP
Вот таблица маршрутов, которая используется, когда маршрутизатор находится в режиме шлюза:
Кто-то в DD-WRT форум помог мне решить эту проблему наилучшим (самым простым) способом.
Маршрутизация на основе политик - правильный способ решить часть проблемы, связанную с выборочным VPN-туннелированием.. Это одно из полей, в котором вы указываете детали для подключения OpenVPN. Вы должны ввести здесь устройства, которые вы хотите использовать через VPN. Обратите внимание, что из-за ошибки в DD-WRT IP самого маршрутизатора не может быть в этом списке.
Итак, я установил следующее:
А теперь перейдем ко второй части проблемы. отказ в доступе к WAN устройствам, которые должны быть подключены к VPN, когда VPN выключен / не работает можно сделать, введя следующие команды в Сохранить брандмауэр раздел:
iptables -I FORWARD -s 192.168.1.128/25 -o $(nvram get wan_iface) -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -p tcp -s 192.168.1.128/25 -o $(nvram get wan_iface) -m state --state NEW -j REJECT --reject-with tcp-reset
Два примечания относительно вышеуказанных команд:
REJECT
вместо того DROP
так как первое немного дружелюбнее второго. DROP
не отвечает и требует от клиента тайм-аута, что может раздражать пользователей. Напротив, REJECT
заставляет клиента НЕМЕДЛЕННО выйти.NEW
. Проверяя наличие НОВОГО, мы не позволяем этим устройствам инициировать исходящие соединения, но не предотвращаем удаленный доступ к ним и отправку ответов через глобальную сеть (по крайней мере, когда VPN не работает). Если вы хотите предотвратить удаленный доступ, удалите --state NEW
из тех правил. Чтобы заблокировать весь исходящий трафик для клиентов в обычной глобальной сети, вы можете использовать переменную nvram get wan_iface
IPV4_WAN=$(nvram get wan_iface)
iptables -I FORWARD -s 192.168.x.x/24 -o "$IPV4_WAN" -j DROP
Вы захотите определить свою конкретную подсеть IPv4, будьте осторожны, чтобы не заблокировать весь свой диапазон LAN!
Это заблокирует любой исходящий трафик, выходящий за пределы вашего маршрутизатора, если он не подключен к интерфейсу VPN, вы можете подтвердить, выполнив traceroute
на любой внешний IPv4-адрес, вы обнаружите, что после первого прыжка трафик упадет.
Что касается вашего конкретного клиента IPv4, я немного запутался. Разве вы не можете создать подсеть IPv4 для клиентов, которые хотите подключиться к VPN, а затем на основе диапазона убедиться, что 192.168.1.50
клиент не в ней? Затем просто добавьте ACCEPT
правило, разрешающее ему использовать WAN как обычно?
iptables -I FORWARD -s 192.168.1.50 -o "$IPV4_WAN" -j ACCEPT