IPv6 útsette om in VPN-lek te reparearjen? Beslis leaver it belied
In link-local-adres is gjin lek en in globale IPv6-rûte ek net. Kies earst tusken blokkearje, drage en gewurde litte.
In adres út it IPv6-berik ferskynt op in testside, de tunnel draacht it dúdlik net, en it populêrste advys op it ynternet is om IPv6 oeral út te setten. Dat kommando makket it paniel wol stil. It hellet ek in protokol fuort dêr't it tagongsnet fan ôfhingje kin, en it lit jo sûnder idee oft it adres in echte lek wie, in link-local-ynterface-adres, of in resolver dy't syn wurk docht. Trije betingsten beslisse de goede kontrôle, en mar ien fan har liedt ta blokkearjen.
Stel fêst wat it helpmiddel eins metten hat
De meast foarkommende falske alaarm is in link-local-adres, dat mei fe80: begjint en op elk IPv6-geskikt ynterface bestiet, oft de masine no oer IPv6 it ynternet berikke kin of net. It ferskynt yn ynterface-listings en yn guon applikaasjediagnostyk, en it seit neat oer jo ferkearsrûte.
De twadde falske alaarm is in unyk lokaal adres yn fc00::/7, dat in privaat berik is dat binnen in netwurk brûkt wurdt. In helpmiddel dat elk adres fan 'e host printsje, sil it grif neist it publike sette. Wa't fluch lêst, neamt dat in lek en bringt dan in oere troch oan in probleem dat net bestiet.
De tredde is hielendal gjin falske alaarm. In globaal adres dat bûten de tunnel it ynternet berikt, is de echte lek, en it is de muoite wurdich om it te mjitten foardat jo eat beslisje:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
As it earste kommando in globaal adres printet en it tredde in publiek IPv6-adres weromjout dat net fan 'e tunnel is, hawwe jo in echte rûte bûten de tunnel. As it earste neat oars as link-local-ynfieringen printet, wie der nea in lek om te reparearjen.
Trije betingsten beslisse de kontrôle
De beslissing is net "IPv6 goed" of "IPv6 min". It is yn hokker fan trije situaasjes jo binne, en elk hat in oar goed antwurd mei oare kosten as jo it misse.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
De earste rige is wat minsken meastentiids bedoele, en it is legit. In klant waans útgong gjin IPv6-stipe hat, moat it eigen IPv6-ferkear fan 'e host net stilwei nei bûten litte, want dat is de dokumintearre dûbele-stapel-lek. It punt is om it te blokkearjen as in ferklearre belied, net om in protokol by de kearn út te setten. It sichtbere resultaat is itselde en mar ien fan beide kin letter neisjoen wurde.
De tredde rige is wêr't it algemiene advys aktyf skealik wurdt. Mobile operators en guon thúsferbiningen driuwe IPv6-only-netwurken mei oersetting foar IPv4-bestimmings. Helje dêr IPv6 fuort en jo helje it iennige ferfier fuort dat it netwurk biedt, wat in folle slimmer útfal jout as dat jo oan it debuggen wiene.
As de útgong gjin IPv6 hat, blokkearje it dan mei opsetsin
Jou foarkar oan it eigen meganisme fan 'e klant, want it jildt krekt salang't de tunnel omheech is en giet werom as er falt. OpenVPN hat dêr in opsje foar, en iptables hat in lykweardige regel foar oare klanten:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable
De rjochtline heart yn it profyl; de regel heart yn in firewall dy't jo neisjen en fuorthelje kinne. Beide misse sletten, dat is wat jo wolle, en beide binne sichtber yn in konfiguraasje-diff, wat in kearn-sysctl begroeven yn in startskript net is.
Skriuw op wêrom't er der is. In blokkearregel sûnder kommentaar wurdt fuorthelle troch de folgjende persoan dy't IPv6 foar eat oars nedich hat, en dan komt de lek stil werom.
As de útgong IPv6 draacht, rûte it en test beide famyljes
IPv6 drage is it bettere antwurd as de server it stipet, en it is net folle dreger. De eask is dat it tunnel-ynterface in adres yn dat famylje hat en dat de standertrûte dêrfoar de tunnel yn wiist ynstee fan út it fysike ynterface:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co
It rûte-opskiepen is de beslissende test: as it it tunnel-ynterface neamt, wurdt IPv6-ferkear droegen. De twa curl-oproppen befêstigje dan wat elk famylje sjocht, en se fergelykje is de manier om te bewizen dat beide paden no troch deselde útgong ferlitte.
Stop net by in slagge ferbining. Ferbyn it tunnel op 'e nij en kontrolearje wer, want in trochstjoerde IPv6-rûte kin by it opnij opbouwen ferlern gean as de server him allinnich yn 'e begjinkonfiguraasje stjoert. Kontrolearje dan ien útsletten bestimming, want split-tunnel-regels binne wêr't de twa famyljes it meast ferskille.
As it tagongsnet allinnich IPv6 is, lit it gewurde
Guon netwurken biede allinnich IPv6 en ferwachtsje dat it apparaat IPv4-tsjinsten berikt fia in oersettingsmeganisme oan 'e operatorskant. IPv6 útsette op sa'n masine is gjin feiligensferbettering; it hellet de iennige rûte nei wat dan ek fuort. Dat is in sels feroarsake útfal foar in testresultaat dat nimmen nedich hie.
It symptoom fan dit ferkeard dwaan is worksaam en ûnnoflik: de tunnel liket te foarmjen, namme-oplossing wurket, en neat laden. As jo dat nei in IPv6-wiziging sjogge, set de ynstelling dan daliks werom en gean fierder mei de diagnoaze earne oars.
Wat jo ek kieze, hâld de beslissing eksplisyt yn it profyl of de firewall, ferbyn it oan wat de útgong eins stipet, en notearje it dûbele-stapel-gedrach dat de RFC 7359-diskusje oer dûbele stapel beskriuwt. In ferklearre blokkade is belied. In útset protokol is in omwei dy't nimmen neisjen kin, en fan 'e testside ôf sjogge se itselde.