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 – попытка заставить его вести себя как прокси-сервер просто глупо.

  • проверить прием пакетов tcp ниже уровня tcpdump
  • Как узнать, сколько повторных передач TCP происходит?
  • Почему состояние TCP TIME-WAIT присутствует на обоих концах после завершения соединения?
  • Время ожидания балансировки нагрузки Apache
  • Эфемерный порт: что это такое и что он делает?
  • Запуск сканирования локального порта и обнаружение открытых портов, но не знаете, для чего они используются?
  • Почему некоторые пакеты сброса TCP отображаются в моем журнале iptables?
  • Переадресация портов и маскировка
  • Socat открывает TCP только при открытии PTY
  • TCP SYN, ACK Retransmissions
  • Почему для очистки прослушивающего TCP-порта после завершения программы требуется несколько минут?
  • Linux и Unix - лучшая ОС в мире.