Чаму выяўленне суседзяў IPv6 не працуе праз маршрутызаваны VPN

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

Вобласць дзеяння ідзе перад канфігурацыяй

Запыт і аб’ява суседа маюць ліміт пераходаў 255 і не перасылаюцца, па задуме. Маршрутызатар паміж вашым тунелем і аддаленай LAN перасылае пакеты IPv6 і не перадае паведамленні суседзяў за яго. Такім чынам, кэш суседзяў на інтэрфейсе тунеля змяшчае партнёра і мала што яшчэ, і гэта правільныя паводзіны, а не дэфект, які трэба выпраўляць.

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

Пастка — гэта дапушчэнне, што прэфікс у канале

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

/128 для адной паслугі — найменш нечаканае рашэнне, і яно цалкам здымае неадназначнасць. Спецыфікацыя выяўлення суседзяў апісвае набор паведамленняў і сцяг «у канале», які гэта вызначае.

Маставанне наўмысна змяняе правілы

Калі тунель перадае кадры Ethernet, аддалены і лакальны сегменты становяцца адным каналам, шматвяшчанне дасягае абодвух бакоў, і выяўленне суседзяў паводзіць сябе як на камутатары. Наступствы прыходзяць разам з ім: шырокавяшчальны і шматвяшчальны шторм, выяўленне дублікатаў адрасоў праз мост і аб’явы маршрутызатара, якія працякаюць у сегмент, што не павінен іх бачыць. Домен адмоваў цяпер таксама ахоплівае дзве пляцоўкі. Нішто з гэтага не аргумент супраць маставання, і кожны пункт — прычына рабіць мост наўмысна, а не выпадкова.

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

Тэстуйце з адрасам, які выкарыстоўвае праграма

Пацвердзіце маршрут праз ip -6 route get, праверце запіс суседа праз ip -6 neigh, затым пацвердзіце паслугу на маршрутызаваным шляху. DNS і зваротны шлях — асобныя праверкі, і здаровы запіс суседа не даказвае ні адной з іх.

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

Запішыце, які праект у вас ёсць

Зафіксуйце маршрутызаваны ці маставы варыянт да інцыдэнту, бо два разгортванні адказваюць на гэтыя пытанні па-рознаму, і чарговы інжынер не павінен здагадвацца пра гэта па профілі.

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