IPv6 през VPN: делегираният префикс не е пул от адреси

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

Стъпка първа: решете на коя роля служите

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

Отговорете на този въпрос, преди да отворите каквато и да е конфигурация. Всичко след тази стъпка зависи от отговора, който сте дали.

Стъпка втора: назначаване на адреси за един хост

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

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

Стъпка трета: делегиране за рутер зад тунела

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

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

Стъпка четвърта: направете обратния маршрут явен

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

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

Стъпка пета: проверка отзад на рутера

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

Направете последната проверка два пъти: веднъж от самия рутер и веднъж от устройство зад него. Рутер, който стига до дестинацията, докато клиентите му не могат, е проблем с делегирането или препращането, а не проблем по-горе по веригата.

Връщане назад

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

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