Ĉu malŝalti IPv6 por ripari VPN-likon? Decidu la politikon anstataŭe
Link-local adreso ne estas liko, kaj tutmonda IPv6-vojo ankaŭ ne. Unue elektu inter blokado, portado kaj lasado.
Adreso el la IPv6-gamo aperas sur testa paĝo, la tunelo evidente ne portas ĝin, kaj la plej populara konsilo en la interreto estas malŝalti IPv6 ĉie. Tiu komando ja silentigas la panelon. Ĝi ankaŭ forigas protokolon, de kiu la alirreto povas dependi, kaj ĝi lasas vin sen ia ideo, ĉu la adreso estis vera liko, link-local-havaĵa adreso, aŭ solvilo faranta sian laboron. Tri kondiĉoj decidas la ĝustan regadon, kaj nur unu el ili kondukas al blokado.
Identigu, kion la ilo fakte mezuris
La plej ofta falsa alarmo estas link-local-adreso, kiu komenciĝas per fe80: kaj ekzistas sur ĉiu IPv6-kapabla havaĵo, sendepende ĉu la maŝino povas atingi la interreton per IPv6. Ĝi aperas en listoj de havaĵoj kaj en iuj aplikaĵaj diagnozoj, kaj ĝi diras nenion pri via trafika vojo.
La dua falsa alarmo estas unika loka adreso en fc00::/7, kiu estas privata gamo uzata ene de reto. Ilo, kiu presas ĉiun adreson de la gastiganto, volonte montros ĝin apud la publika. Iu, kiu legas rapide, nomas tion liko kaj poste pasigas horon pri problemo, kiu ne ekzistas.
La tria tute ne estas falsa alarmo. Tutmonda adreso, kiu atingas la interreton ekster la tunelo, estas la vera liko, kaj indas mezuri ĝin antaŭ ol decidi ion ajn:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coSe la unua komando presas tutmondan adreson kaj la tria redonas publikan IPv6-adreson, kiu ne estas tiu de la tunelo, vi havas veran vojon ekster la tunelo. Se la unua presas nur link-local-rikordojn, neniam estis liko por ripari.
Tri kondiĉoj decidas la regadon
La decido ne estas "IPv6 bona" aŭ "IPv6 malbona". Temas pri tio, en kiu el tri situacioj vi troviĝas, kaj ĉiu havas malsaman ĝustan respondon kun malsama kosto, se vi eraras.
| 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 |
La unua vico estas tio, kion homoj kutime celas, kaj ĝi estas legitima. Kliento, kies eliro ne subtenas IPv6, ne devus silente lasi la propran IPv6-trafikon de la gastiganto eliri, ĉar tio estas la dokumentita duobla-staka liko. La celo estas bloki ĝin kiel deklarita politiko, ne malŝalti protokolon en la kerno. La videbla rezulto estas identa kaj nur unu el ili povas esti reviziita poste.
La tria vico estas kie la ĝenerala konsilo fariĝas aktive malutila. Movaj operatoroj kaj iuj hejmaj konektoj funkciigas IPv6-only-retojn kun tradukado por IPv4-celoj. Forigu IPv6 tie kaj vi forigos la solan transporton, kiun la reto ofertas, kio kaŭzas multe pli malbonan interrompon ol tiu, kiun vi sencimigis.
Se la eliro ne havas IPv6, bloku ĝin intence
Preferu la propran mekanismon de la kliento, ĉar ĝi validas precize dum la tunelo staras kaj revenas kiam ĝi falas. OpenVPN havas opcion por tio, kaj iptables havas ekvivalentan regulon por aliaj klientoj:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableLa direktivo apartenas al la profilo; la regulo apartenas al fajroŝirmilo, kiun vi povas revizii kaj forigi. Ambaŭ malsukcesas fermite, kion vi volas, kaj ambaŭ videblas en agorda difino, kion kerno-sysctl enterigita en startiga skripto ne faras.
Notu, kial ĝi estas tie. Blokadan regulon sen komento forigos la sekva persono, kiu bezonas IPv6 por io neligita, kaj tiam la liko trankvile revenas.
Se la eliro portas IPv6, voju ĝin kaj testu ambaŭ familiojn
Porti IPv6 estas la pli bona respondo kiam la servilo subtenas ĝin, kaj ĝi ne estas multe pli malfacila. La postulo estas, ke la tunela havaĵo havu adreson en tiu familio kaj ke la defaŭlta vojo por ĝi montru en la tunelon anstataŭ el la fizika havaĵo:
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.coLa voj-serĉo estas la decida testo: se ĝi nomas la tunelan havaĵon, IPv6-trafiko estas portata. La du curl-vokoj poste konfirmas, kion vidas ĉiu familio, kaj kompari ilin estas la maniero pruvi, ke ambaŭ vojoj nun eliras per la sama eliro.
Ne haltu ĉe sukcesa konekto. Rekonektu la tunelon kaj kontrolu denove, ĉar puŝita IPv6-vojo povas perdiĝi ĉe reestablo se la servilo sendas ĝin nur en la komenca agordo. Poste kontrolu unu ekskluditan celon, ĉar split-tunnel-reguloj estas tie, kie la du familioj plej ofte malkonsentas.
Se la alirreto estas nur IPv6, lasu ĝin trankvila
Iuj retoj provizas nur IPv6 kaj atendas, ke la aparato atingos IPv4-servojn per traduka mekanismo ĉe la operatora flanko. Malŝalti IPv6 sur tia maŝino ne estas sekureca plibonigo; ĝi forigas la solan vojon al io ajn. Tio estas memkaŭzita interrompo por testrezulto, kiun neniu bezonis.
La simptomo de ĉi tiu eraro estas distingebla kaj malagrabla: la tunelo ŝajne establiĝas, nom-solvado funkcias, kaj nenio ŝargiĝas. Se vi vidas tion post IPv6-ŝanĝo, tuj restarigu la agordon kaj daŭrigu la diagnozon aliloke.
Kion ajn vi elektos, tenu la decidon eksplicita en la profilo aŭ la fajroŝirmilo, ligu ĝin al tio, kion la eliro fakte subtenas, kaj notu la duobla-stakan konduton, kiun priskribas la RFC 7359-diskuto pri duobla stako . Deklarita blokado estas politiko. Malŝaltita protokolo estas provizora solvo, kiun neniu povas revizii, kaj ili aspektas identaj de la testa paĝo.