IPv6 DS Lite

Как только у вас появится работающая IPv6-подключение, вы сможете использовать IPIPv6-туннель для соединения с AFTR, а так как провайдер предоставляет DNS-имя вроде:  
/interface ipipv6 add name=dslite1 remote-address=aftr.prod.m-online.net  
/ip address add address=192.0.0.2/29 interface=dslite1  
/ip route add gateway=192.0.0.1  

Согласно спецификациям, NAT применять не нужно, а для лучшей защиты желательно настроить соответствующие правила файрвола.

Я не знаю готового примера для копирования и вставки. Также есть различные известные проблемы с IPv6 Router Advertisements и DHCPv6 Prefix Discovery через PPPoE-соединения в RouterOS v7, которые, надеюсь, исправлены в недавно выпущенной версии v7.2. Для IPv6 это должно выглядеть примерно так, как в примере для RouterOS v6: отключить или удалить IPv4 DHCP-клиент на ether1, принимающий router advertisements.

/ipv6 settings set accept-router-advertisements=yes

Добавить VLAN-интерфейс на WAN-порт:

/interface vlan add interface=ether1 name=vlan40-ether1 vlan-id=40

Добавить PPPoE-клиент на VLAN-интерфейс:

/interface pppoe-client add add-default-route=yes allow=chap disabled=no interface=vlan40-ether1 name=pppoe-out1 password=XXXXXXXX use-peer-dns=yes user=XXXXXXXX

Добавить PPPoE-клиент в список WAN-интерфейсов:

/interface list member add interface=pppoe-out1 list=WAN

Добавить DHCPv6-клиент к PPPoE-интерфейсу, запрашивая только префикс, без добавления default gateway, обычно с rapid commit:

/ipv6 dhcp-client add add-default-route=no interface=pppoe-out1 pool-name=pool-pd request=prefix use-peer-dns=yes

Добавить IPv6-адрес из DHCPv6 пула на локальную LAN:

/ipv6 address add address=::1 from-pool=pool-pd interface=bridge

Это должно дать IPv6-соединение, вы сможете успешно пропинговать адрес, например 2a00:1450:4009:818::2003, как с Mikrotik, так и с клиента в LAN. Потом добавьте настройку IPIPv6 туннеля и отключите правило IPv4 NAT, возможно, придется немного подкорректировать правила firewall.

Команда :put выводит данные в консоль, но можно использовать :log вместо нее. Ты запрашиваешь эту опцию? Согласно спецификациям, серверы не должны отправлять OPTION_AFTR_NAME, если это явно не запрошено, поэтому /ipv6 dhcp-client option add code=6 name=OPTION_ORO value=0x0040.

Документация довольно скудная и неясно, комбинируются ли другие опции запроса от клиента, например DNS-серверы, или они перезаписываются, так что возможно придется захватить пакеты, чтобы проверить. Также непонятно, будет ли Mikrotik переводить ответ, который использует форматирование DNS-меток — строка FQDN aftr.example.com возвращается в виде последовательности байтов/символов <0x04> a f t r <0x07> e x a m p l e <0x03> c o m <0x00>.

Похоже, что по какой-то причине туннель IPIPv6 не поднимается — по крайней мере, я могу пропинговать только IP-адрес роутера на этом конце туннеля, а вот «другую сторону» — нет. Как я уже говорил выше: никаких признаков подключения (или попыток подключения) интерфейса туннеля не видно. Зато я могу пинговать AFTR по IPv6, значит он работает. Есть идеи, как это отладить? Заранее спасибо!

ПОПРАВКА: к сведению, туннель, который я настроил, не показывает, что он недействителен, не запущен, не подчинен и не является проходным — то есть толком никакой полезной информации.

Ладно, теперь всё работает. Особая благодарность tdw! В чём решение? На этот раз помогло просто убрать конфигурацию keepalive. ROS всё равно через секунду подставил значения по умолчанию, но сразу после этого я увидел статус «running». Отлично! Следующий шаг — настройка маршрутизации. Тут я немного заблудился, думая, что туннель состоит из двух нумерованных концов и что нужно использовать удалённый конец как шлюз. Но оказалось, это не обязательно. Всё, что нужно — назначить произвольный IPv4-адрес и настроить его как шлюз по умолчанию для 0.0.0.0/0. Вуаля! То есть что-то вроде:

/interface ipipv6 add name=dslite1 remote-address=aftr.prod.m-online.net !keepalive  
/ip address add address=192.0.0.2/29 interface=dslite1  
/ip route add dst-address=0.0.0.0/0 gateway=192.0.0.1

Да, пока что я избегал возни с настройкой имени AFTR при каждом новом подключении, так как оно, кажется, статичное, и зачем усложнять. В любом случае, после двух дней работы я заметил, что производительность на IPv4 немного нестабильна, и задумываюсь, связано ли это с CGN (AFTR), который использует мой провайдер, или с чем-то другим. Если быть точнее, до перехода на DS Lite я практически полностью нагружал свой гигабитный канал до ONT. Сейчас же скорость достигает примерно 750 Мбит/с, что кажется немного низким показателем. По обратному каналу я получаю обещанные 300 Мбит/с, поэтому интересно, не является ли узким местом здесь что-то моё (RB5009) или CGN провайдера. Помимо обсуждения с провайдером, хотел бы услышать и ваше мнение. Заранее спасибо!

Загрузка процессора кажется около 5 %, даже когда я гоню линию на полную при тесте скорости, так что, скорее всего, проблема не в этом. PPPoE MTU настроен автоматически на 1492, а MTU туннеля ipipv6 — на 1452, что мне кажется нормальным. Однако спустя несколько дней использования этой конфигурации обнаружилось, что не только максимальная скорость стала ниже, но и несколько сайтов либо вообще не грузятся, либо загружаются очень долго (с множеством попыток). Кажется, раньше такое бывало при слишком большом MTU, но даже при уменьшении MTU туннеля до 1300 ничего не изменилось. Я уже поднял этот вопрос у своего провайдера, но хотел бы сначала собрать мнения здесь, чтобы лучше подготовиться. К тому же, технические знания провайдера явно поверхностные. По моим ощущениям, Huawei настроили у них всё, а теперь эти ребята просто вынуждены работать с системой, не имея ни должных знаний, ни опыта в таком деле. В общем, я подозреваю, что CGN просто неправильно настроен или перегружен, но так как у меня ноль опыта с такой конфигурацией, хочу убедиться, что не упускаю чего-то очевидного.

Страницы не загружаются или грузятся очень долго — это может указывать на проблемы с MTU, обработкой фрагментов или обнаружением PMTU. По умолчанию стоит clamp-tcp-mss=yes на туннельном интерфейсе, что должно это исправить, а значит, проблема скорее всего у них на шлюзе. Можно попробовать установить dont-fragment=yes — тогда пакеты с избыточным размером будут отбрасываться, что может помочь с обнаружением PMTU. Ещё можно попробовать явно прописать правила в файрволе, чтобы либо проверить TCP MSS, либо принудительно установить его в 1412 [1500 - 8 (PPPoE) - 40 (IPv6 заголовок) - 20 (IPv4 заголовок) - 20 (TCP заголовок)].