Kāpēc DNS64 atbildes mainās, tiklīdz VPN izveido savienojumu?

DNS64 atbildes apraksta tīkla izkārtojumu, nevis servera īpašību. Risinātājs sintezē IPv6 adresi no IPv4 adreses, un rezultāts darbojas tikai tur, kur šī prefiksa galā atrodas tulkotājs. Ieviesiet VPN ceļā, un šis izkārtojums var saglabāties, mainīties vai pārstāt būt patiess atkarībā no trim nosacījumiem.

Šie nosacījumi ir atbildējušais risinātājs, maršruts, kas jūsu ierīcei ir līdz sintezētajam prefiksam, un tas, vai kaut kas šajā maršrutā veic tulkošanu. Katru var novērot, un tieši tas padara kļūmi diagnosticējamu.

Uz ko sintezētais AAAA ieraksts patiešām norāda

DNS64 risinātājs atbild uz AAAA vaicājumu par vārdu, kam ir tikai IPv4, iegulstot IPv4 adresi prefiksā, kuru tas ir konfigurēts lietot, un šim darbam zināmais prefikss ir 64:ff9b::/96, kā aprakstīts RFC 6147. Lietojumprogrammai ieraksts izskatās kā jebkurš cits AAAA ieraksts, un tā ir būtība: klients, kam ir tikai IPv6, var mēģināt savienojumu, nezinot, ka galamērķim nekad nav bijis IPv6. Pēc tam šis savienojums ir atkarīgs no NAT64 funkcijas, kas kaut kur ceļā tulko starp abām saimēm. Bez šī tulkotāja sintezētā adrese ir ticami izskatāms galamērķis, kas nekur neved.

Tātad ieraksts kodē divas lietas vienlaikus: sākotnējo IPv4 adresi un pieņēmumu, ka tulkotājs ir sasniedzams. Tikai pirmā ir redzama pašā atbildē.

Trīs nosacījumi izlemj, vai tas joprojām darbojas

Pirmais nosacījums ir, kurš risinātājs izveidoja ierakstu, jo tas bez konfigurēta DNS64 šim vārdam neko neatgriež un lietojumprogramma neizdodas citādi. Otrais ir, vai jūsu ierīcei ir maršruts līdz sintezētajam prefiksam, jo atbilde var būt derīga, kamēr ceļš uz to trūkst. Trešais ir, vai tulkotājs, kam pieder šis prefikss, ir tajā ceļā, kuru jūs izmantotu, jo tunelis, kas nes 64:ff9b::/96 citur, sasniedz citu funkciju vai neko. Visi trīs var būt spēkā pirms tuneļa un neizdoties pēc tam, un tāpēc simptoms izskatās kā pēkšņs regress.

Pārbaudiet tos šajā secībā. Trūkstoša atbilde un trūkstošs maršruts pārlūkā izskatās vienādi, bet risinātāja žurnālā — pilnīgi atšķirīgi.

Kad risinātājs mainās, atbilde mainās

VPN klients bieži iespiež savu risinātāju vai pārņem visu vaicājuma ceļu, un šis risinātājs var neko nesintezēt. Vaicājumi par vārdiem, kam ir tikai IPv4, tad neatgriež nekādu AAAA ierakstu, ko klients, kam ir tikai IPv6, piedzīvo kā vārdu, kuram nevar piekļūt. Notiek arī pretējais: risinātājs, kas tiešām sintezē, var dot prefiksu, kuru jūsu tuneļotais ceļš nenes.

Kešatmiņa padara to grūtāk saskatāmu. Birojā iegūts sintezēts ieraksts var pārdzīvot kontekstu, kas to radīja, tāpēc klients turpina savienoties ar adresi, kuras tulkotājs vairs nav sasniedzams. Skatieties uz risinātāju, kas atbild tagad, nevis uz to, kas atbildēja, kad ieraksts tika saglabāts. Kešatmiņas notīrīšana, nenofiksējot veco un jauno atbildi, iznīcina pierādījumu, kas jums vajadzīgs.

Pārbaudiet vaicājumu un ceļu atsevišķi

Vaicājiet vārdu tieši pirms lietojumprogrammas iesaistīšanas un pierakstiet, kurš serveris atbildēja. Tālāk dotās komandas parāda AAAA ierakstu, izmantoto risinātāju un to, vai pastāv maršruts līdz sintezētajam prefiksam. Izpildiet tās ar izslēgtu tuneli un pēc tam atkal ar ieslēgtu.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Lasiet rezultātus kā ķēdi. Trūkstošs AAAA ieraksts nozīmē, ka risinātājs jums priekšā nesintezē, tāpēc ceļš, kam ir tikai IPv6, šim vārdam nedarbosies, lai ko klients darītu. Ieraksts ir, bet maršruta nav — prefiksu nenes pašreizējais ceļš, un tas ir maršrutēšanas lēmums, nevis risinātāja kļūme. Maršruts ir, bet vaicājums joprojām neizdodas — tas norāda uz pašu tulkotāju, un tas pieder vēl citam īpašniekam.

Pierakstiet risinātāju, tīkla kontekstu un adrešu saimi blakus katram rezultātam. Tieši šis pieraksts ļauj nākamajam salīdzinājumam atdalīt risinātāja maiņu no maršrutēšanas maiņas.