Vai IPv6 trafikam jāiet caur VPN vai tieši?

Pagājušajā mēnesī divi cilvēki man prasīja pretējus rezultātus: viens gribēja, lai VPN aptvertu IPv6, otrs gribēja, lai biroja printeris turpinātu darboties. Viens maršruts ::/0 pats nevar nodrošināt abus. Tas, vai šis maršruts pieder tuneļa iekšpusē, ir atkarīgs no trim nosacījumiem, un pirmais to izslēdz lielākajai daļai komerciālo izeju. Ja izeja nenes IPv6, noklusējuma maršruta virzīšana tur paslēps jūsu trafiku tunelī, kuram nav kur to sūtīt.

Atbildi nosaka trīs nosacījumi

Noklusējuma maršruts ir viena rinda, ::/0, un tas atbilst jebkuram IPv6 galamērķim bez konkrētāka maršruta (RFC 4291). To instalēt ir viegli. Lēmums, vai jums tas jādara, nonāk pie trim nosacījumiem.

Pirmais nosacījums: izejai, ar kuru savienojaties, ir strādājošs IPv6, un tā ir gatava to pārsūtīt. Otrais nosacījums: jūsu klients var saglabāt ceļu uz tuneļa galapunktu, kas parasti atrodas diapazonā, kuru gatavojaties maršrutēt. Trešais nosacījums: jūs varat nosaukt vietējos IPv6 galamērķus, kuriem jāpaliek ārpus tuneļa.

Katrs nosacījums neizdodas savā veidā, tāpēc minēšana izmaksā veselu vakaru. Neizdevies pirmais nosacījums dod jums klusumu un maršrutu tabulu, kas izskatās pareiza. Neizdevies otrais nosacījums nogalina rokasspiedienu dažas sekundes pēc sākuma. Neizdevies trešais nosacījums atstāj strādājošu tuneli un neapmierinātu kolēģi pie printera.

Vai izeja tiešām nes IPv6?

Tuneļa saskarne ar IPv6 adresi neko nepierāda par otru pusi. Daudzi komerciālie profili iekšpusē ir tikai IPv4: serveris dod jums v4 adresi un izmet visu pārējo. Uzstādiet virsū noklusējuma maršrutu no AllowedIPs, un kodols labprāt sūtīs IPv6 uz saskarni, kuras partneris to nekad neredz.

Pārbaudiet no klienta, kamēr tunelis ir pacelts. ping -6 -c 3 2001:4860:4860::8888 un ip -6 route get 2001:4860:4860::8888 atbild uz dažādiem jautājumiem: vai atbilde nāk atpakaļ, un kuru ierīci kodols izvēlējās. Kad otrais nosauc jūsu tuneli, bet pirmais neko neatgriež, problēma ir izejā, nevis maršrutā.

Ja izeju pārvaldāt paši, klienta tests var iziet, un ceļš tomēr var beigties strupceļā. Apstipriniet net.ipv6.conf.all.forwarding=1 vārtejā un to, ka tās ugunsmūris pieņem paketes, kas pārsūtītas no tuneļa. Pareizi maršrutēta pakete izejā, kas atsakās pārsūtīt, no klienta puses izskatās tieši kā maršrutēšanas kļūda.

Vai klients var saglabāt savu ceļu līdz galapunktam?

Šis ir gadījums, kas mani noķēra portatīvajā datorā ar tikai IPv6 WireGuard galapunktu. Galapunkta adrese ir parasta globāla adrese, tāpēc tā iekrīt ::/0. Maršrutējiet visu prefiksu saskarnē, un rokasspiediena paketes dzīs pašas sevi tunelī, kuru tās vēl cenšas uzbūvēt. Tunelis nekad nepaceļas, un nekas klienta izvadē nepasaka, kāpēc.

wg-quick to risina Linux. Tas atvasina maršrutus no AllowedIPs, instalē tos savā tabulā un pievieno politikas noteikumu, lai trafiks uz galapunktu vispirms tiktu atrisināts caur galveno tabulu: noteikums suppress_prefixlength 0, ko atrodat ip -6 rule. Tāpēc wg-quick up gūst panākumus tur, kur ar roku rakstīts ip -6 route add default dev wg0 jūs nogriež.

