chore(test): подтвердить IPv6 в GRE и WireGuard

This commit is contained in:
Denozordec committed 2026-10-10 09:06:40 +07:00
1 parent 2a804876b0
commit 1d61b50591
7 files changed
+1843 -12

No files matched your search

+11 -1
View File
@@ -1,6 +1,6 @@
# UX/UI: протокол внешней приёмки 12.5
Актуальное продолжение 2026-10-10: завершены12.5.107–108 — VXLAN bridge/FDB и IPv6 ULA inner по IPv4 outer, отключение/восстановление собственного bridge-порта. Steady/recovery Ping10/10 в обе стороны; initial IPv6 loss сохранён, бесшовность не заявлена. Cleanup13 коллекций×2, настройкиIPv6 и own dynamic tables passed. Runtime ux-patch102/ux-a11y101 прежний. Следующий109 — IPv6 inner GRE/WireGuard; Portal/Telegram ожидают настройки и отдельного разрешения на сообщение.12.5 открыт.
Актуальное продолжение 2026-10-10: завершены12.5.107–109 — VXLAN bridge/FDB и IPv6 ULA inner в VXLAN/GRE/WireGuard по IPv4 outer. Steady/recovery Ping10/10 в обе стороны каждого типа; initial loss сохранён. Cleanup собственных объектов/baseline passed, обаCHR доступны. Runtime ux-patch102/ux-a11y101 прежний. Native IPv6 не означает поддержку IPv6 interface address в API/history/export GRE/WG. Следующий110 — профильная приёмка IPsec со сложным DN; Portal/Telegram ожидают настройки/разрешения.12.5 открыт.
IPsec78: реальный PSK responder established, mode-config198.18.78.10 и online=true подтверждены API; точные собственные объекты удалены. Сертификатный/DN online, late failure и history restore остаются открытыми. [Отчёт](ux-ui/acceptance/ipsec-mode-config-2026-10-09.json), [журнал](ux-ui-progress.md).
@@ -1048,3 +1048,13 @@ Initial Ping3/3 и steady Ping10/10 в обе стороны; сохранены
Initial IPv6 Ping дал0/3 и1/3; packet rows сохранены, причина потерь не установлена. После3s паузы steady Ping10/10 в обе стороны. Native адреса valid/advertise=false, bridge host и VXLAN FDB изучили MAC противоположного моста с правильным remote VTEP. Каталог приложения показывает правильные интерфейсы/VNI/port/learning/remoteVteps без failures. После отключения собственного bridge-порта CHR1 Ping0/3 в обе стороны, интерфейсы остаются UP; после включения и2s паузы Ping10/10 и FDB подтверждены. Initial loss не скрыт повтором и не заменён утверждением о zero-loss startup/SLA.
Exact-ID/marker cleanup вернул baseline projection13 коллекций×2, собственные bridge hosts/FDB отсутствуют; disable-ipv6/forward/accept-router-advertisements совпали с исходными. Пароли прежние, оба устройства доступны. Исходники/DB/runtime не менялись, build/общая UI регрессия не повторялись. Результат подтверждает native IPv6 inner в данной паре; не добавляет IPv6 IP/bridge/FDB в fragment экспорт, не доказывает SLAAC, клиентские ОС, масштаб, IPv6 outer или максимальную скорость. Следующий109 — GRE/WireGuard IPv6 inner по существующему IPv4 outer.
## 12.5.109 — GRE/WireGuard: IPv6 inner и раздельное восстановление (2026-10-10)
[Native отчёт](ux-ui/acceptance/gre-wireguard-ipv6-inner-2026-10-10.json). На обоих CHR создана отдельная GRE пара MTU1400 и WireGuard пара UDP59909/MTU1420. IPv6 ULA fd00:109:1::1/64↔::2/64 на GRE и fd00:109:2::1/64↔::2/64 на WG; advertise=no. GRE outer и WG endpoints остаются исходными публичными IPv4. Ключи сгенерировал RouterOS на собственных WG-интерфейсах; private keys не сохранялись в отчёт/репозиторий. Peer allowed-address ограничен удалённым собственным IPv6 /128, keepalive5s. До записей collision/baseline/IPv6 preflight завершён на обоих устройствах; ether1/глобальные настройки/ND/firewall/routes не изменялись вручную.
Initial результаты: gre/CHR1=0/3, gre/CHR2=1/3, wireguard/CHR1=3/3, wireguard/CHR2=3/3. Все реальные packet rows сохранены. После3s паузы steady IPv6 Ping10/10 в обе стороны каждого типа, valid native адреса и WG handshake/rx/tx>0 подтверждены. Последовательно отключены только собственный GRE интерфейс CHR1 и собственный WG peer CHR1: соответствующий Ping0/3 в обе стороны, второй туннель в каждой фазе продолжает передавать3/3. После включения и3s паузы recovery Ping10/10 в обе стороны каждого типа. Измерение переходного loss/SLA/максимальной скорости не выполнялось.
Production aggregate GET /api/gre/tunnels и /api/wireguard вернули собственные интерфейсы без failures; WG allowedIps сохранил native IPv6 /128, privateKey не возвращён. Ограничение обнаружено и зафиксировано: CHR1: GRE localInnerIp="", WG address=null; CHR2: GRE localInnerIp="", WG address=null. Текущие GRE/WG readers получают interface addresses из /ip/address, поэтому native IPv6 адрес не попадает в это поле. Эти проверки не принимают IPv6 создание/restore/history/export через приложение и не расширяют его API. Поддержка полного IPv6 управления требует отдельной согласованной модели адресов и миграции snapshots.
Перед очисткой exact IDs/markers и immutable reference fields сверены; собственные peers/IPv6 addresses/interfaces удалены. Baseline projection13 коллекций×2 и7 исходных параметров IPv6 settings совпали. Пароли прежние, оба CHR доступны. DB/runtime/исходники продукта не менялись, повтор build/общей UI регрессии не требовался. Открыты IPv6 outer/client OS/scale, application IPv6 address lifecycle и остальные пункты матрицы. Следующий110 — IPsec complex/escaped DN с собственной сертификатной парой и контролем online identity; внешние Portal/Telegram требуют настоящей настройки.