IPv6 кроз IPv4 VPN сервер и даље захтева прави IPv6 излаз

Тунел се подиже, клијент добија IPv6 адресу из pool-а, а ипак свако IPv6 одредиште истекне. У тунелу ништа није покварено: IPv6 се сасвим добро вози унутар IPv4 транспорта, и то никада није био тежак део. Адреса коју си доделио је обећање које сервер не може да испуни, јер излаз нема никакав IPv6 upstream у који би је послао. Поправка припада излазу, а не профилу клијента.

Симптом: адреса и никакав пут

Провера на страни клијента показује IPv6 адресу која изгледа глобално на тунелском уређају и руту која показује у њу, због чега се то погрешно чита као грешка клијента. Саобраћај улази у тунел, сервер га декапсулира, а затим пакет слеће на хост чија табела рутирања нема подразумевану руту IPv6 ни ка једном стварном месту. У зависности од стека добијаш тренутну недоступност или тихо одбацивање, и у оба случаја клијент види истек времена који изгледа исто као заштитни зид.

Прочитај сопствену табелу рутирања сервера пре него што дирнеш клијента, јер ту живи половина пута која недостаје. Сервер са једном подразумеваном рутом IPv4 већ ти је дао одговор.

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

Унутар тунела пакет је обичан IPv6, а његов извор је адреса клијента. Сервер скида транспортну инкапсулацију и затим држи нативни IPv6 пакет који мора да се проследи следећем IPv6 хопу. Подразумевана рута IPv4 не може да га носи, а превођење у IPv4 је друга функција коју нико није увео. То је цео квар и нема никакве везе са тим да ли је слушалац VPN одговорио преко IPv4.

Механика инкапсулације IPv6 преко IPv4 описана је у RFC 4213, а важан детаљ тамо је да крајње тачке и даље имају потребу за правом IPv6 повезаношћу са друге стране тунела. Омотавање заглавља не ствара upstream ни из чега.

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

Провери сваки слој одвојено, јер исправан спољашњи тунел крије покварен унутрашњи. Провери спољашњи пут IPv4 пингом од клијента до сервера и потврди порт који користиш. Затим провери унутрашњи пут на серверу, где ip -6 route треба да покаже подразумевану или конкретну руту научену од стварног upstream-а, и ip -6 addr треба да покаже префикс извора који upstream прихвата. Све мање од тога је украс на интерфејсу.

Јединствена локална адреса, или префикс који изгледа глобално и ка коме ништа не рутира назад, радо ће се појавити на интерфејсу и отићи никуда. Јавну доступност даје upstream, а не облик адресе.

Исто важи и на клијенту: ip -6 route get 2001:4860:4860::8888 треба да именује тунелски уређај, а ако именује физички, клијент уопште не користи VPN за IPv6.

Префикс извора, величина и ICMPv6

Питај upstream које префиксе извора ће прихватити за прослеђивање и употреби један од њих за pool клијената. Провајдер који ти да /64 за сопствени интерфејс сервера не рутира ти нужно други /64 или већи блок, а разлика је једно поподне отклањања грешака које тикет подршке решава једним питањем. Питај писмено и чувај одговор уз конфигурацију.

Предвиди резерву за додатну инкапсулацију коју твој стек стварно користи и одржавај ICMPv6 у раду, укључујући Packet Too Big. Друго заглавље смањује употребљиви корисни терет, па пут који одговара на мале ping-ове може ипак да падне на преносу датотеке, а заштитни зид који одбацује сав ICMPv6 претвара поправљив проблем са величином у црну рупу. Тестирај један велики пренос пре него што објавиш услугу.

Шта је сасвим други проблем

Долазак до апликације која ради само на IPv4 са клијента који ради само на IPv6 је превођење, а не тунелирање, и тражи нешто попут намерно распоређеног NAT64 решења. Одредиште неће разумети додатно тунелско заглавље само зато што си га додао. Историјске прелазне услуге заслужују исту пажњу: RFC 7526 је укинуо модел anycast релеја 6to4, па упутство написано око њега описује нешто што више нема одржаван јавни релеј.

Ако сервер нема употребљив IPv6 upstream, избори су подржан upstream, други излаз или документована одлука да IPv6 остане ван тунела. Неприхватљиво је рећи клијентима да IPv6 услуга постоји, док њихова обична IPv6 веза тихо заобилази VPN.