IPv6 от HE.NET
Раз пошла такая пьянка...
Мне вот интересно, многие ли здешние пользователи используют IPv6 от he.net с динамическим IP?
А мне пришлось: таковы условия работы услуги "Коннект" (уже не подключить). Вкратце: вам выдается подсеть белых адресов размером /29 и динамический белый IP на ppp0, через который "видится" выданная подсеть. И первая проблема, с которой я столкнулся, это обновление динамического IP на he.net (ведь тоннель six0 строится от ppp0, где динамика, а вот бы построить его от br0, где статика!). Inadyn замусорил мне все логи одинаковыми сообщениями:Из этого не было понятно, в чем дело, и я полез на сайт tunnelbroker.net, где нашел инструкцию, как сконструировать URL для обновления динамического IP тоннеля, закинул все в браузер и получил ответ: "Ваш хост не пингуется". Не помню, как я определил адрес, с которого должен пинговаться IP'шник (то ли в в той же инструкции, то ли воспользовался tcpdump, то ли он был в самом сообщении об ошибке), в итоге в post-firewall пришлось добавить строки:Code:Nov 30 08:45:21 INADYN[327]: E: The response of DYNDNS svr was an error! Aborting. Nov 30 08:45:22 INADYN[327]: W:Error validating DYNDNS svr answer. Check usr,pass,hostname,abuse...! Nov 30 08:45:22 INADYN[327]: W:DYNDNS Server response: HTTP/1.1 200 OK^M Date: Tue, 30 Nov 2010 05:45:21 GMT^M Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g^M X-Powered-By: PHP/5.2.4-2ubuntu5.10^M Set-Cookie: PHPSESSID=96ccbeffd9aa4e4f5d78b0f4a4f47767; path=/^M Expires: Thu, 19 Nov 1981 08:52:00 GMT^M Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0^M Pragma: no-cache^M Content-Length: 37^M Connection: close^M Cont Nov 30 08:45:22 INADYN[327]: W:'RC_DYNDNS_RSP_NOTOK' (0x48) updating the IPs. (it 0) Nov 30 08:45:22 INADYN[327]: E: The response of DYNDNS svr was an error! Aborting. Nov 30 08:45:23 INADYN[327]: W:Error validating DYNDNS svr answer. Check usr,pass,hostname,abuse...! Nov 30 08:45:23 INADYN[327]: W:DYNDNS Server response: HTTP/1.1 200 OK^M Date: Tue, 30 Nov 2010 05:45:22 GMT^M Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g^M X-Powered-By: PHP/5.2.4-2ubuntu5.10^M Set-Cookie: PHPSESSID=21155c4d140bd0960556ccab9ec7ed50; path=/^M Expires: Thu, 19 Nov 1981 08:52:00 GMT^M Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0^M Pragma: no-cache^M Content-Length: 37^M Connection: close^M Cont Nov 30 08:45:23 INADYN[327]: W:'RC_DYNDNS_RSP_NOTOK' (0x48) updating the IPs. (it 0) Nov 30 08:45:23 INADYN[327]: E: The response of DYNDNS svr was an error! Aborting. Nov 30 08:45:23 INADYN[327]: W:Error validating DYNDNS svr answer. Check usr,pass,hostname,abuse...! Nov 30 08:45:23 INADYN[327]: W:DYNDNS Server response: HTTP/1.1 200 OK^M Date: Tue, 30 Nov 2010 05:45:23 GMT^M Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g^M X-Powered-By: PHP/5.2.4-2ubuntu5.10^M Set-Cookie: PHPSESSID=19e891feb404f45d186b59ef5159cbdd; path=/^M Expires: Thu, 19 Nov 1981 08:52:00 GMT^M Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0^M Pragma: no-cache^M Content-Length: 37^M Connection: close^M Cont Nov 30 08:45:23 INADYN[327]: W:'RC_DYNDNS_RSP_NOTOK' (0x48) updating the IPs. (it 0) Nov 30 08:45:23 INADYN[327]: E: The response of DYNDNS svr was an error! Aborting. Nov 30 08:45:24 INADYN[327]: W:Error validating DYNDNS svr answer. Check usr,pass,hostname,abuse...!Вот к стати топик на tunnelbroker.net, но он появился позже.Code:iptables -D INPUT -j DROP iptables -A INPUT -s 66.220.2.74 -p icmp -j ACCEPT iptables -A INPUT -j DROP
Все бы хорошо, но тут совсем недавно свалилась еще одна "радость": отвалился IPv6-тоннель, смотрю логи, а мне Inadyn пишет, что тоннеля с таким ID не существует (да, Inadyn стал более информативным, но все так же любит замусоривать логи)! Я сразу же строчу в саппорт, а мне Kelly Cochran отвечает:I see it was purged for not replying to a ping to the client IPv6 address for the past two years.а я ему, мол столько лет, столько зим все работало прекрасно, столько гигов трафика прокачано, а тут вдруг, на тебе, удалили; объяснил ему, что роутер не пингуется специально, а он мне:
В итоге я его уговорил вернуть мой тоннель обратно, а за это мне пришлось добавить в post-firewall еще пару строчек:If you're blocking all ICMPv6, you're actually impeding a fair bit of some required functionality of IPv6, such as Path MTU Discovery. See RFC4890 for guidelines of IPv6 ICMPv6 filtering.
We also need to be able to ping that address as it's really the only way to ensure there's something properly speaking v6 on the other side.Вот такая история...Code:ip6tables -D INPUT -p ipv6-icmp -m icmp6 ! --icmpv6-type 128 -j ACCEPT ip6tables -I INPUT 2 -p ipv6-icmp -j ACCEPT
Reply With Quote
