DS-Lite bloķē ienākošo IPv4 mitināšanu, nevis izejošo VPN

Tulkošanas stāvoklis seko pusei, kas sāk savienojumu. Izsekojiet izejošo pieprasījumu caur B4 un AFTR, pēc tam uzziniet, kāpēc mitināšana neizdodas.

DS-Lite ir veids, kā klientam nodrošināt IPv4 savienojumu pār piekļuves tīklu, kas pārvada tikai IPv6. Mājas maršrutētājam nav savas atsevišķas publiskas IPv4 adreses, un šis vienīgais fakts pārliecina cilvēkus, ka IPv4 VPN nevar darboties no šā savienojuma. Izejošā virzienā tas parasti darbojas labi. Savienojumu pārveido pakalpojumu sniedzējs, un tālā puse redz parastu IPv4 klientu. Tas, kas salūzt, ir pretējais virziens: mitināt kaut ko, kas gaida nepieprasītu ienākošu IPv4. Atšķirība ir tajā, kura puse sāk sarunu.

Kura puse sāk savienojumu

Klients, kas uzsāk savienojumu, gaitā veido tulkošanas stāvokli. Pakalpojumu sniedzēja tulkotājs redz pirmo paketi, piešķir kartējumu un pārsūta to. Atgriešanās trafiks atbilst šim kartējumam, jo kartējums jau pastāv.

Serverim, kas gaida savienojumus, nav tāda stāvokļa, ko radīt. Kādam no ārpuses ir jāsasniedz adrese un ports, kuru kartēšanai pakalpojumu sniedzējs nav piekritis, un tā ir pavisam cita pieprasījuma lieta.

Izsekojiet izejošo pieprasījumu

Arhitektūra RFC 6333 nosauc abus galus. Klienta puses elements ir B4, kas iekapsulē IPv4 IPv6. Pakalpojumu sniedzēja puses elements ir AFTR, kas veic adreses tulkošanu un pārsūta paketi kā IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN serveris saņem parastu IPv4 savienojumu no pakalpojumu sniedzēja pārtulkotās adreses. Tam nav vajadzīgs DS-Lite režīms, īpašs ports vai zināšana, ka klienta piekļuves tīkls ir tikai IPv6. Tieši šo daļu cilvēki izlaiž: tālā puse to nevar noteikt.

Paša klienta konfigurācija ir tikpat parasta. Tam vajadzīgs strādājošs IPv4 ceļš līdz serverim, ko nodrošina B4 un AFTR, un vajadzīgs, lai servera resursdatora nosaukums atrisinātos uz IPv4 adresi.

Kāpēc ienākošā mitināšana ir tas gadījums, kas neizdodas

IPv4 VPN servera uzturēšana mājās ir risinājums, kas saduras ar pakalpojumu sniedzēja kopīgo adresāciju. Pakalpojumu sniedzēja tulkotājam pieder publiskā adrese un kartējumu tabula, un tam nav iemesla vienam abonentam veidot pastāvīgu ienākošu kartējumu.

Mājas maršrutētāja porta pāradresācijas noteikums nevar konfigurēt AFTR. Noteikums vietējā ierīcē ir īsts un pareizs, un tas augšpusē neko nemaina, tāpēc simptoms izskatās kā nedzūdoša ugunsmūra problēma.

Šeit arī operatora līmeņa tulkošana atšķiras no vienas publiskas adreses: pat pareiza vietējā pāradresācija var nonākt adresē, ko dala daudzi abonenti.

Diagnosticējiet pirms piekļuves plāna maiņas

Vispirms apstipriniet nodrošināto režīmu. Vietējais dubultais steks, DS-Lite un tikai IPv6 tīkls, kas izmanto citu tulkošanas mehānismu, ir trīs dažādas konfigurācijas, un pakalpojumu sniedzēja mārketinga nosaukumi ne vienmēr atbilst tehniskajam.

Pēc tam nosakiet četrus novērojumus izejošai kļūmei. Vai klients atrisina VPN resursdatora nosaukumu uz IPv4 galamērķi? Vai darbojas vienkāršs IPv4 savienojums, nevis pārlūka pieprasījums, kas, iespējams, klusi izmantoja IPv6? Kādu transportu un portu klients mēģina, un vai galapunkta žurnāli šo mēģinājumu vispār redz? Vai kļūme notiek sākotnējās apmaiņas laikā, pēc dīkstāves perioda vai tikai lielākos pārvados?

Šīs četras atbildes norāda uz filtrēšanu, tulkošanas stāvokļa izbeigšanos, nepareizu galapunktu vai paketes izmēra apstrādi. Neviens no tiem netiek noteikts, ieraugot DS-Lite konta lapā.

Uzmanīgi lasiet pakalpojumu sniedzēja izmaiņas

Konta izmaiņas var sakrist ar strādājošu savienojumu, vienlaikus mainot vairākas īpašības. Pierakstiet, kura īpašība mainījās, jo jauns paketes nosaukums nav tehnisks skaidrojums.

Norādījums iespējot dubulto steku ir neskaidrs, līdz kāds apstiprina, ko pakalpojumu sniedzējs faktiski nodrošina. Uzskatīt to par universālu prasību IPv4 VPN klientiem nozīmē pārvērst minējumu politikā.

Ja patiesā prasība ir ienākošā IPv4 mitināšana, pārrunājiet ar pakalpojumu sniedzēju atbalstītu ienākošu risinājumu, vietējo adresāciju vai citu piekļuves dizainu. Ja prasība ir portatīvais dators, kas sasniedz attālu serveri, tā vietā jautājiet par tieši šo izejošo plūsmu. Darba kārtība: nosauciet virzienu, apstipriniet nodrošināto režīmu, pārbaudiet vienkāršu IPv4 un vienu transportu, un mainiet piekļuves plānu tikai tad, ja virziens to patiešām prasa.

Saistītie raksti