Intereting Posts
Debian 8 – запуск скриптов после загрузки bash эквивалент zsh $ @ Разрешения (ACL), позволяющие создавать только новые файлы, – также необходимы расширенные атрибуты? Постоянное изменение размера стека для каждого процесса Как восстановить удаленный двоичный исполняемый файл запущенного процесса Gnome – окна всегда открываются вверху слева сценарий оболочки для самоубийства После установки Ubuntu разделы не соответствуют установленным каталогам Является ли страница с «битным набором PROT_NONE» подходящей для обмена? Поведение приоритетного наследования в смешанных системах Broadcom BCM4352: Bluetooth не подключается Logrotate больше не читает символический файл конфигурации из-за отсутствия прав root как дифференцировать ошибку, возвращаемую при чтении, и для EOF в сценарии оболочки Rsync не может удалить удаленный файл не существует в локальном Как записывать более одного каталога?

маршрутизировать трафик на определенный порт через определенный интерфейс?

В настоящее время я использую систему, в которой мне нужно иметь возможность отправлять и получать трафик HTTP и HTTPS напрямую, однако весь другой трафик должен проходить через VPN.

Моя настройка:

интерфейсы x2: eth0 (локальная сеть, за маршрутизатором) и tun0 (клиент openvpn)

В настоящее время весь трафик направляется через мой VPN, мне было интересно, если бы можно было не маршрутизировать трафик http и https (80, 443) через VPN.

Вот таблица маршрутизации, когда система и клиент openvpn были запущены:

0.0.0.0/1 via 10.8.13.5 dev tun0 default via 192.168.1.1 dev eth0 10.8.13.1 via 10.8.13.5 dev tun0 10.8.13.5 dev tun0 proto kernel scope link src 10.8.13.6 128.0.0.0/1 via 10.8.13.5 dev tun0 176.67.168.144 via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.56 192.168.1.1 dev eth0 scope link 

Я прочитал другие подобные вопросы, однако либо ответы не перенаправляют трафик, либо просто блокируют его.

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

Маршрутизация находится на уровне IP 3. TCP находится на уровне 4, поэтому одной маршрутизации недостаточно для решения этой проблемы.

Вкратце: интересный трафик должен быть помечен с помощью iptables , а помеченные пакеты выбраны с помощью fwmark ip rule для использования отдельной таблицы маршрутизации. Затем необходимо применить еще два исправления для локально инициируемого / принимающего случая трафика, который является более сложным, чем маршрутизируемый случай. Все настройки, конечно, выполняются в локальной системе.

Таблица маршрутизации 80 (подходящее символическое имя может быть добавлено в /etc/iproute2/rt_tables но это не обязательно) и отметка 0x80 была выбрана «произвольно».

 ip route add table 80 192.168.1.0/24 dev eth0 scope link src 192.168.1.56 ip route add table 80 default dev eth0 via 192.168.1.1 

Использование -I чтобы гарантировать, что правила iptables не будут добавлены слишком поздно. Вы должны проверить свои текущие правила, как изменить порядок, если это необходимо:

 iptables -t mangle -N markports iptables -t mangle -I PREROUTING 1 -j CONNMARK --restore-mark iptables -t mangle -I OUTPUT 1 -m mark --mark 0 -j markports iptables -t mangle -I OUTPUT 2 -j CONNMARK --save-mark iptables -t mangle -A markports -p tcp --dport 80 -j MARK --set-mark 0x80 iptables -t mangle -A markports -p tcp --dport 443 -j MARK --set-mark 0x80 ip rule add fwmark 0x80 lookup 80 

Этот блог: Netfilter Connmark »Для Linux и не только! дает хорошую информацию о CONNMARK .

Это должно было работать, но на самом деле неправильный исходящий IP-адрес по умолчанию будет выбран при первом решении о маршрутизации, потому что маршрут должен был пройти через tun0 . При проверке перенаправления, выполненной из-за метки mangle/OUTPUT (см. Этот stream пакетов в схеме Netfilter и General Networking для уточнения), этот IP не изменится. Если бы трафик обрабатывался вместо локального инициирования, такой проблемы бы не было (использование отдельного пространства имен сети, чтобы убедиться, что это решение для служб, возможно, не для рабочего стола). Так что для этого также требуется слой MASQUERADE (или SNAT для более сложных случаев) поверх него:

 iptables -t nat -I POSTROUTING 1 -m mark --mark 0x80 -j MASQUERADE 

Теперь, когда исходящий IP-адрес правильный, он все еще не работает: фильтр обратного пути срабатывает в обратном пути по той же причине: решение о маршрутизации, принятое до PREROUTING , пока не знает fwmark (несмотря на предыдущую схему размещения mangle/PREROUTING до принятия решения о маршрутизации (это, очевидно, не так), поэтому считает пакеты обратного трафика поддельными и отбрасывает их на раннем этапе. rp_filter интерфейса eth0 должен быть переведен в свободный режим, чтобы это было разрешено. Это может иметь некоторые (очень незначительные проблемы с NAT) проблемы безопасности, но я нашел это неизбежным для этого не маршрутизируемого случая:

 echo 2 > /proc/sys/net/ipv4/conf/eth0/rp_filter 

Вы должны будете найти, как установить его навсегда (например, echo net.ipv4.conf.eth0.rp_filter=2 > /etc/sysctl.d/90-local-loose-mode.conf если ничего не изменит его позже).

Протестировано нормально, используя пространства имен с настройками, аналогичными настройкам OP.

ПРИМЕЧАНИЕ. DNS-запросы по-прежнему будут проходить через туннель. Некоторые геолокационные веб-сервисы могут работать не так, как ожидалось.