IPTables и прозрачные прокси

Я установил локальный прозрачный прокси TCP на localhost . Я хочу перенаправить весь TCP-трафик на этот прокси-сервер, чтобы он мог справиться с этим, и ничего не «просочилось», обойдя прокси. Мне нужно использовать IPTables для перенаправления трафика. Я думал об использовании TPROXY, но для этого требуется поддержка приложений, и на данный момент поддерживается только цель REDIRECT.

Я использовал следующие правила IPTables:

 iptables -t nat -A OUTPUT -o lo -j RETURN iptables -t nat -A OUTPUT -d 127.0.0.0/8 -j RETURN iptables -t nat -A OUTPUT -d 192.168.0.0/16 -j RETURN iptables -t nat -A OUTPUT -m owner --uid-owner proxy-owner -j RETURN iptables -t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports $PROXY_PORT iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -d 127.0.0.0/8 -j ACCEPT iptables -A OUTPUT -m owner --uid-owner proxy-owner -j ACCEPT iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -j LOG iptables -P OUTPUT DROP 

Кажется, они работают нормально, однако я смущен, почему.

Вот два вопроса, на которые я до сих пор не знаю ответа:

1) Что касается последнего правила в таблице NAT, почему я хочу только перенаправить SYN-пакеты на локальный прокси-порт ( --syn )? Я хочу перенаправить все TCP-пакеты. В текущей конфигурации кажется, что только пакет SYN перенаправляется на локальный прокси, и всем другим пакетам разрешено напрямую поступать в пункт назначения, что приводит (теоретически) к полному беспорядку (или все, кроме SYN, блокируются фильтром Таблица). Однако, если я --syn параметр --syn и перенаправляю ВСЕ пакеты к локальному прокси, прокси-сервер вообще не работает. Зачем?

2) Что касается 4-го правила в таблице фильтров, почему мне нужно явно разрешать исходящие установленные соединения? Прокси-сервер – это единственное приложение, которому разрешено отправлять пакеты в не-localhost-адресаты в любом случае, и ему уже разрешено это делать (правило 3), поэтому для чего мне нужно 4-е правило? Похоже, он позволяет прокси-соединениям обойти прокси-сервер.

Спасибо!

3 Solutions collect form web for “IPTables и прозрачные прокси”

Обе части вашего вопроса связаны.

Часть (1) захватывает пакет SYN и перенаправляет его, как вы предлагаете. С этого момента conntrack (2) берет на себя и признает, что каждый последующий пакет в этом потоке является частью одного и того же соединения и перенаправляет его так же, как исходный пакет SYN.

Обзор отслеживания соединений можно найти по адресу http://en.wikipedia.org/wiki/Netfilter#Connection_Tracking

ответы:

  1. Причина, по которой вы хотите только сопоставить SYN, двояка. Во-первых, все последующие установленные пакеты будут переданы conntrack (вторая строка, о которой вы просили). Все, что не соответствует conntrack и также не является SYN, является неустановленным пакетом и не принадлежит. Поэтому на этом этапе игнорируется, а затем, наконец, окончательно отбрасывается последним правилом в вашей таблице фильтров. Это способ защиты вашего прокси-процесса от активности ваших пользователей. Например, некоторые формы сетевых зондов начинают отправлять с помощью ACK или FIN только для того, чтобы увидеть, как будет реагировать пульт, и некоторые приложения ужасно умирают, когда получат неверные / неожиданные пакеты.

  2. Почему явным образом разрешаю трафик conntrack-ed? Потому что последняя строка без разбора бросает все. Оставив падение и удалив conntrack, вы отбросите пакеты от вашего прокси, обратившись к клиентам. Здесь очень тонкое различие. Линии, которые соответствуют основанию владельца uid, соответствуют только пакетам, созданным владельцем прокси. Входящие пакеты от клиентов, которые доставляются в прокси-сервер, не принадлежат прокси-серверу.

Рассмотрим следующую диаграмму:

 [ client ] <---traffic---> [ proxy ] <---traffic---> [ target ] 

Трафик слева между клиентом и прокси-сервером не принадлежит прокси-серверу (он был создан ненадежным источником вне системы) и, таким образом, не соответствует строке фильтра 3, что означает, что без линии фильтра 4 она будет отброшена линия фильтра шесть.

Трафик справа от прокси-сервера и целевого объекта принадлежит прокси-серверу (он был создан процессом, запущенным под локальным UID), и поэтому он всегда разрешен с помощью строки 4 и линии фильтра 3.

В вашем случае конкретно, поскольку все это выполняется локально, это может быть не совсем лучший подход. Существует множество способов, которыми вы можете iptables правилами iptables . На самом деле это сводится к тому, что это все равно будет работать для вас. Если вы узнаете больше об iptables, вы можете массировать правила, но вы можете оставить его как есть и быть в порядке.

Надеюсь, это поможет. Это довольно сложная тема.

Мне нужно использовать iptables для перенаправления трафика

Нет – вы просто настроили свою сеть, так что это единственный хост с доступом в Интернет и рассказывающий все остальное, чтобы использовать его в качестве маршрутизатора.

Другой материал, который вам нужен, это просто NAT / masquerading – попытка заставить его вести себя как прокси-сервер просто глупо.

  • Как использовать lsof для идентификации входящих TCP-соединений?
  • Есть ли способ имитировать сокет, застрявший в CLOSE_WAIT или FIN_WAIT2?
  • Прозрачное проксирование TCP-соединений на порту (в основном, без доступа root)
  • Маршрутизация входящих сетевых запросов для данного порта в разные приложения
  • Как читать строки с фиксированной скоростью?
  • Linux «ip route» изменяет адрес источника TCP, но не UDP
  • «Netstat -p» / «ss -p» не показывает процесс прослушивания порта
  • Хранение огромных данных в ядре Linux
  • Отбросить пакеты TCP и предотвратить повторную передачу TCP
  • Какие порты будут использовать ssh-демон?
  • Почему этот простой клиент Perl не работает?
  • Linux и Unix - лучшая ОС в мире.