IPv6 через VPN: Не вижу локальный адрес подключения на интерфейсе L2TP.

Привет, дело в том, что Mikrotik назначает link-local адрес для интерфейса L2TP только после установления соединения. Другими словами, только когда интерфейс находится в состоянии Running, он получает link-local адрес. Глобальный адрес, назначенный этому интерфейсу, становится недоступным, когда интерфейс отключен, но снова появляется после повторного подключения. Проблема, которую я наблюдаю, заключается в том, что Mikrotik использует довольно узкий пул при выборе link-local адреса для интерфейса, поэтому fe80::7/64 часто встречается на многих Mikrotik. Я не видел, чтобы роутер выбирал два одинаковых адреса для своих интерфейсов, но когда вы запускаете L2TP-хаб с включенным IPv6, это становится проблемой, поскольку RIPng, который я использую, сбивается с толку, если видит два идентичных link-local адреса (например, Client1 и Client3 имеют fe80::7/64 в качестве адреса link-local конечной точки L2TP) на разных интерфейсах.

janisk: Это все правда, когда ты пытаешься пропинговать LL-адрес или когда отображаешь основную таблицу маршрутизации, где ты можешь видеть маршруты RIPng, описанные парой ‘ll%interface’, но таблица маршрутизации RIPng (/routing ripng route print) имеет свои маршруты, где шлюзы описаны только значением LL. Похоже, проблем с 6to4 интерфейсами нет, но как только хаб, на котором включены L2TP, IPv6 и RIPng, начинает видеть два одинаковых LL-адреса (например, fe80::7/64 из моего предыдущего поста) на двух разных L2TP клиентских интерфейсах, подключенных из разных мест, он начинает менять записи полученного префикса/ов для дублирующихся LL-адресов, которые он находит. Рассмотри пример: 1 хаб, 4 клиента: Статические L2TP интерфейсы хаба: hub1: fe80::a/64 hub2: fe80::b/64 hub3: fe80::c/64 hub4: fe80::d/64 Интерфейсы клиентов: cl1: fe80::1/64, рекламирует 2001:1::/64 cl2: fe80::2/64, рекламирует 2001:2::/64 cl3: fe80::3/64, рекламирует 2001:3::/64 cl4: fe80::3/64, рекламирует 2001:4::/64 Обычно ты бы ожидал, что хаб будет видеть маршруты примерно так: 2001:1::/64 via fe80::1/64 2001:2::/64 via fe80::2/64 2001:3::/64 via fe80::3/64%hub3 2001:4::/64 via fe80::3/64%hub4 Но это не так. Первые две записи для клиента 1 и 3 будут работать нормально, но поскольку клиенты 2 и 4 имеют один и тот же LL-адрес (fe80::3/64), хаб будет менять изученный префикс для данного LL-адреса сразу после получения нового RIPng объявления. В итоге мы получим такую ситуацию: 2001:1::/64 via fe80::1/64 2001:2::/64 via fe80::2/64 2001:3::/64 via fe80::3/64%hub3 RIPng обновление происходит 2001:1::/64 via fe80::1/64 2001:2::/64 via fe80::2/64 2001:4::/64 via fe80::3/64%hub4 RIPng обновление происходит 2001:1::/64 via fe80::1/64 2001:2::/64 via fe80::2/64 2001:3::/64 via fe80::3/64%hub3 и так далее. Я думаю, это происходит именно потому, что RIPng не описывает полученные маршруты/префиксы информацией ‘LL%interface’, а берет только ‘LL’ часть. В настоящее время я использую такой IPv6/RIPng хаб всего с 12 клиентскими туннелями, и я уже видел такой случай как минимум 3 раза. Я думаю, решением проблемы было бы добавление части “%interface” к дескриптору шлюза маршрута, или если бы вы хотя бы увеличили пул случайности для L2TP интерфейсов, чтобы можно было реже сталкиваться с такими проблемами. Я могу открыть тикет в Support, если ты этого хочешь.