IPv6-прэфікс філіяла: iroute-ipv6 ці route-ipv6 на серверы?

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

Дзве дырэктывы, дзве розныя задачы

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

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

У традыцыйнай userspace-схеме патрэбныя абедзве, і яны дапаўняюць адна адну. Адзін маршрут ядра пакідае дэман без магчымасці выбраць peer. Адзін iroute пакідае ядро без шляху да тунеля. Адсюль жа і большая частка блытаніны з файламі для асобных кліентаў: файл — не запіс табліцы маршрутаў, а запіс маршруту — не заява пра прыналежнасць.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Дзе месца кожнай

Маршрут ідзе ў кіраваную канфігурацыю сервера, дзе ён дзейнічае для гэтага працэсу. iroute ідзе ў файл, спецыфічны для кліента, названы па праверанай асобе прылады філіяла.

Імя файла, якое не супадае з фактычнай асобай, ніколі не чытаецца, і сімптом супадае з адсутным iroute. Праверце асобу, якую пацвердзіў сервер, а потым праверце імя файла сімвал за сімвалам.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Трымайце пул і прэфікс філіяла асобна, бо іх перакрыццё стварае загадку, якую не развяжа ніводная дырэктыва.

Што патрэбна іншаму кліенту

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

Не адпраўляйце яго самому філіялу, бо ў гэтай прылады прэфікс ужо ёсць як падключаная сетка.

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

Зваротны шлях на прыладзе філіяла

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

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

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

Калі пары ўсё яшчэ не хапае

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

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

І на апошак памятайце пра вобласць адрасоў: унікальны лакальны прэфікс накшталт fd00:7a::/64 ёсць прыватным паводле задумы і нічога не кажа пра публічную дасяжнасць IPv6. Лічыце яго ўнутраным доступам, а выхад у інтэрнэт трымайце асобным пытаннем з уласнай палітыкай.