IPv6 väljund kaob pärast OpenVPN-i taaskäivitust: kontrollige prefiksi omandit
IPv6 kaob pärast tunneli uuesti loomist. Otsustage, kellele kuuluvad delegeeritud prefiks, kliendi aadressid ja tagasitee, enne kui midagi taaskäivitate.
IPv6 lakkab liiklust läbi laskmast hetkel, mil OpenVPN taaskäivitub, ja IPv4 töötab edasi. Tunneli liides loodi uuesti ja miski muu, mis haldas selle IPv6 olekut, kaotas kas aadressi või marsruudi, mis teeb prefiksi kättesaadavaks. Kaasatud on kolm eraldi olekuosa ja igal on erinev omanik: teenusepakkuja delegeeritud prefiks ja selle eluiga, VPN-kliendile antud aadressid ning ülesvoolu marsruut, mis saadab selle kliendi prefiksi serverile tagasi. Tehke kindlaks iga osa omanik enne, kui puudutate ükskõik millist deemonit, sest vale deemoni taaskäivitamine peidab probleemi päevaks ja toob selle järgmisel ühendusel tagasi.
Kolm IPv6 olekuosa, kolm omanikku
| 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 |
Ülemaailmse ulatusega aadress tunnelis ei ole üksi piisav. Ülesvoolu ruuterid peavad ikkagi selle prefiksi VPN-serveri poole tagasi saatma ja nad ei tee seda sellepärast, et serveril juhtub olema sealt üks aadress.
Seepärast on ka avaliku /64 kopeerimine tunnelite basseini riskantne. Serverile suunatud prefiks ei ole sama, mida ülesvoolu pool käsitleb on-link prefiksina, ja naabrite avastamine seda lünka ei täida.
Lugege serveri olekut enne, kui midagi muudate
Salvestage olek kaks korda, üks kord siis, kui IPv6 töötab, ja üks kord pärast taaskäivitust, seejärel võrrelge. Ainult lugemiseks mõeldud vaated on piisavad ja need ei maksa hooldusakna ajal midagi:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingOtsige kolme konkreetset erinevust: kadunud marsruuti, aegunud või kehtetule elueale liikunud aadressi ja prefiksi, mis muutus pärast uut delegeerimist, samal ajal kui VPN-i konfiguratsioon reklaamib ikka veel vana.
Kui aadress kadus, aga prefiks jäi muutumatuks, lõpetas selle määrava deemon liidese haldamise. Kui prefiks muutus, aga aadressid mitte, on kliendi konfiguratsioon aegunud. Need kaks tõrget näevad brauserist identsed välja ja neil pole midagi ühist.
Otsustage, kas dhcpcd peaks tunnelit haldama
dhcpcd suudab liideseid avastada ja DHCPv6 prefiksi osi allavoolu liidestele delegeerida, ning selle konfiguratsioon saab delegeerimise sihtmärke selgesõnaliselt nimetada. Ilma selge sihtmärgita võib selle dokumenteeritud käitumine hõlmata teisi liideseid, ja nii saab tunnel aadressi, mida keegi ei planeerinud.
Kaks tingimust peaksid teid suunama jätma tunneli staatilise adresseerimise OpenVPN-i omandisse: server surub oma konfiguratsioonis peale fikseeritud aadressid ja tunneli nimi muutub uuesti ühendamisel. Kui mõlemad kehtivad, jätke tunnel delegeerimise deemonist teadlikult välja, kommentaariga, mis ütleb, miks.
Kui delegeerimine tunnelile on hoopis tahtlik, rakendage prefiksi muutumise käsitlemine. See tähendab reageerimist, kui delegeeritud prefiks või selle eluiga muutub, serveri reklaamitud kliendi prefiksi uuendamist ja marsruudi uuesti lisamist. Liidese väljajätmine selles lahenduses eemaldab ainsa komponendi, mis uut prefiksi teab.
dhcpcd taaskäivitamine võib tunduda asju parandavat, sest see loob oleku uuesti, kuid see uuendab või tühistab konfiguratsiooni ka liideste jaoks, mille peale te ei mõelnud. See taastamine ei tee seda kohustuslikuks pärast iga VPN-i taaskäivitust. See lähtestab ka loendurid, mida te tõendina kasutasite. Eelistage sihitud uuesti laadimist liidesele, mida te tegelikult muutsite.
Kontrollige IPv6-t IPv4 NAT-ist eraldi
Veenduge, et edastamine on lubatud ja ülesvoolu marsruut osutab tegelikule kliendi prefiksile, seejärel looge uus lubatud IPv6-ühendus. Kontrollige ka kliendi enda IPv6 marsruutimistabelit, sest avalikku aadressi näitav klient ei tõesta, et tema päring kasutas tunnelit.
IPv4 maskeerimine lahendab teise probleemi: tagasitee privaatsete allikate jaoks. See ei tee tühistatud IPv6 prefiksi jaoks midagi ja selle lisamine ei too IPv6-t tagasi.
Lõpetage omandiregistriga: milline komponent delegeerib prefiksi, milline määrab kliendi aadressid, milline hoiab tagasiteed ja mis juhtub igaühega uuesti ühendamisel. Neli rida runbookis säästavad järgmisel inimesel kolme deemoni taaskäivitamise, et leida see, millel oli tähtsust.