Рад сообщить, что «непорядок» теперь доступен по IPv6. Те, кто используют IPv6, увидят маленький синий значок «v6» рядом с названием сайта.
К сожалению Linode не предоставляет собственной IPv6 связности, но дает подробные инструкции, как получить оную через туннель от Hurricane Electric, он же Tunnel Broker. Ширина полосы в бесплатном туннеле конечно регулируется, но на времени отклика это никак не сказывается. Одна из точек присутствия Hurricane Electric находится в Лондоне, там же расположен ДЦ Linode, где у меня VPS. Поэтому вход в туннель оказывается очень близко:
li153-251:~# ip link show 6in4
11: 6in4@NONE:
mtu 1280 qdisc noqueue state UNKNOWN
link/sit 0.0.0.0 peer 216.66.80.26
li153-251:~# traceroute 216.66.80.26
traceroute to 216.66.80.26 (216.66.80.26), 30 hops max, 40 byte packets
1 109.74.192.2 (109.74.192.2) 0.437 ms 0.462 ms 0.526 ms
2 te3-1-border76-01.lon2.telecity.net (217.20.44.217) 0.744 ms * *
3 217.20.44.194 (217.20.44.194) 0.687 ms * *
4 10gigabitethernet1-1.core1.lon1.he.net (195.66.224.21) 8.024 ms 7.974 ms 7.829 ms
5 tserv5.lon1.ipv6.he.net (216.66.80.26) 0.938 ms 0.779 ms 0.812 ms
li153-251:~# ping -c3 216.66.80.26
PING 216.66.80.26 (216.66.80.26) 56(84) bytes of data.
64 bytes from 216.66.80.26: icmp_seq=1 ttl=60 time=1.02 ms
64 bytes from 216.66.80.26: icmp_seq=2 ttl=60 time=3.39 ms
64 bytes from 216.66.80.26: icmp_seq=3 ttl=60 time=2.98 ms
--- 216.66.80.26 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 1.021/2.466/3.398/1.036 ms
Непосредственная связность с внешним миром тоже очень хорошая, наличие туннеля совсем незаметно:
li153-251:~# ping6 -c3 ipv6.google.com PING ipv6.google.com(2a00:1450:8006::68) 56 data bytes 64 bytes from 2a00:1450:8006::68: icmp_seq=1 ttl=57 time=8.25 ms 64 bytes from 2a00:1450:8006::68: icmp_seq=2 ttl=57 time=8.35 ms 64 bytes from 2a00:1450:8006::68: icmp_seq=3 ttl=57 time=8.75 ms --- ipv6.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 8.259/8.458/8.758/0.240 ms
Для того, чтобы nginx начал обрабатывать IPv6 запросы, пришлось обновить его до версии 0.7.65. В стандартном репозитории Debian Lenny есть только версия 0.6.32, поэтому пришлось подключить репозиторий Backports и ставить из него.
Еще один интересный момент связан с конфигурацией. nginx по умолчанию открывает порт только для IPv4 соединений, это задает директива listen в файле /etc/nginx/sites-available/default:
listen 80 default;
Чтобы принимать IPv6 соединения, нужно добавить еще одну директиву listen для IPv6:
listen [::] default;
Специальный адрес [::] является так называемым wildcard и означает «все IPv6 адреса». Однако с такой конфигурацией nginx не запускается и выдает ошибку:
[emerg]: bind() to [::]:80 failed (98: Address already in use)
Дело в том, что в IPv6 существует такое понятие как IPv4-mapped адрес. Суть его в том, что пространство IPv4 адресов отображается в пространство IPv6 адресов с помощью специального префикса ::ffff. Сделано это, видимо, для облегчения процесса перехода на новый протокол. Покойный itojun говорил, что это возможность является потенциальной дырой в безопасности, поэтому, например, в OpenBSD она отключена. В других системах, более терпимых к дырам, наличие этой возможности контролируется специальным параметром для сокетов IPV6_V6ONLY. И в Linux по умолчанию IPv4-mapped адреса включены. Это приводит к тому, что вызов bind(2) с IPv6 wildcard в качестве адреса пытается помимо IPv6 адресов захватить и IPv4 адреса, которые уже заняты предыдущей директивой listen. Чтобы решить проблему, необходимо отключить IPv4-mapped адреса с помощью параметра ipv6only в конфиге nginx:
listen [::] default ipv6only=on;