Дадайце прыватны IPv6 у лабараторыю OpenVPN, па адной кропцы праверкі за раз

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

Кропка праверкі першая: злучэнне, якое ўжо працуе

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

Запішыце пул, тапалогію і маршруты, што штурхаюцца, на якія вы ўжо абапіраецеся. Праца з IPv6 пашырае гэтую канфігурацыю; яна не замяняе яе.

Кропка праверкі другая: выберыце ўнутраныя прэфіксы

Выберыце ULA /48 для пляцоўкі і выражце з яго два /64: адзін для кліентаў тунеля, другі для сегмента LAN, дзе знаходзіцца нагрузка IPv6. Згенеруйце 40-бітны глабальны ID, а не капіруйце прэфікс з прыкладу, і праверце абедзве падсеткі супраць кожнай сеткі, якую пляцоўка ўжо маршрутызуе:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

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

Кропка праверкі трэцяя: дадайце памочнік і штурханне маршруту

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

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

Кропка праверкі чацвёртая: перасылка і маршрут адказу

Уключыце перасылку IPv6 на серверы праз уласнага ўладальніка канфігурацыі сістэмы, а не праз разавы запіс у час выканання, які вы забудзеце. Форма часу выканання карысная для хуткага тэсту. Пастаянная канфігурацыя належыць у drop-in-файл, які чытае ўладальнік сеткі дыстрыбутыва:

sysctl -w net.ipv6.conf.all.forwarding=1

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

Затым дайце LAN маршрут назад да пула тунеля. Шлюз IPv6 нагрузкі — гэта маршрутызатар LAN, а не сервер VPN, таму маршрут належыць на гэты маршрутызатар і паказвае на адрас сервера ў LAN:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

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

Кропка праверкі пятая: прачытайце кліента, потым тэстуйце

Перападключыце кліента і прачытайце адрасы, якія ён насамрэч атрымаў, а не выводзьце іх з адраса памочніка на серверы. Спіс інтэрфейсаў паказвае абодва сямействы на адной прыладзе:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Маршрут, які выбірае тунель, даказвае, што кліент ведае, куды слаць пакет. Ён не даказвае, што сервер яго перасылае, што маршрутызатар LAN мае зваротны маршрут або што праграме дазволена адказваць.

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

Публікуйце запіс AAAA толькі тады, калі шлях IPv6 адказвае ад канца да канца. DNS, запытаны праз IPv4, усё яшчэ можа вярнуць адрас IPv6, таму імя, якое развязаецца, не доказ таго, што нешта слухае. Кіраўніцтва RFC 4193 па ULA ахоплівае генерацыю глабальнага ID, які робіць гэтыя прэфіксы вашымі, а не копіяй.