IPv6 OpenVPN tunel baten: etxeko routerraren ibilbidea

Ordenagailu eramangarriak IPv6 helbide bat du, tunela IPv4 gainean dago martxan, eta hala ere IPv6 proba guztiek huts egiten dute. Edo okerrago: probak on egiten du eta trafikoak hornitzailearen bidea hartu zuen tunelean sartu gabe. Bi emaitzak falta den erabaki bakarrera doaz: inork ez zion routerrari bezeroengana bideratu zezakeen aurrizkirik eman. Bezerotik kanporako bidea eginez gero, falta den pieza aurkitzen da.

Hasi bezeroa dagoen tokian

Begiratu bezeroari zerbitzaria ukitu aurretik. ip -6 addr-ek pooleko tunel-helbide bat erakutsi beharko luke, eta ip -6 route-ek tunel-gailurantz seinalatzen duen aurrizki bultzatua. Helbidea badago baina biderik ez, push-a falta da edo bezeroak ezikusi egin dio. Biak falta badira, zerbitzariak ez zuen ezer esleitu.

Ondoren egiaztatu bezeroak kanpoko munduaz zer uste duen. Tunelaren gaineko bideratze lehenetsiak IPv6 trafiko guztia aldarrikatzen du, eta 2000::/3-rako bideak unicast globala soilik. Biak izan daitezke zuzenak, eta isuriei buruzko galdera ezberdinei erantzuten diete.

IPv6 lehenetsirik ez duen bezeroak proba publiko guztietan huts egiten du, tunela bera erabat osasuntsu dagoen arren. Hori politika-hutsunea da, ez tunel hautsia.

Egiaztatu zerbitzariak benetan bideratu dezakeen pool-a

Zerbitzariak benetan kontrolatzen duen aurrizki batetik soilik eslei dezake. Hornitzaileak /56 bat delegatzen badu, erreserbatu /64 bat tunelerako eta utzi gainerakoa LANerako. Hornitzaileak WANen /64 bakarra ematen duenean eta gehiago bideratzen ez duenean, utzi LANeko aurrizkia bakean eta eman tunelari tokiko barruti bakarra, onartuz bezeroek irteera globalik izango ez dutela.

Pool-a eta push-a elkarrekin doaz. server-ipv6 2001:db8:80:10::/64-ek helbideak esleitzen ditu, eta push "route-ipv6 2000::/3"-ek bezeroei tunelean zer bidali esaten die. 2000::/3 bultzatzeak unicast globala estaltzen du eta link-local eta multicast barrutiak tuneletik kanpo uzten ditu.

Idatzi aukeratutako aurrizkia inplementazio-erregistroan. Hurrengoan hornitzailearen entrega aldatzen duenak jakin behar du zein /64 hartzen duen tunelek dagoeneko.

Piztu bigarren familiaren birbidalketa

IPv4 birbidalketak ez du IPv6 birbidalketa esan nahi. Ezarri net.ipv6.conf.all.forwarding=1 eta islatu IPv4ko FORWARD politikak dagoeneko baimentzen duen guztia. Lehenespenez baztertzen duen FORWARD katea duen router batean, falta den arau-multzoak tunel hil baten itxura zehatza du.

Eskuko uztarketa ondo ateratzen da, bezeroak helbidea jasotzen du, eta ez da ezer itzultzen. Gehitu arauak bi noranzkoetarako eta WAN besorako, LANera iristen baina internet ez den tunel batek hirugarren proban huts egiten baitu. Saiakera huts baten ondoren begiratu katearen kontagailuei, inoiz bat etorri ez den araua beste arazo bat baita bat etorri eta baztertu duena baino.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Bigarren efektu batek tunelei errua botatzen dietenak harrapatzen ditu. Birbidalketa piztean kernelak Router Advertisement bidezko helbide-konfigurazioa saltatzen du, bestela esaten ez bazaio, eta horrela ikasitako bideratze lehenetsia harekin desagertzen da. Edo ainguratu bideratze lehenetsi esplizitu bat WAN interfazean, edo jarri accept_ra 2-ra bertan nahita. Edozein aldaketaren ondoren, egiaztatu routerrak oraindik kanporako IPv6 bide erabilgarria duela bezeroak berriro probatu aurretik.

Erantzun bizilagunen aurkikuntzari goiko aldeak bideratzen ez duenean

Goiko aldeko ekipoak batzuetan delegatutako /64 bere loturakotzat hartzen du eta uko egiten dio azpiaurrizkirik VPN kutxarantz bideratzeari. Hori gertatzen denean, zerbait egon behar da bezero-helbide bakoitzeko bizilagun-eskaerei banaka erantzuten diena.

OpenVPN tresnak esleitutako helbidea client-connect kako batera ematen du, beraz sarrerak benetako poolari jarrai diezaiokete eskuz mantentzen den zerrenda baten ordez. Kakoak ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 gehitzen du, eta dagokion client-disconnect kakoak kentzen du. Kendu ezean, proxy taula zahartu egiten da eta geroagoko bezero batek inoiz jaso ez zuen helbide baterako sarrera hereda dezake. Egiaztatu egoera ip -6 neigh show proxy-rekin.

Hartu proxya konponbide behin-behinekotzat. Tunelaren /64rako routerrera zuzendutako bide estatikoak bezeroen aldaketak gainditzen ditu eta ez du shell kako pribilegiatu beharrik.

Jarraitu bidea kanporantz, jauzi batengandik

Probatu kanporantz hiru urratsetan: lehenengo routerraren tunel-helbidea, gero LAN ostalari bat eta hirugarren helmuga publiko bat traceroute6 bidez. Pool-a lehenak frogatzen du, birbidalketa eta LANeko suebakia bigarrenak, eta goiko aldetik itzulera-bidea hirugarrenak. Hutsegite bakoitzak bilaketa gailu bakar batera murrizten du, diseinu osoa berriz ireki ordez.

Begiratu tunelaren MTUari, bidean dauden IPv6 routerrek ez baitute zure ordez zatikatuko. MTU handiegiak packet-too-big errorea eta TLS gelditua erakusten ditu, hutsegite garbia ordez. Ezarri espresuki eta probatu mugarako hurbil dagoen karga batekin.