IPv6 caur IPv4 VPN serveri joprojām prasa īstu IPv6 izeju

Tunelis ceļas, klients iegūst IPv6 adresi no baseina, un tomēr katrs IPv6 galamērķis beidzas ar taimautu. Tunelī nekas nav salūzis: IPv6 lieliski brauc IPv4 transportā, un tā nekad nav bijusi grūtā daļa. Adrese, ko izsniedzi, ir solījums, ko serveris nevar izpildīt, jo izejai nav IPv6 upstream, kur to sūtīt. Labojums pieder izejai, nevis klienta profilam.

Simptoms: adrese ir, ceļa nav

Klienta puses pārbaude rāda globāli izskatīgu IPv6 adresi tuneļa ierīcē un uz to vērstu maršrutu, tāpēc to nepareizi nolasa kā klienta kļūdu. Trafiks iekļūst tunelī, serveris to dekapsulē, un pēc tam pakete nonāk saimniekā, kura maršrutēšanas tabulā nav IPv6 noklusējuma maršruta uz nevienu reālu vietu. Atkarībā no steka iegūsti tūlītēju nesasniedzamību vai klusu nomešanu, un abos gadījumos klients redz taimautu, kas izskatās identiski ugunsmūrim.

Pirms aiztiec klientu, izlasi paša servera maršrutēšanas tabulu, jo tur dzīvo trūkstošā ceļa puse. Serveris ar vienu IPv4 noklusējuma maršrutu jau ir devis tev atbildi.

Seko pakešu pēc dekapsulēšanas

Tuneļa iekšpusē pakete ir parasta IPv6, un tās avots ir klienta adrese. Serveris noņem transporta iekapsulējumu un tad tur vietēju IPv6 paketi, kas jāpārsūta uz nākamo IPv6 lēcienu. IPv4 noklusējuma maršruts to nevar pārvadāt, un tās tulkošana uz IPv4 ir cita funkcija, ko neviens nav ieviesis. Tas ir viss bojājums, un tam nav nekāda sakara ar to, vai VPN klausītājs atbildēja pa IPv4.

IPv6 pār IPv4 iekapsulēšanas mehānika aprakstīta RFC 4213, un svarīgā detaļa tur ir tā, ka galapunktiem joprojām vajadzīgs īsts IPv6 savienojums tuneļa otrā pusē. Galvenes ietīšana nerada upstream no nekā.

Divi tuneļa slāņi, divas neatkarīgas pārbaudes

Pārbaudi katru slāni atsevišķi, jo strādājošs ārējais tunelis slēpj salūzušu iekšējo. Pārbaudi ārējo ceļu ar IPv4 ping no klienta uz serveri un apstiprini izmantoto portu. Pēc tam pārbaudi iekšējo ceļu serverī, kur ip -6 route jārāda noklusējuma vai konkrēts maršruts, kas apgūts no īsta upstream, un ip -6 addr jārāda avota prefikss, ko upstream pieņem. Viss mazāk par to ir rotājums saskarnē.

Unikāla lokāla adrese vai globāli izskatīgs prefikss, uz kuru nekas neatmaršrutē atpakaļ, labprāt parādīsies saskarnē un nekur nenonāks. Publisku sasniedzamību dod upstream, nevis adreses forma.

Tas pats attiecas uz klientu: ip -6 route get 2001:4860:4860::8888 būtu jānosauc tuneļa ierīce, un, ja tā nosauc fizisko, klients VPN IPv6 vispār neizmanto.

Avota prefikss, izmērs un ICMPv6

Pajautā upstream, kādus avota prefiksus tas pieņems pārsūtīšanai, un izmanto vienu no tiem klientu baseinam. Pakalpojumu sniedzējs, kas tev dod /64 servera paša saskarnei, ne vienmēr maršrutē tev otru /64 vai lielāku bloku, un atšķirība ir pēcpusdiena atkļūdošanas, ko atbalsta biļete atrisina ar vienu jautājumu. Jautā rakstiski un glabā atbildi kopā ar konfigurāciju.

Ieplāno budžetā papildu iekapsulējumu, ko tavs steks faktiski izmanto, un uzturi ICMPv6 darbībā, tostarp Packet Too Big. Otra galvene samazina izmantojamo kravu, tāpēc ceļš, kas atbild uz maziem ping, joprojām var neizdoties faila pārsūtīšanā, un ugunsmūris, kas izmet visu ICMPv6, pārvērš labojamu izmēra problēmu melnajā caurumā. Pirms paziņo pakalpojumu, pārbaudi vienu lielu pārsūtīšanu.

Kas ir pavisam cita problēma

Nokļūšana pie tikai IPv4 lietotnes no tikai IPv6 klienta ir tulkošana, nevis tunelēšana, un tai vajadzīgs kaut kas līdzīgs apzināti izvietotam NAT64 risinājumam. Galamērķis nesapratīs papildu tuneļa galveni tikai tāpēc, ka tu to pievienoji. Vēsturiskie pārejas pakalpojumi pelna tādu pašu rūpību: RFC 7526 atcēla 6to4 anycast releja modeli, tāpēc ap to rakstīta pamācība apraksta kaut ko, kam vairs nav uzturēta publiska releja.

Ja serverim nav lietojama IPv6 upstream, izvēles ir atbalstīts upstream, cita izeja vai dokumentēts lēmums, ka IPv6 paliek ārpus tuneļa. Nepieņemami ir teikt klientiem, ka IPv6 pakalpojums pastāv, kamēr viņu parastais IPv6 savienojums klusi apiet VPN.