Разделянето на вашия /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, и изхвърлянето им създава връзки, които се установяват и след това забиват при по-големи трансфери.

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

Запишете дизайна, така че преустройството да го възпроизведе

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

След това тествайте обратната посока изрично, с пакет, който трябва да се върне отвън. Ръководството openvpn(8) покрива опциите server-ipv6 и redirect, а потвърждението за маршрутизация от вашия доставчик покрива половината, която ръководството не може.