Всички знаем че блокирането на ICMP е грях. Какво се случва ако без да искаме частично забраним ICMPv6 на един рутер?

СУ имаше дългогодишен проблем с IPv6 свързаността през един VPLS между кампусите. Първите, които обвиняваха, бяха телекома, от който сме взели услугата, които винаги ни убеждаваха че проблемът не е при тях…

В крайна сметка намерихме един работещ IPv6 рутер, който се оказа че случайно е настроен от друг (още тогава бивш) колега. Вече имахме посока, даже успяхме да репродуцираме проблема.

Имаме следните ip6tables правила:

-A INPUT -d ff00::/8 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
...
-A INPUT -p tcp -m tcp -j REJECT --reject-with tcp-reset

Изненада, IPv6 не работи коректно на някои интерфейси. Защо?

Нещо, което може да ни насочи към проблема, е че ip -6 nei add a:b:c::d laddr a:b:c:d:e:f подкарва трафика, тоест имаме проблем с neighbor discovery-то.

Ако добавим -A INPUT -m state --state INVALID -j LOG в iptables, виждаме че дропим NA пакетите от рутерите отсреща. Преглеждаме интрернетите, виждаме че добрите хора в netfilter-devel листата знаят за проблема, и това е by design.

Как се лекува това нещо? Изрично позволяваме ICMPv6 преди изобщо да гледаме conntrack.

-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
...

От цялото това приключение мога да си извадя няколко извода:

  • никога, ама никога не блокирайте ICMP
  • винаги гледайте документация, независимо какво си мислите
  • не вярвайте на хора само защото имат повече трудов стаж от вас