IPv6 desaktibatu VPN-i ihesa konpontzeko? Hobe erabaki politika
Link-local helbidea ez da ihesa, eta IPv6 ibilbide globala ere ez. Lehenengo aukeratu blokeatu, eraman edo bakean utzi.
IPv6 barrutiko helbide bat proba-orri batean agertzen da, tunelak argi eta garbi ez du eramaten, eta interneteko aholkurik ezagunena IPv6 nonahi desaktibatzea da. Komando horrek panela isilarazten du. Baina sarbide-sareak behar dezakeen protokolo bat ere kentzen du, eta ez dakizu helbidea ihes erreala zen, link-local interfaze-helbidea zen ala bere lana egiten ari zen resolver bat zen. Hiru baldintzak erabakitzen dute kontrol egokia, eta horietako batek bakarrik darama blokeatzera.
Egiaztatu zer neurtu duen tresnak benetan
Gehien gertatzen den alarme faltsua link-local helbidea da; fe80: rekin hasten da eta IPv6 gaitasuna duen interfaze guztietan dago, makinak IPv6 bidez internetera irits daitekeen ala ez. Interfaze-zerrendetan eta aplikazioen diagnostiko batzuetan agertzen da, eta ez du ezer esaten zure trafiko-bideari buruz.
Bigarren alarme faltsua fc00::/7 barruko helbide lokal bakarra da, sare baten barruan erabiltzen den barruti pribatua. Hostak dituen helbide guztiak inprimatzen dituen tresnak pozik zerrendatuko du publikoa denaren ondoan. Azkar irakurtzen duenak ihesa deitzen dio, eta gero ordu bat ematen du existitzen ez den arazo batean.
Hirugarrena ez da inolaz ere alarme faltsua. Tunelatik kanpo internetera iristen den helbide globala da ihes erreala, eta merezi du neurtzea ezer erabaki aurretik:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coLehenengo komandoak helbide globala inprimatzen badu eta hirugarrenak tunelarena ez den IPv6 helbide publikoa itzultzen badu, tunelatik kanpoko bide erreala duzu. Lehenengoak link-local sarrerak baino ez baditu inprimatzen, ez zen inoiz konpontzeko ihesik egon.
Hiru baldintzak erabakitzen dute kontrola
Erabakia ez da "IPv6 ona" edo "IPv6 txarra". Erabakia hiru egoeretatik zein den da, eta bakoitzak erantzun zuzen desberdina du, oker eginez gero kostu desberdinarekin.
| 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 |
Lehenengo errenkada da jendeak normalean esan nahi duena, eta zilegia da. Irteerak IPv6 onarpenik ez duen bezeroak ez luke hostaren IPv6 trafiko natiboa isilka irten behar, hori baita dokumentatutako pila bikoitzeko ihesa. Kontua da politika adierazi gisa blokeatzea, ez protokolo bat nukleoan desaktibatzea. Ikusgai den emaitza berdina da eta bietako bat bakarrik berrikus daiteke geroago.
Hirugarren errenkada da aholku orokorra benetan kaltegarria bihurtzen den lekua. Operadore mugikorrek eta etxeko konexio batzuek IPv6-only sareak darabiltzate IPv4 helmuguetarako itzulpenez. Kendu IPv6 han eta sareak eskaintzen duen garraio bakarra kentzen duzu, eta horrek konpontzen ari zinen hutsa baino askoz okerragoa sortzen du.
Irteerak IPv6 ez badu, blokeatu nahita
Nahiago bezeroaren mekanismoa, tunela altxatuta dagoen bitartean zehazki aplikatzen delako eta erortzean atzera egiten duelako. OpenVPN tresnak badu horretarako aukera bat, eta iptablesek baliokidea den araua du beste bezeroentzat:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableZuzentaraua profilean dagokio; araua berrikusi eta kendu dezakezun suebaki batean dagokio. Biek itxita huts egiten dute, hori da nahi duzuna, eta biak konfigurazio-diff batean ikusten dira, hasierako script batean lurperatutako nukleo-sysctl bat ez bezala.
Idatzi zergatik dagoen. Iruzkinik gabeko blokeo-araua IPv6 beste zerbaitetarako behar duen hurrengo pertsonak kenduko du, eta orduan ihesa isilka itzuliko da.
Irteerak IPv6 eramaten badu, bideratu eta probatu bi familiak
IPv6 eramatea da erantzun hobea zerbitzariak onartzen duenean, eta ez da askoz zailagoa. Baldintza da tunelaren interfazeak familia horretako helbidea izatea eta haren bide lehenetsia tunelera joatea, interfaze fisikotik kanpora joan beharrean:
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.coIbilbide-kontsulta da proba erabakigarria: tunelaren interfazea izendatzen badu, IPv6 trafikoa eramaten ari da. Bi curl deiek gero egiaztatzen dute familia bakoitzak zer ikusten duen, eta haiek alderatzea da bi bideak orain irteera beretik ateratzen direla frogatzeko modua.
Ez zaitez gelditu konexio arrakastatsu batean. Berriz konektatu tunela eta egiaztatu berriro, bultzatutako IPv6 ibilbidea gal baitaiteke berrezartzean zerbitzariak hasierako konfigurazioan soilik bidaltzen badu. Gero egiaztatu baztertutako helmuga bat, split-tunnel arauak baitira bi familiak sarrien desadosten duten lekua.
Sarbide-sarea IPv6 soilik bada, utzi bakean
Sare batzuek IPv6 baino ez dute ematen eta gailuak IPv4 zerbitzuetara operadorearen aldeko itzulpen-mekanismo baten bidez iristea espero dute. Halako makinan IPv6 desaktibatzea ez da segurtasun-hobekuntza; edozertara doan bide bakarra kentzen du. Norberak eragindako etena da inork behar ez zuen proba-emaitza baten mesedetan.
Hau oker egitearen sintoma bereizgarria eta desatsegina da: tunela ezartzen dela dirudi, izen-ebazpena funtzionatzen du, eta ezerk ez du kargatzen. IPv6 aldaketaren ondoren hori ikusten baduzu, leheneratu ezarpena berehala eta jarraitu diagnostikoa beste nonbait.
Edozer aukeratzen duzula ere, eduki erabakia esplizitua profilean edo suebakian, lotu irteerak benetan onartzen duenari, eta ohar ezazu RFC 7359 pila bikoitzeko eztabaidak deskribatzen duen portaera . Blokeo adierazia politika da. Protokolo desaktibatua inork auditatu ezin duen ingurubide bat da, eta proba-orritik berdinak dirudite.