IPv6 през IPv4 VPN сървър все още изисква IPv6 изход

Тунелът се вдига, клиентът получава IPv6 адрес от пула, а всяка IPv6 дестинация все пак изтича по време. В тунела нищо не е счупено: IPv6 се вози напълно добре вътре в IPv4 транспорта и това никога не е било трудната част. Адресът, който си раздал, е обещание, което сървърът не може да изпълни, защото изходът няма IPv6 ъплинк, в който да го изпрати. Поправката е на изхода, а не в клиентския профил.

Симптомът: адрес без път

Проверка от страна на клиента показва глобално изглеждащ IPv6 адрес на тунелното устройство и маршрут, сочещ в него, поради което това се разчита погрешно като клиентска повреда. Трафикът влиза в тунела, сървърът го декапсулира и после пакетът се озовава на хост, чиято таблица за маршрутизация няма маршрут по подразбиране за IPv6 към никъде реално. В зависимост от стека получаваш незабавна недостъпност или тихо изпускане, а и в двата случая клиентът вижда таймаут, който изглежда идентичен на защитна стена.

Прочети собствената таблица за маршрутизация на сървъра, преди да пипаш клиента, защото липсващата половина от пътя живее точно там. Сървър с един маршрут по подразбиране за IPv4 вече ти е дал отговора.

Проследи пакета след декапсулацията

Вътре в тунела пакетът е обикновен IPv6 с адреса на клиента за източник. Сървърът сваля транспортната инкапсулация и после държи роден IPv6 пакет, който трябва да бъде препратен към следващ IPv6 възел. Маршрут по подразбиране за IPv4 не може да го носи, а превръщането му в IPv4 е друга функция, която никой не е внедрил. Това е целият провал и той няма нищо общо с това дали слушателят на VPN е отговорил през IPv4.

Механиката на инкапсулация IPv6 върху IPv4 е описана в RFC 4213 и важната подробност там е, че крайните точки все още се нуждаят от реална IPv6 свързаност от другата страна на тунела. Обвиването на заглавка не създава ъплинк от нищото.

Два тунелни слоя, две независими проверки

Провери всеки слой поотделно, защото работещ външен тунел скрива счупен вътрешен. Провери външния път с IPv4 ping от клиента към сървъра и потвърди порта, който използваш. После провери вътрешния път на сървъра, където ip -6 route трябва да покаже маршрут по подразбиране или конкретен маршрут, научен от реален ъплинк, а ip -6 addr трябва да покаже префикс на източника, който ъплинкът приема. Всичко по-малко е украса по интерфейса.

Уникално локален адрес или глобално изглеждащ префикс, към който нищо не маршрутизира обратно, ще се появи доволно на интерфейс и няма да отиде никъде. Публичната достъпност се дава от ъплинка, не от формата на адреса.

Същото важи и при клиента: ip -6 route get 2001:4860:4860::8888 трябва да посочи тунелното устройство, а ако посочва физическото, клиентът изобщо не използва VPN за IPv6.

Префикс на източника, размер и ICMPv6

Попитай ъплинка кои префикси на източника ще приеме за препращане и използвай един от тях за пула на клиентите. Доставчик, който ти дава /64 за собствения интерфейс на сървъра, не ти маршрутизира непременно втори /64 или по-голям блок и разликата е един следобед отладка, който тикет до поддръжката решава с един въпрос. Питай писмено и пази отговора при конфигурацията.

Предвиди запас за допълнителната инкапсулация, която стекът ти реално използва, и поддържай ICMPv6 работещ, включително Packet Too Big. Втора заглавка свива използваемия полезен товар, затова път, който отговаря на малки ping-ове, може все пак да се провали при прехвърляне на файл, а защитна стена, която изхвърля целия ICMPv6, превръща поправим проблем с размера в черна дупка. Тествай едно голямо прехвърляне, преди да обявиш услугата.

Кое е напълно различен проблем

Достигането до приложение само с IPv4 от клиент само с IPv6 е транслация, не тунелиране, и изисква нещо като умишлено внедрена NAT64 схема. Дестинацията няма да разбере допълнителна тунелна заглавка само защото си я добавил. Историческите преходни услуги заслужават същото внимание: RFC 7526 отмени модела на anycast реле 6to4, така че ръководство, написано около него, описва нещо, което вече няма поддържано публично реле.

Ако сървърът няма използваем IPv6 ъплинк, изборите са поддържан ъплинк, различен изход или документирано решение IPv6 да остане извън тунела. Неприемливо е да казваш на клиентите, че има IPv6 услуга, докато обикновената им IPv6 връзка тихо заобикаля VPN.