LINUX.ORG.RU
ФорумAdmin

6to4 обработка траффика iptables и ip6tables

 , ,


1

1

Здравствуйте
Имеется сервер. Debian 7 x86_64, ядро 3.2.0-4-amd64
eth1 - белый ip4 адрес eth0 - адрес 192.168.0.1/24(внутренняя сеть)
Настроил 6to4 интерфейс, как описано тут:
6to4.ru
Конфигурация iptables и ip6tables по умолчанию(это временно, не обращайте внимание на то, что для локалки не настроено правил).
ipv6 интернет адреса доступны, все пингуется, также я с другого ipv6-адреса(miredo) могу зайти на данный сервер по ssh.
Теперь про iptables. Допустим я хочу контролировать траффик.
Допустим имеется следующий скрипт для iptables:

#!/bin/bash

#iptables###########################

iptables -F
iptables -X

iptables -t nat -F
iptables -t nat -X

iptables -P INPUT DROP
iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -i eth0 -j ACCEPT

#ip6tables###############################

ip6tables -F
ip6tables -X

ip6tables -P INPUT ACCEPT
ip6tables -P FORWARD ACCEPT
ip6tables -P OUTPUT ACCEPT


Насколько я понимаю, в данном случае в iptables(для ipv4) НЕТ правила, которое разрешает входящие пакеты ipv4 с типом 41 (ipv6), сооветственно входящий ipv6 траффик(не настоящий ipv6, а ipv6 упакованный в ipv4, т.е. фактически это входящий ipv4 траффик) должен блокироваться в соответствии с политикой, которая установилась вызовами:
iptables -P INPUT DROP
iptables -P FORWARD DROP

!!!НО. Они проходят. В соответствии с приведенным скриптом для настройки, я спокойно захожу на данный серевер по ssh (через ipv6), или пингую его посредством ping6, пинг проходит, возвращаются ответы.
Желая разобраться добавил в приведенный скрипт следующие строки:
iptables -A INPUT -p 41 -j LOG --log-level debug --log-prefix "p-41 filter INPUT "
iptables -A OUTPUT -p 41 -j LOG --log-level debug --log-prefix "p-41 filter OUTPUT "
iptables -A FORWARD -p 41 -j LOG --log-level debug --log-prefix "p-41 filter FORWARD  "

iptables -t mangle -A PREROUTING -p 41 -j LOG --log-level debug --log-prefix "p-41 mangle PRE "
iptables -t mangle -A INPUT -p 41 -j LOG --log-level debug --log-prefix "p-41 mangle INPUT "
iptables -t mangle -A OUTPUT -p 41 -j LOG --log-level debug --log-prefix "p-41 mangle OUTPUT "
iptables -t mangle -A FORWARD -p 41 -j LOG --log-level debug --log-prefix "p-41 mangle FORWARD "
iptables -t mangle -A POSTROUTING -p 41 -j LOG --log-level debug --log-prefix "p-41 mangle POST "

iptables -t nat -A PREROUTING -p 41 -j LOG --log-level debug --log-prefix "p-41 nat PRE "
iptables -t nat -A OUTPUT -p 41 -j LOG --log-level debug --log-prefix "p-41 nat OUTPUT "
iptables -t nat -A POSTROUTING -p 41 -j LOG --log-level debug --log-prefix "p-41 nat POST "

iptables -t raw -A PREROUTING -p 41 -j LOG --log-level debug --log-prefix "p-41 raw PRE "
iptables -t raw -A OUTPUT -p 41 -j LOG --log-level debug --log-prefix "p-41 raw OUTPUT "

Т.е. в данном случае, я смотрю через syslog, в каких цепочках побывали пакеты с типом протокола ipv6(41).
Результат(патеты с типом 41 были в):
таблица filter: цепочка OUTPUT
таблица mangle: цепочки PREROUTING, INPUT, OUTPUT, POSTROUTING
таблица raw: цепочки PREROUTING, OUTPUT.

Вопрос: Почему входящие пакеты ipv4 с типом протокола 41(ipv6) не попадают в цепочку INPUT таблицы filter? Может нужно подгрузить какой-нибудь модуль ядра?

★★★★★

iptables -A INPUT -p 41

iptables -I INPUT -p 41

af5 ★★★★★ ()

ну а проще имхо wireshark глянуть

af5 ★★★★★ ()
Ответ на: комментарий от af5

Если ставить iptables -I INPUT -p 41 ...
то так срабатывает правило.
А почему данные пакеты не DROP-ются в соответствии с политикой по умолчанию? (iptables -P INPUT DROP)

rumgot ★★★★★ ()
Ответ на: комментарий от af5

И еще вопрос: Почему есть разница, в начале цепочки будет правило (iptables -I INPUT -p 41) или в конце (команда iptables -A INPUT -p 41) ?

rumgot ★★★★★ ()
Ответ на: комментарий от rumgot

А почему данные пакеты не DROP-ются в соответствии с политикой по умолчанию?

ESTABLISHED,RELATED

af5 ★★★★★ ()
Ответ на: комментарий от rumgot

И еще вопрос: Почему есть разница, в начале цепочки будет правило (iptables -I INPUT -p 41) или в конце (команда iptables -A INPUT -p 41) ?

после первого подходящего ACCEPT правила (ESTABLISHED,RELATED) iptables прекращает мучить пакет и отдает его операционке, соответственно остальные правила не проверяются. А логирование не прерывает дальнейшую проверку.

af5 ★★★★★ ()
Ответ на: комментарий от af5

