IPv6 kroz IPv4 VPN server i dalje traži IPv6 izlaz

Tunel se podiže, klijent dobija IPv6 adresu iz poola, a svako IPv6 odredište ipak istekne. U tunelu ništa nije pokvareno: IPv6 se sasvim dobro vozi unutar IPv4 transporta i to nikada nije bio težak dio. Adresa koju si dodijelio obećanje je koje server ne može ispuniti, jer izlaz nema IPv6 upstream u koji bi je poslao. Popravka pripada izlazu, a ne klijentskom profilu.

Simptom: adresa bez puta

Provjera na klijentskoj strani pokazuje IPv6 adresu koja izgleda globalno na tunelskom uređaju i rutu koja pokazuje u nju, zbog čega se to pogrešno čita kao klijentska greška. Saobraćaj ulazi u tunel, server ga dekapsulira, a zatim paket završi na hostu čija rutirajuća tabela nema IPv6 zadanu rutu ni prema kojem stvarnom mjestu. Zavisno od stacka dobiješ trenutnu nedostupnost ili tiho odbacivanje, a u oba slučaja klijent vidi istek vremena koji izgleda isto kao firewall.

Pročitaj serverovu vlastitu rutirajuću tabelu prije nego što diraš klijenta, jer upravo tu živi nedostajuća polovina puta. Server s jednom IPv4 zadanom rutom već ti je rekao odgovor.

Prati paket nakon dekapsulacije

Unutar tunela paket je običan IPv6, a izvor je klijentova adresa. Server skine transportnu enkapsulaciju i tada drži nativni IPv6 paket koji se mora proslijediti sljedećem IPv6 hopu. IPv4 zadana ruta ga ne može nositi, a prevođenje u IPv4 je druga funkcija koju niko nije uveo. To je cijeli kvar i nema nikakve veze s tim da li je VPN slušalac odgovorio preko IPv4.

Mehanika enkapsulacije IPv6 u IPv4 opisana je u RFC 4213, a važan detalj tamo je da krajnje točke i dalje trebaju stvarnu IPv6 povezanost s druge strane tunela. Umotavanje zaglavlja ne stvara upstream niotkuda.

Dva tunelska sloja, dvije nezavisne provjere

Provjeri svaki sloj odvojeno, jer ispravan vanjski tunel skriva pokvaren unutrašnji. Provjeri vanjski put IPv4 pingom od klijenta do servera i potvrdi port koji koristiš. Zatim provjeri unutrašnji put na serveru, gdje ip -6 route mora pokazati zadanu ili konkretnu rutu naučenu od stvarnog upstreama, a ip -6 addr mora pokazati izvorni prefiks koji upstream prihvata. Sve manje od toga je ukras na interfejsu.

Jedinstveno-lokalna adresa, ili prefiks koji izgleda globalno a ništa ne rutira natrag do njega, rado će se pojaviti na interfejsu i otići nikuda. Javnu dostupnost daje upstream, a ne oblik adrese.

Isto vrijedi i na klijentu: ip -6 route get 2001:4860:4860::8888 treba da imenuje tunelski uređaj, a ako imenuje fizički, klijent uopšte ne koristi VPN za IPv6.

Izvorni prefiks, veličina i ICMPv6

Pitaj upstream koje izvorne prefikse će prihvatiti za prosljeđivanje i upotrijebi jedan od njih za klijentski pool. Provajder koji ti da /64 za serverov vlastiti interfejs ne rutira ti nužno drugi /64 ili veći blok, a razlika je jedno poslijepodne otklanjanja grešaka koje support tiket riješi jednim pitanjem. Pitaj pismeno i čuvaj odgovor uz konfiguraciju.

Predvidi rezervu za dodatnu enkapsulaciju koju tvoj stack stvarno koristi i održavaj ICMPv6 ispravnim, uključujući Packet Too Big. Drugo zaglavlje skuplja upotrebljivi nosivi teret, pa put koji odgovara na male pingove ipak može pasti na prijenosu datoteke, a firewall koji odbacuje sav ICMPv6 pretvara popravljiv problem s veličinom u crnu rupu. Testiraj jedan veliki prijenos prije nego što najaviš uslugu.

Šta je sasvim drugi problem

Dolazak do aplikacije koja radi samo na IPv4 s klijenta koji radi samo na IPv6 je prevođenje, a ne tuneliranje, i traži nešto poput namjerno postavljenog NAT64 rješenja. Odredište neće razumjeti dodatno tunelsko zaglavlje samo zato što si ga dodao. Historijske tranzicijske usluge zaslužuju istu pažnju: RFC 7526 ukinuo je anycast relay model 6to4, pa uputstvo napisano oko njega opisuje nešto što više nema održavani javni relay.

Ako server nema upotrebljiv IPv6 upstream, izbori su podržani upstream, drugi izlaz ili dokumentovana odluka da IPv6 ostaje izvan tunela. Neprihvatljivo je reći klijentima da IPv6 usluga postoji dok njihova obična IPv6 veza tiho zaobilazi VPN.