Az IPv6 kimenet meghal egy OpenVPN-újraindítás után: ellenőrizze a prefix tulajdonjogát
Az IPv6 meghal, amint a tunel újra létrejön. Döntse el, kié a delegált prefix, az ügyfélcímek és a visszaút, mielőtt bármit újraindít.
Az IPv6 abban a pillanatban abbahagyja a forgalom átengedését, amikor OpenVPN újraindul, az IPv4 pedig tovább működik. A tunel interfésze újra létrejött, és valami más, ami az IPv6-állapotát kezelte, elvesztette vagy a címet, vagy az útvonalat, amely elérhetővé teszi a prefixet. Három különálló állapotdarab érintett, és mindegyiknek más a tulajdonosa: a szolgáltató delegált prefixe és annak élettartama, a VPN-ügyfeleknek kiosztott címek, és a felső útvonal, amely visszaküldi azt az ügyfélprefixet a szerverhez. Azonosítsa mindegyik tulajdonosát, mielőtt bármelyik daemonhoz nyúlna, mert a rossz újraindítása egy napra elrejti a problémát, és a következő csatlakozáskor visszahozza.
Három IPv6-állapotdarab, három tulajdonos
| 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 |
Egy globális hatókörű cím a tunelen belül önmagában nem elég. A felső routereknek továbbra is vissza kell küldeniük azt a prefixet a VPN-szerver felé, és nem fogják megtenni csak azért, mert a szervernek véletlenül van egy cím abból.
Ezért kockázatos egy nyilvános /64-et tunelpoolba másolni. A szerverhez irányított prefix nem ugyanaz, mint amit a felső oldal on-linkként kezel, és a szomszédkeresés nem tölti ki ezt a rést.
Olvassa ki a szerver állapotát, mielőtt bármit módosít
Rögzítse az állapotot kétszer, egyszer amikor az IPv6 működik, és egyszer az újraindítás után, majd hasonlítsa össze. A csak olvasható nézetek elegendőek, és semmibe sem kerülnek egy karbantartási ablak alatt:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingKeressen három konkrét eltérést: egy eltűnt útvonalat, egy címet, amely elavult vagy érvénytelen élettartamra váltott, és egy prefixet, amely az újradelegálás után megváltozott, miközben a VPN-konfiguráció még a régit hirdeti.
Ha a cím eltűnt, de a prefix változatlan, akkor az azt kiosztó daemon felhagyott az interfész kezelésével. Ha a prefix változott, de a címek nem, akkor az ügyfélkonfiguráció elavult. A két hiba böngészőből azonosnak látszik, és semmi közös nincs bennük.
Döntse el, hogy a dhcpcd kezelje-e a tunelt
A dhcpcd képes interfészeket felfedezni, és egy DHCPv6-prefix részeit továbbdelegálni az alsóbb interfészeknek, a konfigurációja pedig név szerint megadhatja a delegálási célokat. Kifejezett cél nélkül a dokumentált viselkedése más interfészeket is érinthet, és így lesz a tunelnek olyan címe, amelyet senki sem tervezett.
Két feltételnek kellene arra terelnie, hogy az OpenVPN tulajdonába adja a tunel statikus címzését: a szerver fix címeket tol a konfigurációjában, és a tunel neve újracsatlakozáskor megváltozik. Ha mindkettő fennáll, zárja ki a tunelt szándékosan a delegáló daemonból, egy megjegyzéssel, amely megmondja, miért.
Ha viszont a tunelre delegálás szándékos, valósítsa meg a prefixváltozás kezelését. Ez azt jelenti, hogy reagálni kell, amikor a delegált prefix vagy annak élettartama megváltozik, frissíteni kell a szerver által hirdetett ügyfélprefixet, és újra hozzá kell adni az útvonalat. Az interfész kizárása abban a tervben eltávolítja az egyetlen komponenst, amely ismeri az új prefixet.
A dhcpcd újraindítása úgy tűnhet, hogy rendbe hozza a dolgokat, mert újra létrehozza az állapotot, de olyan interfészek konfigurációját is megújítja vagy visszavonja, amelyekre nem gondolt. Az ilyen helyreállítás nem teszi kötelezővé minden VPN-újraindítás után. Azokat a számlálókat is nullázza, amelyeket bizonyítékként használt. Részesítse előnyben a ténylegesen módosított interfész célzott újratöltését.
Az IPv6-ot az IPv4 NAT-tól külön ellenőrizze
Erősítse meg, hogy a továbbítás engedélyezett, és a felső útvonal a tényleges ügyfélprefixre mutat, majd hozzon létre egy új, engedélyezett IPv6-kapcsolatot. Ellenőrizze magának az ügyfélnek az IPv6-os útvonaltábláját is, mert egy nyilvános címet mutató ügyfél nem bizonyítja, hogy a kérése a tunelt használta.
Az IPv4-maszkolás más problémát old meg: a visszautat privát forrásokhoz. Egy visszavont IPv6-prefixért semmit sem tesz, és hozzáadása nem hozza vissza az IPv6-ot.
Zárja le a tulajdonjogi nyilvántartással: melyik komponens delegálja a prefixet, melyik osztja ki az ügyfélcímeket, melyik tartja a visszautat, és mi történik mindegyikkel újracsatlakozáskor. Négy sor egy runbookban megkíméli a következő embert attól, hogy három daemont újraindítson, hogy megtalálja azt, amelyik számított.