Namamatay ang IPv6 egress pagkatapos i-restart ang OpenVPN: suriin kung kanino ang prefix
Namamatay ang IPv6 pagkatapos muling gawin ang tunnel. Magpasya kung kanino ang delegadong prefix, ang mga address ng kliyente at ang return route bago i-restart ang anuman.
Humihinto ang IPv6 sa pagpasa ng trapiko sa sandaling OpenVPN ay mag-restart, at patuloy na gumagana ang IPv4. Ang interface ng tunnel ay muling ginawa, at may iba pang bagay na namamahala sa IPv6 state nito ay nawala ang address o nawala ang ruta na nagpapabisa sa prefix. May tatlong hiwalay na piraso ng state na sangkot, at bawat isa ay may ibang may-ari: ang delegadong prefix ng provider at ang buhay nito, ang mga address na ibinibigay sa mga kliyente ng VPN, at ang upstream route na nagpapabalik sa prefix ng kliyente sa server. Tukuyin ang may-ari ng bawat piraso bago hawakan ang anumang daemon, dahil ang pag-restart ng mali ay nagtatago ng problema nang isang araw at ibinabalik ito sa susunod na koneksyon.
Tatlong piraso ng IPv6 state, tatlong may-ari
| 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 |
Hindi sapat ang address na may global scope sa loob ng tunnel. Kailangan pa ring ipadala ng mga router sa itaas ang prefix na iyon pabalik sa VPN server, at hindi nila ito gagawin dahil lang may address ang server mula rito nang nagkataon.
Kaya rin mapanganib ang pagkopya ng pampublikong /64 sa isang tunnel pool. Ang prefix na niruruta sa server ay hindi katulad ng prefix na itinuturing na on-link ng itaas na bahagi, at hindi pupunan ng neighbor discovery ang puwang na iyon.
Basahin ang state ng server bago magbago ng anuman
Kunin ang state nang dalawang beses, isang beses habang gumagana ang IPv6 at isang beses pagkatapos ng restart, at pagkatapos ay ihambing. Sapat na ang mga read-only na view, at wala silang gastos sa loob ng maintenance window:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingMaghanap ng tatlong partikular na pagkakaiba: isang rutang nawala, isang address na lumipat sa lipas o di-wastong buhay, at isang prefix na nagbago pagkatapos ng redelegation habang inaanunsyo pa rin ng VPN configuration ang luma.
Kung nawala ang address pero hindi nagbago ang prefix, huminto sa pamamahala ng interface ang daemon na nagtatalaga nito. Kung nagbago ang prefix pero hindi ang mga address, luma na ang configuration ng kliyente. Magkapareho ang itsura ng dalawang pagkabigo mula sa browser at wala silang anumang pagkakatulad.
Magpasya kung dapat pangasiwaan ng dhcpcd ang tunnel
Kayang tumuklas ng mga interface ang dhcpcd at magdelegate ng bahagi ng DHCPv6 prefix sa mga downstream interface, at kayang pangalanan nang tahasan ng configuration nito ang mga target ng delegation. Nang walang tahasang target, maaaring isangkot ng dokumentadong pag-uugali nito ang iba pang interface, at ganoon napupunta ang tunnel sa isang address na walang nagplano.
Dalawang kondisyon ang dapat magtulak sa iyo na ipaubaya sa OpenVPN ang static addressing ng tunnel: itinutulak ng server ang mga fixed address sa configuration nito, at nagbabago ang pangalan ng tunnel sa muling pagkonekta. Kung pareho itong totoo, sadyang ibukod ang tunnel mula sa delegation daemon, kasama ang komentong nagsasabi kung bakit.
Kung sa halip ay sinasadya ang delegation sa tunnel, ipatupad ang paghawak sa pagbabago ng prefix. Ibig sabihin, tumugon kapag nagbago ang delegadong prefix o ang buhay nito, i-update ang inaanunsyong client prefix ng server, at idagdag muli ang ruta. Ang pagbubukod sa interface sa ganoong disenyo ay nag-aalis ng nag-iisang component na nakakaalam ng bagong prefix.
Maaaring mukhang inaayos ng pag-restart ng dhcpcd ang mga bagay dahil muling ginagawa nito ang state, pero nagre-renew o nagwi-withdraw din ito ng configuration para sa mga interface na hindi mo inisip. Hindi ginagawang kinakailangan ng pagbawi na iyon ang pag-restart pagkatapos ng bawat restart ng VPN. Nire-reset din nito ang mga counter na ginagamit mong ebidensya. Mas mainam ang target na muling pag-load ng interface na aktwal mong binago.
I-validate ang IPv6 nang hiwalay sa IPv4 NAT
Kumpirmahin na naka-enable ang forwarding at ang upstream route ay tumuturo sa aktwal na client prefix, pagkatapos ay gumawa ng bagong pinapayagang IPv6 koneksyon. Suriin din ang sariling IPv6 route table ng kliyente, dahil ang kliyenteng nagpapakita ng pampublikong address ay hindi nagpapatunay na ginamit ng request nito ang tunnel.
Ang IPv4 masquerading ay lumulutas ng ibang problema: ang return path para sa mga pribadong source. Wala itong ginagawa para sa binawing IPv6 prefix, at hindi ibabalik ng pagdaragdag nito ang IPv6.
Tapusin sa talaan ng pagmamay-ari: aling component ang nagde-delegate ng prefix, alin ang nagtatalaga ng mga address ng kliyente, alin ang may hawak ng return route, at ano ang nangyayari sa bawat isa sa muling pagkonekta. Apat na linya sa isang runbook ang nagliligtas sa susunod na tao mula sa pag-restart ng tatlong daemon para hanapin ang mahalaga.