Назад | Перейти на главную страницу

IPv6 соединение B с A работает, от A к B происходит сбой, при этом SYN-ACK B принимает ICMP-адресат недоступен, запрещен

Тестирую на IPv6. A - это сервер в Cogent colo с собственным IPv6, назовите его 2001: db8: 1111 :: 1. B - Mac mini за маршрутизатором Airport Extreme за ISP Comcast; маршрутизатор настроен на использование anycast 6to4, а B, скажем, 2002: c000: 202 :: 2.

На B, ssh 2001:db8:1111::1 работает нормально.

На, ssh 2002:c000:202::2 время вышло. (То же самое для любого другого TCP-соединения.) Запуск tcpdump -nnvvvSs0 на B я вижу, что пакет SYN от A доходит до B нормально, но пакет SYN-ACK, возвращающийся от B к A, получает сообщение «пункт назначения недоступен, недоступность запрещена»:

12:16:42.266203 IP6 (hlim 51, next-header TCP (6) payload length: 40) 2001:db8:1111::1.43263 > 2002:c000:201::2.22: Flags [S], cksum 0x6c79 (correct), seq 102729844, win 5760, options [mss 1440,sackOK,TS val 749393277 ecr 0,nop,wscale 7], length 0
12:16:42.266330 IP6 (flowlabel 0xb4ac1, hlim 64, next-header TCP (6) payload length: 44) 2002:c000:202::2.22 > 2001:db8:1111::1.43263: Flags [S.], cksum 0xa0e9 (correct), seq 122191294, ack 102729845, win 65535, options [mss 1440,nop,wscale 3,nop,nop,TS val 1053035827 ecr 749393277,sackOK,eol], length 0
12:16:42.403695 IP6 (hlim 51, next-header ICMPv6 (58) payload length: 92) 2001:db8:1111::1 > 2002:c000:202::2: [icmp6 sum ok] ICMP6, destination unreachable, length 92,  unreachable prohibited 2001:db8:1111::1

Определенно кажется поразительным, что B может отправить SYN в A и установить соединение, но SYN-ACK B отклоняется. Куда мне дальше посмотреть, чтобы понять, почему это происходит?

Редактировать: Вот /etc/sysconfig/ip6tables с сервера A:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmpv6 -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT
#-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
#-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
#-A RH-Firewall-1-INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT
#-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 32768:61000 ! --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A RH-Firewall-1-INPUT -j DROP

COMMIT

Похоже, вам не хватает правила ip6tables, например следующего:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Смена брандмауэра на A исправила это. Мы добавили

-A RH-Firewall-1-INPUT -s 2002:c000:202::2 -j ACCEPT

перед

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited

Для меня все еще немного загадочно, зачем это нужно, когда B -> A уже сработало ...