Падзел вашага /64 не маршрутызуе IPv6 да кліентаў VPN

Кліент паказвае глабальны адрас IPv6, рукапацісканне завяршылася, і з інтэрнэту нічога не вяртаецца. Налада пула выглядае правільнай, бо яна правільная; адрас сапраўдны, і тунель яго пераносіць. Не спрацоўвае дастаўка, а дастаўка залежыць ад рашэння, прынятага вышэй за сервер VPN, на якое ніякая кліенцкая канфігурацыя не можа паўплываць.

Міф: частка вашага /64 ужо дасягальная

Гісторыя прывабная: сервер мае публічны /64, падзяліце яго напалову, аддайце другую палову пулу VPN, і гэтыя кліенты ўжо ў інтэрнэце. Падзел прэфікса сапраўды выдзяляе адрасы без канфліктаў. Ён не змяняе тое, як сетка вышэй вырашае, куды павінен ісці пакет для аднаго з гэтых адрасоў.

У IPv6 няма прадвызначанага слоя перакладу, на які можна абаперціся, таму зваротны шлях павінен існаваць як маршрутызацыя або як дастаўка на ўзроўні звёна. Пакет, адрасаваны тунельнаму адрасу кліента, прыбывае на маршрутызатар вышэй, і гэты маршрутызатар прымае рашэнне аб перасылцы з уласнай табліцы. Калі табліца паказвае на фізічнае звяно, пакет ідзе туды, незалежна ад таго, што лічыць ваш сервер VPN.

Гэта ўся памылка: прамы кірунак працуе, бо яго адпраўляе ваш сервер, а зваротны кірунак памірае праз адзін хоп, бо сетка вышэй так і не даведалася, што кліент існуе.

Што насамрэч патрабуе дастаўка на звёне

Калі сетка вышэй лічыць увесь /64 знаходзячымся на фізічным звяне, яна вырашае кожны адрас прызначэння праз выяўленне суседзяў. Яна адпраўляе запыт на гэтае звяно і чакае, што ўладальнік адраса адкажа. Кліент VPN за тунелем не знаходзіцца на гэтым звяне і не можа адказаць, таму запыт застаецца без адказу, а пакет адкідаецца.

Выдзяленне /65 не змяняе гэтага чакання. Сетка вышэй па-ранейшаму разглядае дыяпазон як знаходзячыся на звёне, бо адзінае, што магло б змяніць яе думку, — гэта маршрут або проксі, які адказвае за кліента. Ні адно не з'яўляецца, бо вы адрэдагавалі канфігурацыю VPN. Менавіта гэтая прага тлумачыць, чаму пул можа бездакорна працаваць паміж сваімі кліентамі і ўсё роўна быць недасягальным з іншага месца.

Проксі-выяўленне суседзяў — гэта механізм, які можа злучыць два светы. Шлюз адказвае на запыты для канкрэтных кліенцкіх адрасоў, якімі ён валодае, і перасылае трафік у тунель. Гэта працуе, і гэта павінна быць абмежавана менавіта гэтымі адрасамі з жыццёвым цыклам, які ідзе за пулам, бо адказ за адрас, які вы больш не абслугоўваеце, ператварае чужы трафік у чорную дзірку. Некаторыя сеткі вышэй не прымаюць проксі-адказы, якіх не чакалі, таму гэтая канструкцыя патрабуе таксама згоды правайдэра.

Што патрабуе маршрутызаваная дастаўка

Больш чыстая канструкцыя — гэта размеркаванне, якое сетка вышэй сапраўды маршрутызуе на ваш шлюз. Гэта можа быць дэлегаваны прэфікс або статычны маршрут для меншага блока, і патрабаванне ў абодвух выпадках адно: табліца сеткі вышэй павінна паказваць на ваш сервер для дыяпазону кліентаў. Тады зваротны трафік прыбывае на шлюз, і шлюз перасылае яго ў тунель.

Маршрутызаваная дастаўка цалкам здымае пытанне выяўлення суседзяў, і менавіта таму варта папрасіць яе ў правайдэра, перш чым будаваць нешта хітрае. Папрасіце маршрут у пісьмовай форме і пацвердзіце, што наступны хоп — гэта адрас, да якога сетка вышэй сапраўды можа дабрацца.

Абедзве канструкцыі ўсё яшчэ патрабуюць уключанай перасылкі IPv6 на шлюзе і правілаў файрвола, якія дазваляюць перасланы паток у абодвух кірунках. Дастаўка — гэта перадумова, а не замена для астатняй часткі шляху. Працоўны маршрут з выключанай перасылкай дае роўна такую ж цішыню, як і адсутны маршрут, таму праверце абодва, перш чым нешта перапраектаваць.

Два незалежныя маршруты, якія трэба наладзіць

Прэфікс пула і ўласны маршрут кліента па змаўчанні — гэта асобныя налады, і іх блытаніна дае частковую злучнасць, якая выглядае як зламаны тунель. Пул паведамляе серверу, якія адрасы выдаваць. Маршруты кліента вызначаюць, на якія прызначэнні кліент наогул адпраўляе трафік у тунель.

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

Прэфікс вышэй — гэта прастора для дакументацыі, а перанакіраванне датычыцца толькі IPv6, што якраз і часта патрэбна двухстэкаваму разгортванню, пакуль дастаўка IPv6 яшчэ выпраўляецца. Перанакіраванне IPv4 не стварае пакрыцця IPv6, і ні адна налада не вынікае з другой.

Трымайце кіравальны трафік, ад якога залежыць IPv6, працоўным пры любой палітыцы, якую вы ўжываеце. Паведамленні Packet Too Big — класічная ахвяра файрвола, які дазваляе толькі TCP і UDP, і іх адкіданне стварае злучэнні, якія ўстанаўліваюцца і потым затыкаюцца на буйнейшых перадачах.

Аб'явы маршрутызатара — трэцяя рухомая частка. Калі шлюз пачынае аб'яўляць на вышэйшым звяне, ён можа змяніць тое, што кліенты і суседзі лічаць пра прэфіксы на звёне, а гэта можа ціха звесці на нішто канструкцыю, якую вы толькі што задокументавалі.

Запішыце канструкцыю, каб перабудова яе ўзнавіла

Запішыце тры аб'екты асобна: размеркаванне кліента, маршрут прызначэння кліента і метад дастаўкі размеркавання ў сетцы вышэй. Чытач, які мае ўсе тры, можа перабудаваць разгортванне; чытач, які мае толькі наладу пула, узнавіць зыходную памылку.

Затым праверце зваротны кірунак яўна, пакетам, які павінен вярнуцца звонку. Дапаможнік openvpn(8) апісвае параметры server-ipv6 і redirect, а пацверджанне маршрутызацыі ад вашага правайдэра пакрывае тую палову, якую дапаможнік не можа.