LINUX.ORG.RU
решено Форум — Admin  

Странность работы netfilter/ip6tables с пакетами IPv6


0

2

Настроил на домашнем сервере роутер в IPv6-интернет через Hurricane Electric. Всё в принципе работает, но в процессе настройки столкнулся с такой проблемой: по какой-то причине, пакеты с хостов локалки, предназначенные для хостов «большого» интернета, на роутере проходят в ip6tables не только через цепочку filter:FORWARD (как и должно быть), но и через filter:INPUT (что странно). Хотя по этой схеме такого в принципе не должно быть...

Разрешать все входящие подключения из локалки на роутер я не хочу, поэтому написал такие правила: 

###########################################################################
# FILTER TABLE
###########################################################################
*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT

# Drop invalid TCP packets
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A OUTPUT -m conntrack --ctstate INVALID -j DROP

# Accept all incoming packets on loopback interface
-A INPUT -i lo -j ACCEPT

# Accept incoming packets from established or related connections
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # (1)

#------------
# Forwarding
#------------

# FIXME: WTF?!
-A INPUT -i brlan ! -d 2001:123:1f0b:1a08::/64 -j ACCEPT # (2)
-A INPUT -i brlan ! -d 2001:123:1f0a:1a08::2 -j ACCEPT   # (3)

-A FORWARD -i brlan -j ACCEPT # (4)

#--------------------------
# For all incoming packets
#--------------------------

# ICMP ping
-A INPUT -p icmpv6 -m conntrack --ctstate NEW -m icmpv6 --icmpv6-type echo-request -j ACCEPT

# Traceroute
-A INPUT -p udp -m udp --dport 33434:33534 -m state --state NEW -j REJECT --reject-with icmp6-port-unreachable
# Tracepath
-A INPUT -p udp -m udp --dport 44444:44473 -m state --state NEW -j REJECT --reject-with icmp6-port-unreachable

COMMIT
brlan - это интерфейс (точнее мост), который смотрит в локалку; 2001:123:1f0b:1a08::/64 - моя подсеть; 2001:123:1f0a:1a08::2 - внешний IPv6-адрес роутера. Правила (2) и (3) по идее лишние, так как все пакеты из локалки в интернет должно разрешать правило (4), а обратно - правило (1). В правилах (2) и (3) фильтр по назначению я сделал для того, чтобы хоть как-то закрыть входящие подключения на сам роутер из локалки.

Вопрос: почему пакеты идут так странно?

Deleted
← Репозиторий Debian
Распределение нагрузки между интернет-каналами →

Интересно. Можно сбросить счетчики (iptables -Z), попинговать из локалки 2a00:1450:8001::63, а потом выложить сюда вывод «iptables -vnL»?

// Подозреваю какой-нибудь изврат с маршрутизацией IPv6, когда пакеты адресуются сначала шлюзу, а он уже должен перенаправлять их дальше. В IPv6 подобные костыли считаются хорошим тоном.

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

Интересно. Можно сбросить счетчики (iptables -Z), попинговать из локалки 2a00:1450:8001::63, а потом выложить сюда вывод «iptables -vnL»?

Ок, вечером сделаю.

Кстати, а 2a00:1450:8001::63 - это кто? Один из серверов гугла?

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

>Кстати, а 2a00:1450:8001::63 - это кто? Один из серверов гугла?

Ага.

anonymous
()
Ответ на: комментарий от nnz

На ноуте: 

$ ping6 -c 4 ipv6.google.com
PING ipv6.google.com(2a00:1450:8001::63) 56 data bytes
64 bytes from 2a00:1450:8001::63: icmp_seq=1 ttl=55 time=122 ms
64 bytes from 2a00:1450:8001::63: icmp_seq=2 ttl=55 time=113 ms
64 bytes from 2a00:1450:8001::63: icmp_seq=3 ttl=55 time=114 ms
64 bytes from 2a00:1450:8001::63: icmp_seq=4 ttl=55 time=113 ms

--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 113.136/116.090/122.832/3.927 ms
И после этого на роутере: 
# ip6tables -vnL
Chain INPUT (policy DROP 1 packets, 52 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       tcp      *      *       ::/0                 ::/0                tcp flags:!0x17/0x02 ctstate NEW 
    0     0 DROP       all      *      *       ::/0                 ::/0                ctstate INVALID 
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0                
  529 36698 ACCEPT     all      *      *       ::/0                 ::/0                ctstate RELATED,ESTABLISHED 
    1    64 ACCEPT     all      brlan  *       ::/0                !2001:123:1f0b:1a08::/64 
    0     0 ACCEPT     all      brlan  *       ::/0                !2001:123:1f0a:1a08::2/128 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       tcp      *      *       ::/0                 ::/0                tcp flags:!0x17/0x02 ctstate NEW 
    0     0 DROP       all      *      *       ::/0                 ::/0                ctstate INVALID 
    7   728 ACCEPT     all      *      *       ::/0                 ::/0                ctstate RELATED,ESTABLISHED 
    1   104 ACCEPT     all      brlan  *       ::/0                 ::/0                

Chain OUTPUT (policy ACCEPT 876 packets, 1117K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       tcp      *      *       ::/0                 ::/0                tcp flags:!0x17/0x02 ctstate NEW 
    0     0 DROP       all      *      *       ::/0                 ::/0                ctstate INVALID
Видно, что первый пакет с пингом прошёл через правила (2) и (4), а затем его подхватил conntrack и остальные пакеты пошли через (1) (и аналогичное правило для INPUT). Я пробовал несколько раз, чтобы исключить случайный трафик, - получалась одна и та же картина.

P.S. 529 пакетов на INPUT - это торренты =).

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

Очевидно, что пакеты, прошедшие (2) и (4) — это разные пакеты. У них разница в длине 40 байт.

Померив полный размер ICMPv6-пакета (включая IPv6-заголовки) на своем хосте, я получил 104. Т.е. пинг, как ему и положено, идет через FORWARD. Что за нафиг попадает в INPUT — непонятно. Возможно, днс-запрос, или UPnP какой-нибудь.

Если сообщенный мною сведений недостаточно для однозначного вывода, лучше повторить эксперимент, добавив три условия:
— отрубить торренты
— в правила с «--ctstate RELATED,ESTABLISHED» добавить «--ctdir REPLY», чтобы оставить больше пакетов для лога
— и, собственно, добавить правила с «-j LOG» перед (2) и (4)

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

Очевидно, что пакеты, прошедшие (2) и (4) — это разные пакеты. У них разница в длине 40 байт.

Да, это я ступил.

Что за нафиг попадает в INPUT — непонятно.

Я уже разобрался - это ICMPv6 Neighbout Solicitation. Похоже прежде чем отправлять пакеты, стек IPv6 пытается как-то узнать куда именно их надо отправлять. Короче всё очень хитро...

Сейчас я заменил правила (2) и (3) на 

-A INPUT -i brlan -p icmpv6 -m icmpv6 --icmpv6-type router-solicitation -j ACCEPT
-A INPUT -i brlan -p icmpv6 -m icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
И всё работает.

Вообще надо бы получше разобраться как работает IPv6. Никто не подскажет чего почитать толкового на эту тему? А то вроде механизм работы начинает проясняться, но всё равно многое ещё непонятно =).

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

Оказывается ICMPv6 Neighbor Solicitation и Neighbor Advertisement выполняют примерно те же функции, что и ARP в IPv4.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Репозиторий Debian
Admin
Распределение нагрузки между интернет-каналами →