IPv6 izeja mirst pēc OpenVPN restartēšanas: pārbaudiet prefiksa īpašumtiesības
IPv6 mirst pēc tam, kad tunelis tiek izveidots no jauna. Pirms kaut ko restartēt, izlemiet, kam pieder deleģētais prefikss, klientu adreses un atgriešanās maršruts.
IPv6 pārstāj laist cauri satiksmi tajā mirklī, kad OpenVPN restartējas, un IPv4 turpina darboties. Tuneļa saskarne tika izveidota no jauna, un kaut kas cits, kas pārvaldīja tās IPv6 stāvokli, pazaudēja vai nu adresi, vai maršrutu, kas padara prefiksu sasniedzamu. Ir iesaistītas trīs atsevišķas stāvokļa daļas, un katrai ir cits īpašnieks: pakalpojumu sniedzēja deleģētais prefikss un tā darbības laiks, VPN klientiem piešķirtās adreses un augšupējais maršruts, kas šo klienta prefiksu sūta atpakaļ serverim. Nosakiet katras daļas īpašnieku, pirms aiztiecat jebkuru dēmonu, jo nepareizā restartēšana paslēpj problēmu uz dienu un atgriež to nākamajā savienojumā.
Trīs IPv6 stāvokļa daļas, trīs īpašnieki
| 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 |
Globāla mēroga adrese tuneļa iekšienē pati par sevi nav pietiekama. Augšupējiem maršrutētājiem joprojām ir jāsūta prefikss atpakaļ uz VPN serveri, un viņi to nedarīs tikai tāpēc, ka serverim nejauši ir adrese no tā.
Tāpēc arī publiskas /64 kopēšana tuneļa baseinā ir riskanta. Uz serveri maršrutēts prefikss nav tas pats, ko augšupējā puse uzskata par on-link, un kaimiņu atklāšana šo plaisu neaizpildīs.
Izlasiet servera stāvokli, pirms kaut ko maināt
Ierakstiet stāvokli divas reizes, vienreiz kamēr IPv6 darbojas un vienreiz pēc restartēšanas, pēc tam salīdziniet. Ar tikai lasāmiem skatiem pietiek, un uzturēšanas loga laikā tie neko nemaksā:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingMeklējiet trīs konkrētas atšķirības: pazudušu maršrutu, adresi, kas pārgājusi uz novecojušu vai nederīgu darbības laiku, un prefiksu, kas mainījies pēc atkārtotas deleģēšanas, kamēr VPN konfigurācija joprojām reklamē veco.
Ja adrese pazuda, bet prefikss nav mainījies, to piešķirošais dēmons pārstāja pārvaldīt saskarni. Ja prefikss mainījās, bet adreses nē, klienta konfigurācija ir novecojusi. Abi bojājumi no pārlūka izskatās vienādi un tiem nav nekā kopīga.
Izlemiet, vai dhcpcd jāpārvalda tunelis
dhcpcd var atklāt saskarnes un deleģēt DHCPv6 prefiksa daļas lejupējām saskarnēm, un tā konfigurācija var tieši nosaukt deleģēšanas mērķus. Bez skaidra mērķa tā dokumentētā uzvedība var iesaistīt citas saskarnes, un tā tunelī nonāk adrese, ko neviens nebija plānojis.
Diviem nosacījumiem vajadzētu mudināt jūs ļaut OpenVPN pārvaldīt tuneļa statisko adresāciju: serveris savā konfigurācijā bīda fiksētas adreses, un tuneļa nosaukums mainās atkārtotas savienošanas laikā. Ja abi ir spēkā, apzināti izslēdziet tuneli no deleģēšanas dēmona, ar komentāru, kas pasaka kāpēc.
Ja deleģēšana uz tuneli tomēr ir apzināta, ieviesiet prefiksa maiņas apstrādi. Tas nozīmē reaģēt, kad deleģētais prefikss vai tā darbības laiks mainās, atjaunināt servera reklamēto klienta prefiksu un atkal pievienot maršrutu. Saskarnes izslēgšana šādā dizainā noņem vienīgo komponentu, kas zina par jauno prefiksu.
dhcpcd restartēšana var izskatīties kā lietu salabošana, jo tā no jauna izveido stāvokli, bet tā arī atjauno vai atsauc konfigurāciju saskarnēm, par kurām jūs nedomājāt. Šāda atjaunošana nepadara to par obligātu pēc katra VPN restartēšanas. Tā arī atiestata skaitītājus, ko izmantojāt kā pierādījumu. Dodiet priekšroku mērķētai tās saskarnes pārlādei, kuru jūs patiešām mainījāt.
Validējiet IPv6 atsevišķi no IPv4 NAT
Pārliecinieties, ka pārsūtīšana ir iespējota un augšupējais maršruts norāda uz faktisko klienta prefiksu, pēc tam izveidojiet jaunu atļautu IPv6 savienojumu. Pārbaudiet arī paša klienta IPv6 maršrutu tabulu, jo klients, kas rāda publisku adresi, nepierāda, ka tā pieprasījums izmantoja tuneli.
IPv4 maskēšana risina citu problēmu: atgriešanās ceļu privātiem avotiem. Tā neko nedara atsauktam IPv6 prefiksam, un tās pievienošana neatgriezīs IPv6.
Noslēdziet ar īpašumtiesību reģistru: kura komponente deleģē prefiksu, kura piešķir klientu adreses, kura tur atgriešanās maršrutu, un kas notiek ar katru atkārtotas savienošanas laikā. Četras rindas runbookā ietaupa nākamajam cilvēkam trīs dēmonu restartēšanu, lai atrastu to, kuram bija nozīme.