Laptop ima IPv6 adresu, tunel je podignut preko IPv4, a svaki IPv6 test pada. Ili još gore, test uspije i saobraćaj izađe preko ISP puta, a da nikada nije ušao u tunel. Oba ishoda vode do jedne nedostajuće odluke: niko nije dao ruteru prefiks koji bi mogao rutirati prema klijentima. Praćenje puta od klijenta prema vani otkriva koji dio nedostaje.

Počnite tamo gdje sjedi klijent

Pogledajte klijenta prije nego što dotaknete server. ip -6 addr treba pokazati tunelsku adresu iz poola, a ip -6 route treba pokazati proslijeđeni prefiks koji pokazuje na tunelski uređaj. Kada adresa postoji a ruta ne, push nedostaje ili ga je klijent ignorisao. Kada nema ni jednog ni drugog, server nije dodijelio baš ništa.

Zatim provjerite šta klijent misli o vanjskom svijetu. Zadana ruta kroz tunel traži sav IPv6 saobraćaj, dok ruta za 2000::/3 traži samo globalni unicast. Oboje može biti ispravno i odgovaraju na različita pitanja o curenju.

Klijent bez ikakve IPv6 zadane rute pada na svakom javnom testu iako je sam tunel potpuno zdrav. To je praznina u politici, a ne pokvaren tunel.

Provjerite pool koji server zaista može rutirati

Server može dodjeljivati samo iz prefiksa koji zaista kontroliše. Ako ISP delegira /56, rezervišite jedan /64 za tunel, a ostatak ostavite za LAN. Kada ISP na WAN-u preda samo jedan /64 i ništa dalje ne rutira, ostavite LAN prefiks na miru i dajte tunelu jedinstven lokalni raspon, prihvatajući da klijenti neće imati globalni izlaz.

Pool i push idu zajedno. server-ipv6 2001:db8:80:10::/64 dodjeljuje adrese, a push "route-ipv6 2000::/3" govori klijentima šta da šalju u tunel. Guranje 2000::/3 pokriva globalni unicast i ostavlja link-local i multicast raspone izvan tunela.

Upišite izabrani prefiks u zapis o postavljanju. Onaj ko sljedeći promijeni ISP predaju mora znati koji /64 tunel već zauzima.

Uključite prosljeđivanje za drugu familiju

IPv4 prosljeđivanje ne podrazumijeva IPv6 prosljeđivanje. Postavite net.ipv6.conf.all.forwarding=1 i preslikajte sve što IPv4 FORWARD politika već dozvoljava. Na ruteru čiji FORWARD lanac po zadanom odbija, nedostajući skup pravila izgleda isto kao mrtav tunel.

Rukovanje uspije, klijent dobije adresu, a nazad ne dođe ništa. Dodajte pravila za oba smjera i za WAN krak, jer tunel koji stigne do LAN-a ali ne do interneta pada na trećem testu. Nakon neuspjelog pokušaja pogledajte brojače lanca, jer pravilo koje nikada nije pogodilo je drugačiji problem od onog koje je pogodilo i odbacilo.

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

Jedan nuspojava uhvati ljude koji na kraju krive tunel. Uključivanje prosljeđivanja tjera kernel da preskoči konfiguraciju adrese putem Router Advertisement, osim ako mu ne kažete drugačije, a zadana ruta naučena tako nestaje s njom. Ili prikujte izričitu zadanu rutu na WAN interfejsu, ili tamo namjerno postavite accept_ra na 2. Nakon bilo koje promjene potvrdite da ruter još ima upotrebljiv IPv6 put prema vani prije nego ponovo testirate klijente.

Odgovorite na otkrivanje susjeda kada uzvodna strana ne rutira

Uzvodna oprema ponekad tretira delegirani /64 kao da pripada njenom vlastitom linku i odbija rutirati bilo koji podprefiks do VPN kutije. Kada se to dogodi, nešto mora odgovoriti na zahtjeve susjeda za svaku klijentsku adresu pojedinačno.

OpenVPN izlaže dodijeljenu adresu client-connect hooku, pa zapisi mogu slijediti pravi pool umjesto liste koja se održava ručno. Hook dodaje ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, a odgovarajući client-disconnect hook ga uklanja. Bez uklanjanja proxy tabela zastari i kasniji klijent može naslijediti zapis za adresu koju nikada nije dobio. Potvrdite stanje pomoću ip -6 neigh show proxy.

Tretirajte proxy kao zaobilazno rješenje. Statička ruta za tunelski /64 usmjerena na ruter preživljava promjene klijenata i uopšte ne zahtijeva privilegovani shell hook.

Pratite put prema vani, skok po skok

Testirajte prema vani u tri koraka: prvo tunelska adresa rutera, zatim LAN host, i treće javno odredište preko traceroute6. Pool dokazuje prvi korak, prosljeđivanje i LAN firewall drugi, a povratni put preko uzvodne strane treći. Svaki neuspjeh sužava pretragu na jedan uređaj umjesto da ponovo otvara cijeli dizajn.

Pazite na MTU tunela, jer IPv6 ruteri na putu neće fragmentirati umjesto vas. Preveliki MTU se pojavljuje kao greška packet-too-big i zastali TLS, a ne kao čist neuspjeh. Postavite ga izričito i testirajte s teretom blizu granice.

Povezani članci