Моя текущая установка состоит из следующих элементов:
eth0
это доступ к шлюзу и eth1
управляет локальной сетью (192.128.2.0/24)eth1
)Когда я настраиваю клиентов на eth1
чтобы использовать 192.168.2.1:4000 в качестве прокси HTTP и HTTPS, все идет хорошо. Однако все мои попытки использовать iptables для автоматизации этого процесса перенаправления пока не увенчались успехом. Вот моя последняя попытка:
iptables -t mangle -A PREROUTING -i eth1 -p tcp -m multiport --dport 80,443 -j TPROXY --on-ip 0.0.0.0 --on-port 4000 --tproxy-mark 1/1
iptables -t mangle -A PREROUTING -i eth0 -s 192.168.1.0/24 -j ACCEPT
iptables -t mangle -A PREROUTING -i eth0 -d 192.168.1.0/24 -j ACCEPT
iptables -t mangle -A PREROUTING -i eth0 -m multiport --sport 80,443 -j MARK --set-mark 1/1
Я понимаю следующее:
Затем я использовал ip
чтобы определить маршрут для маршрутизации политики на основе отметки, которую я установил с iptables
:
ip rule add fwmark 1/1 table 1
ip route add local 0.0.0.0/0 dev lo table 1
И конечно не работает, и я даже не знаю почему ... Может мой прокси-сервер не поддерживает TPROXY
функция, и я должен использовать только MARK
правила ... Но даже тогда я немного потерялся здесь.
Прежде всего, посмотрите здесь: Концепции кеширования перехвата чтобы иметь представление о преимуществах, недостатках или возможных проблемах использования прозрачного прокси.
Во-вторых, трафик HTTPS или ssl не будет работать с обычным прозрачным прокси. У вас должна быть специальная конфигурация под названием ssl-bump, у которого есть свои проблемы с конфиденциальностью.
Третий,
Предполагая, что eth0 является внешним, а eth1 - внутренним (lan, 192.168.1.0/24) интерфейсом, вот два примера правил iptables для перенаправления HTTP-трафика:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 192.168.1.1:3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
Это без использования Tproxy.