Подела вашег /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, а потврда рутирања од вашег добављача покрива ону половину коју приручник не може.