IPv6 преку IPv4 VPN сервер сѐ уште бара вистински IPv6 излез

Тунелот се крева, клиентот добива IPv6 адреса од базенот, и сепак секоја IPv6 дестинација истекува. Во тунелот ништо не е расипано: IPv6 се вози совршено добро во IPv4 транспортот, и тоа никогаш не беше тешкиот дел. Адресата што ја издаде е ветување што серверот не може да го исполни, бидејќи излезот нема IPv6 upstream каде да ја прати. Поправката припаѓа на излезот, а не на профилот на клиентот.

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

Проверката на клиентската страна покажува IPv6 адреса што изгледа глобална на тунелскиот уред и маршрута што покажува во неа, поради што ова погрешно се чита како дефект на клиентот. Сообраќајот влегува во тунелот, серверот го декапсулира, и потоа пакетот слетува на домаќин чија табела за рутирање нема стандардна маршрута IPv6 кон ниедно вистинско место. Во зависност од стекот добиваш моментална недостапност или тивко отфрлање, и во двата случаи клиентот гледа истек на време што изгледа исто како ѕид на огнот.

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

Следи го пакетот по декапсулацијата

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

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

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

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

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

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

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

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

Предвиди буџет за дополнителната инкапсулација што твојот стек навистина ја користи, и одржувај го ICMPv6 во работа, вклучително Packet Too Big. Второто заглавие ја намалува употребливата носивост, па пат што одговара на мали ping може сепак да не успее при пренос на датотека, а ѕидот на огнот што фрла целиот ICMPv6 претвора поправлив проблем со големина во црна дупка. Пред да ја објавиш услугата, тестирај еден голем пренос.

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

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

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