Маршрутизация, помогите, пожалуйста, на основе политики?
Мой домашний роутер - это встроенная в Linux коробка Linux. Для дополнительной конфиденциальности / безопасности я настроил его в качестве клиента OpenVPN для сервера OpenVPN, работающего на VPS, на котором я работаю. Весь мой домашний трафик проходит через этот VPN-туннель 24/7. Эта настройка работает отлично.
Иногда мне хотелось бы, чтобы какой-то трафик обходил туннель vpn и использовал мое обычное соединение без VPN. IP-адреса назначения многочисленны и разнообразны, поэтому просто невозможно жестко закодировать статические маршруты.
Вместо этого я решил настроить экземпляр сервера openvpn на маршрутизаторе, доступный для клиентов в локальной сети, а затем использовать маршрутизацию на основе политик для маршрутизации всего трафика из этой подсети vpn (подключенных клиентов) напрямую через подключение к Интернету, минуя туннель, через который проходит весь другой интернет-трафик. Таким образом, клиенты в моей домашней сети могут подключаться к этому внутреннему vpn и выходить в Интернет, не проходя через туннель vpn маршрутизатора.
Это звучит как выполнимо? Правильно ли я считаю, что мог бы использовать маршрутизацию на основе источника через отдельную таблицу маршрутизации, чтобы обойти туннель vpn клиента маршрутизатора? Какие-нибудь подводные камни или детали (связанные с iptables или таблицами маршрутизации), о которых нужно знать, чтобы это работало?
Заранее спасибо.
2 ответа
Таким образом, чтобы продолжить, я был успешным, следуя моему первоначальному плану.
Я настроил на маршрутизаторе сервер 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?) Может быть менее затратной для маршрутизатора. Но тем не менее, это работает. Спасибо всем, кто присоединился.
Если я правильно понимаю, обычная работа хоста в вашей сети - это просто использовать Интернет с его DHCP или аналогичной конфигурацией локальной сети, и его маршрут по умолчанию отсутствует через службу VPN, скажем, интерфейс tun0
Однако иногда вы бы не хотели использовать значение по умолчанию tun0 маршрут для сетевой активности на одном или нескольких хостах. Вместо того, чтобы отключать службу VPN для всей вашей сети, вы предлагаете вместо этого установить VPN-туннель от хоста LAN до вашего сервера Linux, скажем tun1, скажем, со своей подсетью subnetBв отличие от обычной локальной сети, скажем, subnetA, Вы хотели бы получить трафик от subnetA по умолчанию маршрутизируется через tun0, но трафик с локальных VPN subnetB не выходить через туннель, а выйти через eth0без туннеля.
Я предлагаю, а не делать исходный маршрут политики на основе subnetA или же subnetB, что вы используете входящий интерфейс для назначения политики: Входящий трафик включен eth1 выходит на tun0, Входящий трафик включен tun1 выходит на eth0,