IPv6 праз тунель OpenVPN: пакрокавы разбор для хатняга роўтара

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

Пачніце з кліента

Паглядзіце на кліент, перш чым чапаць сервер. ip -6 addr павінен паказваць адрас тунеля з пула, а ip -6 route — праштурханы прэфікс, які паказвае на тунельнае прыстасаванне. Калі адрас ёсць, а маршруту няма, праштурхоўванне адсутнічае або кліент яго праігнараваў. Калі няма ні таго, ні другога, сервер наогул нічога не прызначыў.

Затым праверце, што кліент думае пра знешні свет. Маршрут па змаўчанні праз тунель захоплівае ўвесь трафік IPv6, а маршрут для 2000::/3 — толькі глабальны unicast. Абодва могуць быць правільнымі, і яны адказваюць на розныя пытанні пра ўцечку.

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

Праверце пул, які сервер сапраўды можа маршрутызаваць

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

Пул і праштурхоўванне ідуць разам. server-ipv6 2001:db8:80:10::/64 прызначае адрасы, а push "route-ipv6 2000::/3" кажа кліентам, што адпраўляць у тунель. Праштурхоўванне 2000::/3 ахоплівае глабальны unicast, пакідаючы link-local і multicast дыяпазоны па-за тунелем.

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

Уключыце перасыланне для другой сям'і

Перасыланне IPv4 не азначае перасылання IPv6. Усталюйце net.ipv6.conf.all.forwarding=1 і паўтарыце ўсё, што ўжо дазваляе палітыка FORWARD для IPv4. На роўтары, чыі ланцужок FORWARD па змаўчанні скідае пакеты, адсутны набор правілаў выглядае гэтак жа, як мёртвы тунель.

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

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

Адказвайце на выяўленне суседзяў, калі верхні бок не маршрутызуе

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

OpenVPN падстаўляе прызначаны адрас апрацоўніку client-connect, таму запісы могуць ісці за сапраўдным пулам, а не за спісам, які вядуць уручную. Апрацоўнік дадае ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, а адпаведны апрацоўнік client-disconnect выдаляе яго. Без выдалення табліца проксі састарэе, і пазнейшы кліент можа атрымаць у спадчыну запіс для адраса, які ён ніколі не атрымліваў. Праверце стан праз ip -6 neigh show proxy.

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

Ідзіце шляхам вонкі, па адным хопе

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

Сачыце за MTU тунеля, бо роўтары IPv6 на шляху не будуць фрагментаваць за вас. Занадта вялікі MTU праяўляецца як памылка packet-too-big і застой TLS, а не як чысты збой. Задайце яго яўна і праверце з карыснай нагрузкай каля мяжы.