Теперь, когда Amazon расширил IPv6 поддержка VPC в большинстве своих глобальных регионов, включая eu-west-1, я пытаюсь подключить свои экземпляры. К сожалению, я не могу заставить работать маршрутизацию.
Я выполнил шаги в руководство по миграции, т.е. я связал IPv6 CIDR с нашим VPC, назначил его часть нашей «общедоступной» подсети, обновил таблицу маршрутов VPC для отправки ::/0 через igw (интернет-шлюз), убедился, что таблица маршрутов назначена общедоступной подсети, и назначил адреса IPv6 некоторым новым экземплярам Ubuntu 16.04 из консоли.
Затем я настроил Ubuntu для получения назначенного адреса через DHCPv6. как описано здесь, добавляя iface eth0 inet6 dhcp к настройке сети и перезагрузке.
Когда я перезагружаю экземпляр, он запускается на несколько минут дольше, но в конце концов я могу войти в систему и ip a s показывает настроенный IPv4 и глобальный IPv6-адрес.
Однако сеть v6 не работает:
# ping6 www.google.com
connect: Network is unreachable
В таблице маршрутов действительно отсутствует маршрут по умолчанию:
# ip -6 route
2001:DB8:1234:1234:1234:1234:1234:1234 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256 mtu 9001
Добавление маршрута v6 по умолчанию вручную через ip -6 route add default dev eth0 приводит к таблице маршрутизации, которая выглядит правильно:
# ip -6 route
2001:DB8:1234:1234:1234:1234:1234:1234 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256 mtu 9001
default dev eth0 metric 1024
К сожалению, это приводит к другой ошибке:
# ping6 www.google.com
PING www.google.com(dh-in-x6a.1e100.net) 56 data bytes
From dh-in-x6a.1e100.net icmp_seq=1 Destination unreachable: Address unreachable
From dh-in-x6a.1e100.net icmp_seq=2 Destination unreachable: Address unreachable
From dh-in-x6a.1e100.net icmp_seq=3 Destination unreachable: Address unreachable
Разве DHCPv6-клиент не должен заботиться о добавлении маршрута по умолчанию? И почему я даже тогда не могу выйти во внешний мир?
Ваша таблица маршрутизации выглядит некорректно. Эта строка выглядит очень неправильно:
default dev eth0 metric 1024
В этой строке говорится, что весь Интернет подключен напрямую к вашему eth0 интерфейс без необходимости проходить через какие-либо промежуточные маршрутизаторы. Это заставит вашу систему отправлять запросы на обнаружение соседей в LAN для каждого хоста, которого она пытается достичь. И если этот хост не подключен напрямую к вашей локальной сети, он не увидит запрос на обнаружение соседей.
Таким образом, вы не можете ожидать, что что-то будет работать с этой таблицей маршрутизации. С некоторыми маршрутизаторами можно настроить соседний маршрутизатор, чтобы обойти вашу неправильную конфигурацию. Но рассчитывать на это не стоит. Вместо этого вам следует выяснить, какой правильный адрес шлюза, и настроить его.
Вот пример того, как выглядит запись в таблице маршрутизации на одном конкретном компьютере с функциональным подключением:
default via fe80::1 dev eth0 metric 1024 advmss 1220
В via fe80::1 часть - это то, чего не хватает в твоей. Предполагаемый адрес может отличаться от fe80::1, вам нужно будет спросить у своего провайдера, какой адрес шлюза использовать, если он вам этого не сказал. Я чаще всего видел, чтобы провайдеры обращались к своему шлюзу двумя способами: fe80::1 или /64 префикс, за которым следует ::1 который в вашем случае станет 2001:DB8:1234:1234::1.
В advmss 1220 часть не является абсолютно необходимой, но я включаю ее, потому что она поможет обойти некоторые проблемы с MTU.
После того, как вы исправили запись в таблице маршрутизации, следующим шагом для тестирования является проверка того, что маршрутизатор отображается в кэше вашего соседа. А затем используйте traceroute6 или mtr чтобы узнать, как далеко вы можете забрать пакеты, прежде чем они потеряются.
Оказалось, что я пропустил шаг в руководстве по миграции.
При включении IPv6 на существующем VPC некоторые вещи, такие как таблицы маршрутизации и группы безопасности, необходимо обновить вручную, если вы внесли изменения в настройки по умолчанию.
Я обновил нашу таблицу маршрутов (согласно http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-routes) и группы безопасности (согласно http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-sg-rules), но забыл обновить наш сетевой ACL, как упоминалось на той же странице.
Итак, я эффективно блокировал весь трафик IPv6. Добавление правил РАЗРЕШЕНИЯ для входящих и исходящих сообщений для ::/0 исправил мою проблему для Ubuntu 16.04.
Для Ubuntu 14.04 на самом деле в руководстве по миграции Amazon была ошибка, которая с тех пор исправлена. Совет добавить iface eth0 inet6 dhcp к /etc/networking/interfaces.d/eth0.cfg не сработало, что привело к настроенному IPv6-адресу, но отсутствовал маршрут по умолчанию.
Вместо этого мне пришлось запускать dhcp-client при появлении интерфейса, вот так: up dhclient -6. В итоге я получил следующую рабочую конфигурацию в /etc/networking/interfaces.d/eth0.cfg файл:
# The primary network interface
auto eth0
iface eth0 inet dhcp
up dhclient -6 -v -pf /run/dhclient6.$IFACE.pid -lf /var/lib/dhcp/dhclient6.$IFACE.leases $IFACE
Похоже, Amazon обновила свое руководство по миграции, чтобы сказать нечто подобное (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html#ipv6-dhcpv6-ubuntu-14).
У меня была та же проблема, несмотря на то, что в таблице маршрутов был маршрут для :: / 0, который указывал на igw для VPC. Проблема заключалась в том, что набор правил брандмауэра блокировал пакеты ICMPv6 для протокола обнаружения соседей.
Вам обязательно нужно разрешить icmp6types 133,134,135,136,137