IPv6-выхад гіне пасля перазапуску OpenVPN: праверце, каму належыць прэфікс
IPv6 гіне пасля таго, як тунель ствараецца нанова. Вызначце, каму належыць дэлегаваны прэфікс, адрасы кліентаў і зваротны маршрут, перш чым нешта перазапускаць.
IPv6 перастае прапускаць трафік у той момант, калі OpenVPN перазапускаецца, а IPv4 працягвае працаваць. Інтэрфейс тунеля быў створаны нанова, і нешта іншае, што кіравала яго станам IPv6, страціла або адрас, або маршрут, які робіць прэфікс дасяжным. Задзейнічаны тры асобныя часткі стану, і кожная мае свайго ўладальніка: дэлегаваны прэфікс правайдэра і яго тэрмін дзеяння, адрасы, выдадзеныя кліентам VPN, і маршрут уверх, які вяртае гэты прэфікс кліента на сервер. Вызначце ўладальніка кожнай часткі, перш чым чапаць дэман, бо перазапуск не таго дэмана хавае праблему на дзень і вяртае яе пры наступным падключэнні.
Тры часткі стану IPv6, тры ўладальнікі
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Адраса з глабальнай вобласцю ўнутры тунеля самога па сабе недастаткова. Маршрутызатары ўверх павінны ўсё яшчэ адпраўляць гэты прэфікс назад да сервера VPN, і яны не зробяць гэтага толькі таму, што сервер выпадкова мае адрас з яго.
Вось чаму таксама рызыкоўна капіяваць публічны /64 у пул тунеля. Прэфікс, накіраваны на сервер, не тое ж самае, што прэфікс, які ўверх разглядае як on-link, і выяўленне суседзяў не закрые гэтую прагаліну.
Прачытайце стан сервера, перш чым нешта мяняць
Зафіксуйце стан двойчы: адзін раз, калі IPv6 працуе, і адзін раз пасля перазапуску, затым параўнайце. Праглядаў толькі для чытання дастаткова, і яны нічога не каштуюць падчас акна абслугоўвання:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingШукайце тры канкрэтныя адрозненні: маршрут, які знік, адрас, які перайшоў у састарэлы або несапраўдны тэрмін дзеяння, і прэфікс, які змяніўся пасля паўторнай дэлегацыі, тады як канфігурацыя VPN усё яшчэ абвяшчае стары.
Калі адрас знік, але прэфікс не змяніўся, дэман, які яго прызначае, спыніў кіраваць інтэрфейсам. Калі прэфікс змяніўся, але адрасы не, канфігурацыя кліента састарэла. Дзве гэтыя адмовы выглядаюць аднолькава з браўзера і не маюць нічога агульнага.
Вырашыце, ці павінен dhcpcd кіраваць тунелем
dhcpcd можа выяўляць інтэрфейсы і дэлегаваць часткі прэфікса DHCPv6 ніжнім інтэрфейсам, а яго канфігурацыя можа відавочна называць мэты дэлегацыі. Без відавочнай мэты яго дакументаваныя паводзіны могуць закранаць іншыя інтэрфейсы, і менавіта так тунель атрымлівае адрас, якога ніхто не планаваў.
Ёсць дзве ўмовы, якія павінны схіліць вас аддаць статычную адрасацыю тунеля OpenVPN: сервер штурхае фіксаваныя адрасы ў сваёй канфігурацыі, і імя тунеля змяняецца пры перападключэнні. Калі выконваюцца абедзве, наўмысна выключыце тунель з дэмана дэлегацыі, з каментарыем, які кажа чаму.
Калі ж дэлегацыя на тунель наўмысная, рэалізуйце апрацоўку змены прэфікса. Гэта значыць рэагаваць, калі дэлегаваны прэфікс або яго тэрмін дзеяння змяняецца, абнаўляць абвешчаны серверам прэфікс кліента і зноў дадаваць маршрут. Выключэнне інтэрфейса ў такім дызайне выдаляе адзіны кампанент, які ведае пра новы прэфікс.
Перазапуск dhcpcd можа выглядаць як выпраўленне, бо ён стварае стан нанова, але ён таксама абнаўляе або адклікае канфігурацыю для інтэрфейсаў, пра якія вы не думалі. Такое аднаўленне не робіць яго патрабаваннем пасля кожнага перазапуску VPN. Яно таксама скідвае лічыльнікі, якія вы выкарыстоўвалі як доказ. Аддайце перавагу мэтанакіраванай перазагрузцы таго інтэрфейса, які вы сапраўды змянілі.
Правярайце IPv6 асобна ад NAT для IPv4
Пераканайцеся, што перасылка ўключана і што маршрут уверх паказвае на фактычны прэфікс кліента, затым усталюйце новае дазволенае злучэнне IPv6. Праверце таксама ўласную табліцу маршрутаў IPv6 кліента, бо кліент з публічным адрасам не даказвае, што яго запыт ішоў праз тунель.
Маскіраванне IPv4 вырашае іншую праблему: зваротны шлях для прыватных крыніц. Яно нічога не робіць для адкліканага прэфікса IPv6, і яго даданне не верне IPv6.
Завяршыце запісам уладальнікаў: які кампанент дэлегуе прэфікс, які прызначае адрасы кліентаў, які трымае зваротны маршрут, і што адбываецца з кожным пры перападключэнні. Чатыры радкі ў ранбуку зберагаюць наступнаму чалавеку тры перазапускі дэманаў, каб знайсці той, што меў значэнне.