Перенаправьте HTTP-трафик с локальной сети на внешний прокси-сервер с помощью iptables на моем маршрутизаторе

1019
ccampo

Моя цель - прозрачно проксировать все HTTP-запросы от одного IP (мой ноутбук 192.168.1.134) в моей локальной сети до внешнего IP (скажем, интернет-VPS X.X.X.X), на котором работает прокси-сервер (в частности, mitmproxyв прозрачном режиме), прослушивающий порт 80.

Моя домашняя локальная сеть работает на маршрутизаторе ASUS RT-N66U с прошивкой Asuswrt-Merlin. Маршрутизатор имеет ip 192.168.1.1и является шлюзом по умолчанию для каждого устройства в моей сети. Для пересылки трафика я подключил ssh'd к маршрутизатору и выполнил следующие iptablesкоманды:

iptables -t nat -A PREROUTING -s 192.168.1.134 -p tcp --dport 80 -j DNAT --to X.X.X.X:80 iptables -t nat -A POSTROUTING -j MASQUERADE

Кроме того, на моем маршрутизаторе включена переадресация IP:

admin@RT-N66U:/tmp/home/root# cat /proc/sys/net/ipv4/ip_forward 1

Это приводит к чему-то, но это не то, что я ожидаю. С 192.168.1.134(моего ноутбука), когда я делаю простой http-запрос (например curl http://example.com), я могу видеть в журнале событий моего прокси-сервера, который mitmproxyсообщает, что клиент подключился (используя открытый IP-адрес NAT моего маршрутизатора, выданный моим провайдером), однако это примерно, насколько это возможно. Это никогда не идет дальше, и моя команда curl просто ждет. В конце концов я вижу «Сброс соединения по одноранговой сети» в журнале моего прокси, и соединение закрывается.

Любая помощь будет предложена. Я должен признать, я не очень опытный с iptables.

1
Возможно, потому что mitmproxy в прозрачном режиме должен работать на маршрутизаторе, поэтому он получает конкретную информацию от iptables (см. Http://docs.mitmproxy.org/en/latest/transparent/linux.html). Это не будет работать, если перенаправление произойдет раньше: пункт назначения потерян. ИЛИ вам просто нужно «делать что-то» с помощью mitmproxy (редактировать, принимать ...) A.B 7 лет назад 0
@AB Должен заметить, что я успешно установил это, когда прокси-сервер находится в локальной сети, например, Raspberry PI. Это как-то связано с тем, что прокси-сервер находится в глобальной сети. ccampo 7 лет назад 0
Я верен тому, что сказал. http://docs.mitmproxy.org/en/latest/howmitmproxy.html#transparent-http цитата: «Первый - это механизм перенаправления, который прозрачно перенаправляет TCP-соединение, предназначенное для сервера в Интернете, на прослушивающий прокси-сервер. обычно принимает форму брандмауэра ** на том же хосте, что и прокси-сервер ** - iptables в Linux "и" Механизм маршрутизации, который выполнил перенаправление **, отслеживает исходное назначение для нас ** ". Эта информация была потеряна. Вы можете заставить его работать с туннелем между вашим gw и mitmproxy и перенаправлять только на прокси. A.B 7 лет назад 0
Кстати, современный метод заключается в использовании TPROXY, REDIRECT остается приемлемым (это то, что ожидает mitmproxy, поэтому другого выбора нет), а DNAT вообще не может работать: исходный пункт назначения теряется за пределами fw / router. A.B 7 лет назад 0
@AB не уверен, что вы следуете тому, что я говорю, но у меня есть прозрачный режим для работы, когда прокси-сервер был на другом компьютере, кроме маршрутизатора, в пределах локальной сети. См. Пример: https://gist.github.com/ccampo133/755b45e966dc736f71137e049ed5f0c8 Забудьте о mitmproxy, забудьте о прозрачном режиме, даже ... забудьте обо всех деталях, относящихся к митму. Давайте поговорим обратный прокси. Это может быть nginx. Дело в том, что он все еще не работает, если прокси-сервер находится в глобальной сети, а не в локальной сети, и я хочу знать, возможно ли заставить его работать. ccampo 7 лет назад 0
`ip route add default через 192.168.1.139 dev br0 таблица 2` не теряет целевой IP. `iptables -t nat -A PREROUTING -s 192.168.1.134 -p tcp --dport 80 -j DNAT - до XXXX: 80` делает. Оба перенаправляют на прокси. Первый сохраняет исходный IP-адрес назначения, а прокси-сервер знает, где продолжить свою работу, второй - нет, прокси-сервер не имеет ни малейшего представления, что делать дальше. Лучшее, что он может сделать для HTTP - это разрешить заголовок Host: медленный и ненадежный для mitm. Итак, вы можете сделать перенаправление в другом месте, но прокси должен быть следующим маршрутизатором. С туннелем к прокси это все еще возможно. A.B 7 лет назад 0
Я не знаю, для nginx, но я думаю, что squid в режиме ускорения будет работать для HTTP с вашими текущими настройками (путем разрешения заголовка Host). A.B 7 лет назад 0
так ты согласен? A.B 7 лет назад 0

0 ответов на вопрос

Похожие вопросы