А почему данный пакет попадает под правило ESTABLISHED,RELATED?
Ведь прежде чем второй и последующий пакеты будут определены как ESTABLISHED, первый пакет должен был быть разрешен в каком-нибудь другом правиле. Но ведь такого разрешения не было.
Или нет?

rumgot ★★★★★ ()
Ответ на: комментарий от rumgot

соединение (туннель) устанавливается как исходящее от тебя (до ipv6 провайдера)

af5 ★★★★★ ()
Последнее исправление: af5 (всего исправлений: 2)
Ответ на: комментарий от af5

Т.е. это соединение устанавливается в момент настройки интерфейса?

rumgot ★★★★★ ()
Ответ на: комментарий от af5

Итого привожу результаты экспериментов.
Вся эта система работает несколько иначе. При использовании технологии 6to4 для получения ipv6 адреса, в момент создания туннельного интерфейса, ИСХОДЯЩИЕ ПОДКЛЮЧЕНИЕ НЕ СОЗДАЕТСЯ(проверял исходящие пакеты).
Тем не менее входящие ipv6 пакеты пропускаются именно по правилу:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Т.к. без этого правила входящие соединения не проходят. Т.е. получается вопрос: как создается подключение, к которому впоследствии сетевой фильтр относит пакеты для входящих ipv6 подключений?
Сразу после загрузки данного сервера входящие ipv6-пакеты(например при ipv6-пинге данного сервера с другого ipv6 адреса) НЕ ПРОХОДЯТ. По прошествии пары минут, входящий ipv6-пинг(или попытка подключиться по ssh) уже проходит.
Смотрим текущие соединения и ищем ipv4-соединения по адресу 192.88.99.1 (6to4-ретранслятор) сразу после загрузки сервера:
watch -n 0,1 "cat /proc/net/nf_conntrack | grep 192.88.99.1"
Так вот сразу после загрузки данная команда совпадений не находит, но через 1-2 минуты появляется соединение с 192.88.99.1 с типом протокола 41 (это как раз наш случай, т.е. ipv6 пакеты, инкапсулированные в ipv4 пакеты). И как только оно появилось, начинают работать входящие ipv6 подключения, но не ранее.
Сбрасываем соединения командой:
conntrack -F
Результат: входящие подключения опять НЕ ИДУТ.
Опять перезагружаемя, врубаем tcpdump и ищем ipv4 пакеты в которых есть адрес хоста 192.88.99.1 , пораллельно смотрим в /proc/net/nf_conntrack на предмет соединений с 192.88.99.1 .
Обнаруживаем вот что: через 1 минуту после перезагрузки, от сервера идет неcколько DNS-запросов по ipv6(на сервере работает bind), сразу отмечаем, что в /proc/net/nf_conntrack появилось соединение с 192.88.99.1 . Пингуем данный сервер по ipv6 с внешнего ipv6-адреса: пинги проходят, ответы получаем.
Сбрасываем соединения командой:
conntrack -F
Результат: входящие ipv6-пинги уже НЕ ИДУТ. Если подождать пока bind выполнит очередной DNS-запрос по ipv6 или самому куда-нибудь обратиться по ipv6(например пингануть какой-нибудь ipv6 хост с данного сервера), то снова в /proc/net/nf_conntrack появится соединение с 192.88.99.1 и снова будут пропускаться входящие ipv6 пакеты(ipv6 пакеты, инкапсулированные в ipv4 пакеты)

Итого получается картина:
Приведенный мной вначале скрипт для конфигурации сетевого фильтра ВСЕ ЖЕ БЛОКИРУЕТ входящий ipv6 траффик(точнее ipv6 траффик, инкапсулированный в ipv4). НО как только появляется исходящие ipv4 соединение с 6to4 ретранслятором 192.88.99.1 по протоколу 41, все последующие входящие ipv4 пакеты от данного хоста с протоколом 41(т.е. фактически любые входящие ipv6 подключения) будут отнесены правилом:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
к этому установленному нашим сервером соединению(и учитывая действие данного правила, будут приняты).

Подводя итог:
В случае необходимости блокирования только входящего ipv6 траффика инскапсулированного в iv4(протокол 41), при наличии разрешия для всех исходящий ipv4 подключений, а также наличии разрешия для входящих ESTABLISHED подключений, нужно устанавливать запрещающие правила для входящих подключений используя ip6tables.
Если нужно разрешить входящий ipv6 траффик инскапсулированный в iv4(протокол 41) то должно быть правило:
iptables -A INPUT -p 41 -j ACCEPT
Это правило нужно, т.к. не обязательно наш сервер будет выполнять исходящие ipv6 соединения(в моем случае это делает bind, а он установлен не всегда), и соответственно не обязательно в системе будет установленное соединение с 192.88.99.1 ; при наличии же указанного правила, входящие ipv6 пакеты, инкапсулированные в ipv4(протокол 41) , будут пропущены всегда.

rumgot ★★★★★ ()
Ответ на: комментарий от rumgot

ИСХОДЯЩИЕ ПОДКЛЮЧЕНИЕ НЕ СОЗДАЕТСЯ

через 1-2 минуты появляется соединение с 192.88.99.1 с типом протокола 41

Ты определись, создаётся или не создаётся

af5 ★★★★★ ()
Ответ на: комментарий от af5

Будь внимательней. Я написал "... в момент создания туннельного интерфейса, ИСХОДЯЩИЕ ПОДКЛЮЧЕНИЕ НЕ СОЗДАЕТСЯ"...
А если есть замечания по написанному мной - с удовольствием прочту.

rumgot ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.