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 спестяват на следващия човек рестартирането на три демона, за да открие онзи, който е имал значение.