Divu slāņu VPN: adrešu saimi izvēlas klients, nevis jūs

Tunelis ir uzcelts, IPv4 vietnes ielādējas, un viens resursdatora nosaukums pārsniedz laika limitu. Tūlītējs secinājums ir, ka VPN ir salūzis vai akreditācijas dati ir nepareizi, un parasti neviens no abiem nav patiess. Nosaukums atgrieza gan IPv4, gan IPv6 adresi, lietotne izvēlējās vienu, un tikai vienam no šiem kandidātiem bija strādājošs ceļš. Izvēli izdarīja klients; tunelis vienkārši neaptvēra to, ko tas izvēlējās.

Izvēle nav pārklājuma solījums

Noklusējuma adreses izvēle, kas aprakstīta RFC 6724, nosaka, kuru avota un galamērķa pāri resursdators dod priekšroku, ja ir pieejami vairāki. Happy Eyeballs pievieno virsū savienojuma stratēģiju: tas sāk mēģinājumus abās saimēs un patur to, kas atbild pirmais, lai lietotājs negaidītu salūzušas saimes laika limitu.

Neviens no mehānismiem neveido maršrutu. Ja jūsu tunelis pārvadā tikai IPv4, AAAA kandidāts joprojām ir likumīgs galamērķis, ko klients var mēģināt, un kļūme izpaužas kā lēna ielāde, nevis kā kļūda, jo pārlūkprogramma atkāpās. Lietotājs ziņo par lēnu vietni, nevis salūzušu, un atbalsta biļete manto šo neskaidrību. Atkārtojiet to ar fiksētu saimi, un ziņojums kļūs konkrēts.

Šīs atkāpšanās dēļ simptoms dažādās lietotnēs nav konsekvents. Pārlūkprogramma slēpj kavēšanos; komandrindas klients ar fiksētu saimi uzreiz parāda īsto kļūmi.

Atrodiet saimi, kuru pieprasījums faktiski izmantoja

Sāciet ar nosaukumu, nevis tuneli. Vaicājiet abus ierakstu tipus un pierakstiet, kas atgriezās:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Ja v4 pieprasījums izdodas un v6 pieprasījums neizdodas, esat atkārtojis problēmu tādā formā, ko varat atkļūdot. Ja abi izdodas no čaulas un pārlūkprogramma joprojām neizdodas, pirms tuneli aiztikt apskatiet lietotnes pašas risinātāju vai kešatmiņā saglabātu atbildi.

Glabājiet saimi un galamērķi savos pierakstos. Biļeti, kurā teikts, ka vietne neielādējas caur VPN, neviens nevar pārbaudīt, bet biļete, kurā teikts, ka AAAA neizdodas un A strādā, norāda uz konkrētu maršrutu.

Pārbaudiet maršrutu šai saimei

Neizdošanās saimei pajautājiet kodolam, kuru ceļu tas izmantotu, un salīdziniet to ar tuneļa konfigurētajām adresēm. Linux sistēmā ip -6 route get galamērķim parāda saskarni un avotu, kas tiktu izvēlēti.

Pēc tam pārbaudiet pašu tuneli. WireGuard vienaudži nes atļauto IP sarakstu, un ieraksts par 0.0.0.0/0 neko nepasaka par IPv6. Ja vienaudža sarakstā nav IPv6 prefiksa, klientam nav pamata sūtīt AAAA trafiku tunelī, un pakete iziet pa to, ko resursdators citādi darītu.

Ugunsmūra noteikumi un NAT politika ir pelnījuši tādu pašu pārbaudi katrai saimei. Noteikums, kas rakstīts IPv4, neaptver IPv6 nevienā platformā, un tas ir visbiežākais iemesls, kāpēc viena saime strādā, bet otra ne.

Neizslēdziet IPv6, lai ekrānuzņēmums būtu vienkāršāks

IPv6 izslēgšana visā sistēmā liks simptomam pazust un atstās jūs bez diagnozes. Tā arī salauž jebkuru galamērķi, kas ir tikai IPv6, un slēpj to pašu kļūdu nākamajai lietotnei. Ja datoram patiešām nevajadzētu izmantot IPv6, tā ir apzināta politika ar īpašnieku un testu. Tās izslēgšana incidenta laikā nav ne viens, ne otrs.

Izlemiet, kas klientam jādara ar saimi, un konfigurējiet to skaidri: pārvadiet to caur tuneli vai bloķējiet atbalstītā veidā, lai izvēle nekad nepiedāvātu nesasniedzamu kandidātu. Abi ir likumīgi dizaini. Globāla izslēgšana nav ne viens, ne otrs, jo tas vispār nav dizains.

Ko ierakstīt biļetē

Pierakstiet četras lietas: resursdatora nosaukumu, neizdevušos saimi, kodola izvēlēto maršrutu un saimei raksturīgā pieprasījuma rezultātu. Šis kopums ir pietiekams, lai kāds cits atkārtotu kļūmi, neuzminot, kuru no diviem ceļiem jūs domājāt.

RFC 6724 adrešu izvēles noteikumi izskaidro, kāpēc klients deva priekšroku tam kandidātam, kuram deva, un RFC 8305 izskaidro sacensību uzvedību, kas paslēpa kavēšanos. Neviens no tiem neizvēlēs maršrutu paketei jūsu vietā, un tieši tas tunelim jādara.