Tunela erortzen da, segurtasun-etengailuak jardun duela jakinarazten du, eta deskarga batek aurrera egiten du. Ez dago ezer hautsita IPv4ko arauetan. Aplikazioa soilik arau horiek inoiz idatzi ez ziren bide batera mugitu da.

Pila bikoitzeko gailuek bi irteera independente dituzte. Horietako bat blokeatzea erdi blokeoa da.

Bi arau-multzo, bi lehenetsi

Linuxen, iptables eta ip6tables taula bereiziak dira, politika bereiziekin. IPv4 taularen INPUT eta OUTPUT kateak DROP-era jartzeak ez du ezer aldatzen IPv6 taulan, non lehenetsia normalean ACCEPT den. Banaketa bera dago nftablesen, non familia bat aztertu eta hauetako batek bakarrik daramatzala zure arauak aurki dezakezun. Asimetria hori normala da, eta arazo osoa da.

Horregatik segurtasun-etengailu bat zabala izan daiteke itxuraz eta partzialki jokatu. IPv4ko arauak idatzi zituen script-a exekutatu zen, kontagailuak handitzen dira, erregistro-lerroa agertzen da, eta IPv6 pakete bat interfaze fisikotik erabat ukitu gabe irteten da.

Irakurri zure bezeroak benetan instalatzen duena, marketin-orriak agintzen duena baino. Zenbait bezerok IPv6 tunelera bideratzen dute, batzuek nahita blokeatzen dute, eta beste batzuek bakean uzten dute plataforma-mailako blokeoak beste arau bat ezartzen duen bitartean. Saltzailearen dokumentazioa da hemen fidatzeko moduko iturri bakarra.

Zer esaten dizun interfazearen konfigurazioak

wg-quick-en esku-liburuaren orria IPv6 arauak barne hartzen ditu bere adibide-konfigurazioan, eta arrazoia hutsune hau da zehazki. Adibidea ez da apaingarria. Badago IPv4ko arauek bakarrik bigarren familia irekita utziko luketelako.

Adibidearen erdia kopiatzeak politikaren erdia sortzen du. Hau da isuri honen jatorririk ohikoena. Blog-sarrera batek adibidea laburtu zuen luzeragatik. Orduan bertsio laburtua denek berrerabili zuten txantiloi bihurtu zen.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Bigarren komandoak politika baimengarria inprimatzen badu eta lehenengoak DROP inprimatzen badu, erantzuna aurkitu duzu bezeroa ukitu gabe. Asimetria hori da akatsa.

Zergatik kontsulta bakar bat ez den istorio osoa

Izen bakar batek A erregistroa eta AAAA erregistroa itzul ditzake, eta aplikazioek ez dute denek modu berean aukeratzen. Nabigatzaileak IPv6 nahiago izan dezake sareak eskaintzen duenean eta huts egitean atzera egin, bigarren planoko sinkronizazioak edo eguneratzeko programak bere ebazpen-motorra eta bere lehentasuna erabiltzen dituen bitartean. Beraz, IPv4 bidezko proba arrakastatsu batek bide bat frogatzen du, ez politika.

Sare-trantsizioek ere aldatzen dute erantzuna. Beste Wi-Fi sare batera konektatzeak, loalditik esnatzeak edo mugikorrera aldatzeak IPv6 aurrizki berria eman diezaioke gailuari, eta bulegoko LANean nahikoa zirudien politika ez dator bat etorri.

Probatu tunela itzalita dagoen egoera

Konektatuta zaudela probatzeak tunela funtzionatzen duela esaten dizu. Proba interesgarria erabilgarri ez dagoen egoera da, orduan baita segurtasun-etengailuak eutsi behar duela. Geldiarazi tunela nahita, eta gero probatu garrantzitsuak diren helmugak babesten ari zaren aplikaziotik.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Bi familiek itxita huts egin beharko lukete. IPv4 eskaerak denbora-muga gainditzen badu eta IPv6 eskaerak egoera-kode bat itzultzen badu, politika osatugabea da, eta tunela berriz probatzeak ez du hori aldatuko.

Eduki dokumentatutako salbuespenak proba horretan ere. Sare lokalaren aurkikuntzak, DHCP berritzeak edo VPN amaierarako abiarazte-bideak irisgarri jarraitu behar izatea gerta daiteke, eta salbuespen horiek politikan aipatu beharko lirateke, etenaldi batean aurkitu beharrean. Tunela itzuli ezin duelako huts egiten duen isuri-proba ez da segurtasun-aurkikuntza, konektibitateren aurkikuntza baizik.

Erlazionatutako artikuluak