Поделбата на вашиот /64 не насочува IPv6 кон VPN клиентите

Клиентот прикажува глобална IPv6 адреса, ракувањето е завршено, а ништо не се враќа од интернет. Поставката за групата изгледа точна затоа што е точна; адресата е валидна и тунелот ја пренесува. Она што не успева е доставата, а доставата зависи од одлука донесена над VPN серверот на која ниту една конфигурација од страна на клиентот не може да влијае.

Митот: дел од вашиот /64 е веќе достапен

Приказната е привлечна: серверот има јавна /64, пресечете ја на половина, дајте ја другата половина на VPN групата, и тие клиенти се сега на интернет. Поделбата на префиксот навистина доделува адреси без судири. Но не го менува тоа како upstream мрежата одлучува каде треба да оди пакетот за една од тие адреси.

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

Тоа е целата грешка: насоката напред работи затоа што вашиот сервер ја испраќа, а повратната насока умира еден хоп подалеку затоа што upstream никогаш не дознал дека клиентот постои.

Што навистина бара доставата на врската

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

Отсекувањето на /65 не го менува тоа очекување. Upstream сепак го третира опсегот како на врската, затоа што единственото нешто што би го предомислило е рута или прокси што одговара во име на клиентот. Ниту едно не се појавува затоа што уредувавте VPN конфигурација. Токму таа празнина објаснува зошто групата може совршено да работи меѓу сопствените клиенти и сепак да биде недостапна од кое било друго место.

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

Што бара насочената достава

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

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

Двата дизајна сепак бараат овозможено проследување на IPv6 на портата и правила на огнениот ѕид што го дозволуваат проследениот тек во двете насоки. Доставата е предуслов, не замена, за остатокот од патот. Работна рута со исклучено проследување создава точно иста тишина како рута што недостасува, затоа проверете ги двете пред да преработите нешто.

Две независни рути што треба да се наместат правилно

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Префиксот погоре е простор за документација, а пренасочувањето се однесува само на IPv6, што е токму она што двојното поставување често го сака додека доставата на IPv6 се уште се поправа. Пренасочувањето на IPv4 не воспоставува покриеност со IPv6, и ниту една поставка не ја подразбира другата.

Одржувајте го контролниот сообраќај од кој зависи IPv6 во функција под која било политика што ја применувате. Пораките Packet Too Big се класична жртва на огнен ѕид што дозволува само TCP и UDP, а нивното отфрлање создава врски што се воспоставуваат и потоа застануваат при поголеми преноси.

Огласите на рутерот се третиот подвижен дел. Ако портата почне да огласува на горната врска, тоа може да го промени она што клиентите и соседите го мислат за префиксите на врската, што може тивко да го поништи дизајнот што штотуку го документиравте.

Запишете го дизајнот за да го репродуцира повторната изградба

Запишете три објекти одделно: распределбата на клиентот, целната рута на клиентот и методот на достава на распределбата од upstream. Читател што ги има сите три може да го изгради повторно распоредувањето; читател што ја има само поставката за групата ќе ја репродуцира првобитната грешка.

Потоа јасно тестирајте ја повратната насока, со пакет што мора да се врати однадвор. Прирачникот openvpn(8) ги покрива опциите server-ipv6 и redirect, а потврдата за маршрутирање од вашиот давател го покрива половиот дел што прирачникот не може.