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 одделно од IPv4 NAT
Потврдете дека препраќањето е вклучено и дека горната рута покажува кон вистинскиот клиентски префикс, потоа направете ново дозволено IPv6 поврзување. Проверете ја и сопствената IPv6 рутна табела на клиентот, бидејќи клиент што прикажува јавна адреса не докажува дека неговото барање го користело тунелот.
IPv4 маскирањето решава друг проблем: повратниот пат за приватни извори. Тоа не прави ништо за повлечен IPv6 префикс, и неговото додавање нема да го врати IPv6.
Завршете со записот за сопственост: која компонента го делегира префиксот, која доделува клиентски адреси, која ја држи повратната рута и што се случува со секоја при повторно поврзување. Четири реда во runbook му заштедуваат на следниот човек рестартирање на три демони за да го најде оној што бил важен.