IPv6-lähtö kuolee OpenVPN:n uudelleenkäynnistyksen jälkeen: tarkista etuliitteen omistus
IPv6 kuolee, kun tunneli luodaan uudelleen. Päätä, kenelle kuuluvat delegoitu etuliite, asiakkaiden osoitteet ja paluureitti, ennen kuin käynnistät mitään uudelleen.
IPv6 lakkaa välittämästä liikennettä heti, kun OpenVPN käynnistyy uudelleen, ja IPv4 toimii edelleen. Tunnelirajapinta luotiin uudelleen, ja jokin muu sen IPv6-tilaa hallinnut taho menetti joko osoitteen tai reitin, joka tekee etuliitteestä tavoitettavan. Mukana on kolme erillistä tilan osaa, ja jokaisella on eri omistaja: palveluntarjoajan delegoitu etuliite ja sen elinikä, VPN-asiakkaille annetut osoitteet ja ylävirran reitti, joka lähettää asiakasetuliitteen takaisin palvelimelle. Selvitä kunkin osan omistaja ennen kuin kosket yhteenkään taustaprosessiin, sillä väärän uudelleenkäynnistys piilottaa ongelman päiväksi ja tuo sen takaisin seuraavalla yhteydellä.
Kolme IPv6-tilan osaa, kolme omistajaa
| 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 |
Globaalin laajuuden osoite tunnelin sisällä ei yksin riitä. Ylävirran reitittimien on yhä lähetettävä etuliite takaisin VPN-palvelimelle, eivätkä ne tee sitä siksi, että palvelimella sattuu olemaan osoite siitä.
Siksi myös julkisen /64:n kopioiminen tunnelialtaaseen on riskialtista. Palvelimelle reititetty etuliite ei ole sama kuin etuliite, jota ylävirta kohtelee on-link-osoitteena, eikä naapurien löytäminen täytä tätä aukkoa.
Lue palvelimen tila ennen kuin muutat mitään
Tallenna tila kahdesti, kerran kun IPv6 toimii ja kerran uudelleenkäynnistyksen jälkeen, ja vertaa sitten. Vain luku -näkymät riittävät, eivätkä ne maksa mitään huoltoikkunan aikana:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingEtsi kolme konkreettista eroa: kadonnut reitti, vanhentuneeseen tai virheelliseen elinikään siirtynyt osoite ja etuliite, joka muuttui uudelleen delegoinnin jälkeen, kun VPN-kokoonpano yhä mainostaa vanhaa.
Jos osoite katosi mutta etuliite pysyi muuttumattomana, sen jakava taustaprosessi lopetti rajapinnan hallinnan. Jos etuliite muuttui mutta osoitteet eivät, asiakkaan kokoonpano on vanhentunut. Nämä kaksi vikaa näyttävät selaimesta samalta eikä niillä ole mitään yhteistä.
Päätä, pitäisikö dhcpcd:n hallita tunnelia
dhcpcd voi löytää rajapintoja ja delegoida osia DHCPv6-etuliitteestä alavirran rajapinnoille, ja sen kokoonpano voi nimetä delegointikohteet nimenomaisesti. Ilman nimenomaista kohdetta sen dokumentoitu käyttäytyminen voi koskea muita rajapintoja, ja niin tunneliin päätyy osoite, jota kukaan ei suunnitellut.
Kahden ehdon pitäisi ohjata sinua antamaan OpenVPN:lle tunnelin staattinen osoitteistus: palvelin työntää kiinteitä osoitteita kokoonpanossaan, ja tunnelin nimi muuttuu uudelleenyhdistettäessä. Jos molemmat pätevät, jätä tunneli tarkoituksella delegointitaustaprosessin ulkopuolelle ja kirjoita kommentti, joka kertoo miksi.
Jos delegointi tunneliin on sen sijaan tarkoituksellista, toteuta etuliitteen muutoksen käsittely. Se tarkoittaa reagoimista, kun delegoitu etuliite tai sen elinikä muuttuu, palvelimen mainostaman asiakasetuliitteen päivittämistä ja reitin lisäämistä uudelleen. Rajapinnan poissulkeminen siinä suunnittelussa poistaa ainoan komponentin, joka tietää uudesta etuliitteestä.
dhcpcd:n uudelleenkäynnistys voi näyttää korjaavan asioita, koska se luo tilan uudelleen, mutta se myös uudistaa tai peruu kokoonpanon rajapinnoille, joita et ajatellut. Sellainen palautuminen ei tee siitä vaatimusta jokaisen VPN-uudelleenkäynnistyksen jälkeen. Se myös nollaa laskurit, joita käytit todisteena. Suosi kohdennettua uudelleenlatausta rajapinnalle, jota todella muutit.
Validoi IPv6 erikseen IPv4 NAT:sta
Varmista, että edelleenvälitys on käytössä ja että ylävirran reitti osoittaa todelliseen asiakasetuliitteeseen, ja tee sitten uusi sallittu IPv6-yhteys. Tarkista myös asiakkaan oma IPv6-reititystaulu, sillä julkinen osoite ei todista, että asiakkaan pyyntö käytti tunnelia.
IPv4-naamiointi ratkaisee toisen ongelman: paluupolun yksityisille lähteille. Se ei tee mitään peruutetulle IPv6-etuliitteelle, eikä sen lisääminen tuo IPv6:ta takaisin.
Lopeta omistustietueeseen: mikä komponentti delegoi etuliitteen, mikä jakaa asiakasosoitteet, mikä pitää paluureitin ja mitä kullekin tapahtuu uudelleenyhdistettäessä. Neljä riviä runbookissa säästää seuraavalta ihmiseltä kolmen taustaprosessin uudelleenkäynnistyksen, jotta hän löytää sen, jolla oli merkitystä.