Pārbaudiet abus stāvokļus ar ip -6 route get <endpoint-v6>, pirms tuneļa pacelšanas un pēc tam. Ja atbilde mainās uz jūsu tuneļa ierīci, jūs esat noņēmuši ceļu, kas tunelim vajadzīgs. Kad maršrutus rakstāt paši, pievienojiet resursdatora maršrutu uz galapunktu caur sākotnējo vārteju, vai savienojieties ar galapunktu caur IPv4 un atstājiet IPv6 lietderīgajai slodzei.

Kam jāpaliek ārpus tuneļa?

Konkrētāki maršruti pārspēj noklusējuma maršrutu, tāpēc prefikss uz saites vai ULA diapazons ar savu maršrutu turpina darboties bez papildu piepūles. Šis ir klusais iemesls, kāpēc tik daudzas pilna tuneļa IPv4 konfigurācijas izdzīvo: LAN prefiksi ir konkrētāki par noklusējuma maršrutu un nekad neiekļūst tunelī.

Tas salūzt, kad vietēja ierīce ir sasniedzama caur globālu adresi, kas ir normāli printerim, kuram tas pats maršrutētājs piešķīra publisku prefiksu, NAS vai televizoram. Šīs adreses atbilst ::/0 un nekam citam, tāpēc tās pārvietojas tunelī kopā ar visu pārējo un pazūd.

Izlemiet pēc galamērķa, nevis pēc protokola. Ja divi vai trīs vietējie resursdatori ir svarīgi, dodiet to prefiksiem maršrutu ārā pa fizisko saskarni, vai izņemiet tos no apspriestā kopuma. Ja saraksts turpina augt, godīgā atbilde ir IPv6 split tunneling ar rakstisku izņēmumu sarakstu, nevis noklusējuma maršruts, ko jūs nepārtraukti lāpāt.

Ja atbilde ir nē, bloķējiet to

Atstāt IPv6 bez maršruta nav tas pats, kas atstāt to mierā. Resursdators ar strādājošu IPv6 noklusējuma maršrutu turpina to lietot, kamēr tunelis pārvadā IPv4, tāpēc trafiks iziet blakus VPN, un katrs pakalpojums, kas dod priekšroku IPv6, redz jūsu īsto adresi. Tā ir noplūde, nevis sadalīts tunelis.

Izvēlieties vienu un pierakstiet, kuru izvēlējāties. Maršrutējiet noklusējuma maršrutu un pieņemiet iepriekš minētos kompromisus, vai atspējojiet IPv6 uz tuneļa darbības laiku. Prefiksa izlaišana no AllowedIPs vien nav pietiekama, jo operētājsistēma patur savu noklusējuma maršrutu. Linux versijā rupjā versija ir sysctl -w net.ipv6.conf.all.disable_ipv6=1; smalkākā versija nomet IPv6 ārpus tuneļa ar ugunsmūra noteikumu. Tālruņu klientos ir skaidrs IPv6 bloķēšanas slēdzis, kas dara to pašu darbu.

Pārbaudiet to kā noplūdi

Paceliet tuneli un nolasiet stāvokli, nevis uzticieties slēdzim. ip -6 route show default jārāda viens noklusējuma maršruts, un ip -6 route get galamērķim ārpus jūsu LAN jānosauc tuneļa ierīce. Atkārtojiet abus pēc atvienošanas: noklusējuma maršruts, kas pārdzīvo tuneli, ir kļūda, kuru meklējāt.

Pēc tam pārbaudiet pretējo virzienu. No resursdatora vietējā tīklā sasniedziet klientu tā vietējā IPv6 adresē. Ja tas pārstāj darboties, trešais nosacījums nekad netika izpildīts, lai ko toreiz apgalvotu maršrutu tabula.

Pierakstiet rezultātu tur, kur to atradīs nākamais cilvēks: kuri prefiksi paliek vietēji, kāpēc un ko klients dara pēc atvienošanas. Divas rindas runbook'ā ietaupa nākamajam inženierim galapunkta cilpas no jauna atklāšanu pusnaktī.