It splitsen fan jo /64 rûtelet gjin IPv6 nei VPN-klanten

De klant toant in globale IPv6-adres, de hânskuteling is foltôge, en der komt neat werom fan it ynternet. De poolynstelling sjocht der korrekt út om't dy korrekt is; it adres is jildich en de tunnel draacht it. Wat misgiet is de levering, en de levering hinget ôf fan in beslissing dy't boppe de VPN-tsjinner nommen wurdt en dêr't gjin konfiguraasje oan klantekant ynfloed op hawwe kin.

De myte: in stik fan jo /64 is al berikber

It ferhaal is oanloklik: de tsjinner hat in iepenbier /64, snij it midstwa, jow de oare helte oan 'e VPN-pool, en dy klanten binne no op it ynternet. It splitsen fan it foarheaksel jout wol adressen sûnder botsingen. It feroaret lykwols net hoe't it upstream-netwurk beslút wêr't in pakket foar ien fan dy adressen hinne moat.

IPv6 hat gjin standert oersettingslaach om op werom te fallen, dus de weromwei moat bestean as rûtelearring of as levering op keppelingsnivo. In pakket rjochte op it tunneladres fan in klant komt oan by de upstream-rûter, en dy rûter nimt in troerstjoerbeslissing út syn eigen tabel. As de tabel nei de fysike keppeling wiist, giet it pakket dêrhinne, likefolle wat jo VPN-tsjinner tinkt.

Dat is de hiele flater: de foarút-rjochting wurket om't jo tsjinner it stjoert, en de werom-rjochting stjert ien hop fuort om't de upstream nea leard hat dat de klant bestiet.

Wat levering op 'e keppeling wier fereasket

As de upstream it hiele /64 as op 'e fysike keppeling beskôget, löst er elk bestimmingsadres op mei buor-ûntdekking. Hy stjoert in fersyk op dy keppeling en ferwachtet dat de eigner fan it adres antwurdet. In VPN-klant efter in tunnel is net op dy keppeling en kin net antwurdzje, dus it fersyk bliuwt ûnbeantwurde en it pakket wurdt fuortsmiet.

In /65 útspjalte feroaret dy ferwachting net. De upstream behannelet it berik noch hieltyd as op 'e keppeling, om't it iennige dat syn miening feroarje soe in rûte of in proxy is dy't út namme fan 'e klant antwurdet. Net ien fan beide ferskynt om't jo in VPN-konfiguraasje bewurke hawwe. Krekt dy kleau ferklearret wêrom't in pool perfekt wurkje kin tusken syn eigen klanten en dochs fan oar plak net berikber wêze kin.

Proxy-buor-ûntdekking is it meganisme dat de twa wrâlden oerbringe kin. It trochfierpunt antwurdet op fersiken foar de spesifike klantadressen dy't it besit en stjoert it ferkear de tunnel yn. It wurket, en it moat krekt ta dy adressen beheind wurde mei in libbenssyklus dy't de pool folget, om't antwurdzje foar in adres dat jo net mear betsjinje it ferkear fan in oar yn in swart gat feroaret. Guon upstreams akseptearje gjin proxy-antwurden dy't se net ferwachte hiene, dus dit ûntwerp hat ek de ynstimming fan 'e leveransier nedich.

Wat rûtele levering fereasket

It skjinere ûntwerp is in tawizing dy't de upstream wier nei jo trochfierpunt rûtelet. Dat kin in delegaasje-foarheaksel wêze of in statyske rûte foar in lytser blok, en de eask is yn beide gefallen itselde: de tabel fan 'e upstream moat foar it klantberik nei jo tsjinner wize. Dan komt weromferkear by it trochfierpunt oan en it trochfierpunt stjoert it de tunnel yn.

Rûtele levering hellet de fraach fan buor-ûntdekking hielendal fuort, en dêrom is it de muoite wurdich om de leveransier dêrom te freegjen foar't jo eat tûks bouwe. Freegje de rûte skriftlik oan, en befêstigje dat de folgjende hop it adres is dat de upstream wier berikke kin.

Beide ûntwerpen hawwe noch hieltyd IPv6-troerstjoer oan op it trochfierpunt nedich en firewallregels dy't de troerstjoerde stream yn beide rjochtingen tastean. Levering is in foarwaarde, net in ferfanging, foar de rest fan it paad. In wurkjende rûte mei troerstjoer útskeakele jout krekt deselde stilte as in ûntbrekkende rûte, dus kontrolearje beide foar't jo eat opnij ûntwerpe.

Twa ûnôfhinklike rûtes om goed te krijen

It poolfoarheaksel en de eigen standertrûte fan 'e klant binne aparte ynstellingen, en it trochinoar heljen jout in partjele ferbining dy't der as in brutsen tunnel útsjocht. De pool fertelt de tsjinner hokker adressen útdield wurde moatte. De rûtes fan 'e klant beslute nei hokker bestimmings de klant ea ferkear de tunnel yn stjoert.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

It foarheaksel hjirboppe is dokumintaasjeromte, en de troerstjoering jildt allinnich foar IPv6, wat krekt is wat in dûbel-stack-ynset faak wol wylst IPv6-levering noch reparearre wurdt. In IPv4-troerstjoering bringt gjin IPv6-dekking ta stân, en net ien fan beide ynstellingen ferûnderstelt de oare.

Hâld it kontrôleferkear dat IPv6 nedich hat wurkjend ûnder hokker belied jo ek tapasse. Packet Too Big-berjochten binne it klassike slachtoffer fan in firewall dy't allinnich TCP en UDP tastean, en se fuortsmite jout ferbiningen dy't ta stân komme en dan by gruttere oerdrachten fêstrinne.

Rûter-oankundigings binne it tredde bewegende part. As it trochfierpunt begjint oan te kundigjen op 'e uplink, kin dat feroarje wat klanten en buorlju leauwe oer foarheaksels op 'e keppeling, wat it ûntwerp dat jo krekt dokumintearre hawwe stil útskeakelje kin.

Dokumintearje it ûntwerp sadat in werbou it reprodusearret

Skriuw trije objekten apart op: de tawizing fan 'e klant, de bestimmingsrûte fan 'e klant, en de leveringsmetoade fan 'e upstream foar de tawizing. In lêzer dy't alle trije hat kin de ynset werbouwe; in lêzer dy't allinnich de poolynstelling hat sil de oarspronklike bug reprodusearje.

Test dan de werom-rjochting eksplisyt, mei in pakket dat fan bûten weromkomme moat. De openvpn(8)-hânlieding behannelet de opsjes server-ipv6 en redirect, en de rûtebefêstiging fan jo leveransier behannelet de helte dy't de hânlieding net kin.