Маршрутизация, помогите пожалуйста, на основе политики?

Question

Мой домашний роутер - это пользовательская коробка Arch Linux. Для дополнительной конфиденциальности / безопасности я настроил его в качестве клиента OpenVPN для сервера OpenVPN, работающего на VPS, на котором я работаю. Весь мой домашний трафик проходит через этот VPN-туннель 24/7. Эта настройка работает отлично.

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

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

Это звучит как выполнимо? Правильно ли я считаю, что мог бы использовать маршрутизацию на основе источника через отдельную таблицу маршрутизации, чтобы обойти туннель vpn клиента маршрутизатора? Какие-либо подводные камни или детали (связанные с iptables или таблицами маршрутизации), о которых нужно знать, чтобы эта работа работала?

Заранее спасибо.

Answer 1

Поэтому, чтобы продолжить, я добился успеха после моего первоначального плана.

Я установил на маршрутизаторе сервер openvpn, доступный только из домашней локальной сети. Если клиент в моей домашней локальной сети хочет получить доступ к Интернету и обойти соединение vpn'd, при котором маршрутизатор обычно направляет весь внутренний трафик через Интернет, он подключается к этой внутренней VPN. Этот vpn-сервер настроен для выдачи статических IP-адресов на основе сертификата клиента. Затем сценарий cl-connect.sh создает отдельную таблицу маршрутизации и правила маршрутизации, так что конкретные предварительно определенные IP-адреса, назначенные клиентам во внутреннем vpn, маршрутизируются через альтернативную таблицу маршрутизации, которая сообщает всем этим соединениям выходить в Интернет, используя не интерфейс tun0 для всего маршрутизатора, а интерфейс unvpn-d eth0, который подключается непосредственно к моему провайдеру. Когда клиенты локальной сети отключаются, сценарий cl-disconnect.sh также удаляет маршруты.

Таким образом, весь трафик моей домашней локальной сети по-прежнему направляется в более широкий Интернет через маршрутизатор и его интерфейс tun0 к общему маршрутизатору VPN по умолчанию. Но клиенты, подключающиеся к этому новому внутреннему vpn-серверу, направляют свой трафик в Интернет, минуя VPN-маршрутизатор и IP-адрес, назначенный моим провайдером.

Я думаю, мне интересно, если каким-то образом использование openvpn является излишним, и простая настройка прокси-сервера (squid?) может быть меньше накладных расходов для маршрутизатора. Но тем не менее, это работает. Спасибо всем, кто присоединился.

Answer 2

Если я правильно понимаю, обычная работа хоста в вашей сети - это просто использовать Интернет с его DHCP или аналогичной конфигурацией ЛВС, и его маршрут по умолчанию отсутствует через службу VPN, скажем, интерфейс tun0

Однако иногда вы не хотели бы использовать заданный по умолчанию маршрут tun0 для сетевой активности на одном или нескольких хостах. Вместо того чтобы отключать службу VPN для всей вашей сети, вы предлагаете вместо этого установить VPN-туннель от хоста LAN до вашего linux-сервера, скажем, tun1 , со своей собственной подсетью, скажем, subnetB , отличной от обычной сети хоста LAN, скажем, subnetA , Вы хотели бы, чтобы трафик из subnetA умолчанию направлялся через tun0 , но трафик из subnetB локальной VPN не выходил через туннель, а оставлялся через eth0 , без туннелирования.

Вместо того чтобы создавать исходный маршрут политики на основе subnetA или subnetB , я предлагаю использовать входящий интерфейс для назначения политики: входящий трафик на eth1 остается на tun0 . Входящий трафик на tun1 уходит на eth0 .