DS-Lite blokas envenantan IPv4-gastigadon, ne elirantan VPN

DS-Lite estas maniero doni al kliento IPv4-konektecon tra alira reto, kiu portas nur IPv6. La hejma encaminilo ne havas propran dediĉitan publikan IPv4-adreson, kaj tiu sola fakto konvinkas homojn, ke IPv4-VPN ne povas funkcii el tiu konekto. Elire ĝi kutime funkcias bone. La konekton tradukas la provizanto, kaj la malproksima fino vidas ordinaran IPv4-klienton. Kio rompiĝas estas la kontraŭa direkto: gastigi ion, kio atendas nepetitan envenantan IPv4. La diferenco estas, kiu flanko komencas la konversacion.

Kiu flanko komencas la konekton

Kliento, kiu iniciatas konekton, kreas tradukan staton dum ĝi iras. La tradukilo de la provizanto vidas la unuan paketon, asignas mapadon kaj plusendas ĝin. Revena trafiko kongruas kun tiu mapado ĉar la mapado jam ekzistas.

Servilo, kiu atendas konektojn, havas neniun tian staton por krei. Iu de ekstere devas atingi adreson kaj pordon, kiujn la provizanto ne konsentis mapi, kaj tio estas tute alia peto.

Sekvu elirantan peton

La arkitekturo en RFC 6333 nomas ambaŭ finojn. La klientflanka elemento estas la B4, kiu enkapsuligas IPv4 en IPv6. La provizantflanka elemento estas la AFTR, kiu plenumas la adresan tradukon kaj plusendas la paketon kiel IPv4.

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

La VPN-servilo ricevas normalan IPv4-konekton de la tradukita adreso de la provizanto. Ĝi bezonas nek DS-Lite-reĝimon, nek specialan pordon, nek konscion, ke la alira reto de la kliento estas nur IPv6. Tio estas la parto, kiun homoj maltrafas: la malproksima fino ne povas tion scii.

La propra agordo de la kliento estas same ordinara. Ĝi bezonas funkciantan IPv4-vojon al la servilo, kiun B4 kaj AFTR provizas, kaj ĝi bezonas, ke la gastigantnomo de la servilo solviĝu al IPv4-adreso.

Kial envenanta gastigado estas la kazo, kiu malsukcesas

Ruli IPv4-VPN-servilon hejme estas la dezajno, kiu kolizias kun la kunhava adresado de la provizanto. La tradukilo de la provizanto posedas la publikan adreson kaj la mapadan tabelon, kaj ĝi havas neniun kaŭzon krei permanentan envenantan mapadon por unu abonanto.

Pordplusenda regulo sur la hejma encaminilo ne povas agordi la AFTR. La regulo estas reala kaj ĝusta sur la loka aparato, kaj ĝi ŝanĝas nenion supren, tial la simptomo aspektas kiel fajroŝirma problemo, kiu ne foriras.

Ĉi tie ankaŭ la traduko je operatora nivelo diferencas de unu publika adreso: eĉ ĝusta loka plusendo povas surteriĝi sur adreso, kiun multaj abonantoj kunhavas.

Diagnozu antaŭ ol ŝanĝi la aliran planon

Unue konfirmu la provizitan reĝimon. Denaska duobla stako, DS-Lite kaj nur-IPv6-reto uzanta alian tradukan mekanismon estas tri malsamaj aranĝoj, kaj la merkatikaj nomoj de la provizanto ne ĉiam kongruas kun la teknika.

Poste starigu kvar observojn por elira malsukceso. Ĉu la kliento solvas la VPN-gastigantnomon al IPv4-celo? Ĉu simpla IPv4-konekteco funkcias, anstataŭ retumila peto, kiu eble silente uzis IPv6? Kiun transporton kaj pordon la kliento provas, kaj ĉu la protokoloj de la finpunkto entute vidas tiun provon? Ĉu la malsukceso okazas dum la komenca interŝanĝo, post senokupa periodo, aŭ nur ĉe pli grandaj transigoj?

Tiuj kvar respondoj montras al filtrado, al eksvalidiĝo de la traduka stato, al malĝusta finpunkto aŭ al traktado de paketa grando. Neniu el ili estas pruvata per tio, ke vi vidas DS-Lite sur la konta paĝo.

Legi provizantajn ŝanĝojn atente

Konta ŝanĝo povas koincidi kun funkcianta konekto dum ĝi ŝanĝas plurajn ecojn samtempe. Notu, kiu eco ŝanĝiĝis, ĉar nova paka nomo ne estas teknika klarigo.

Instrukcio ebligi duoblan stakon estas ambigua ĝis iu konfirmas, kion la provizanto fakte provizas. Trakti ĝin kiel universalan postulon por IPv4-VPN-klientoj igas konjekton politiko.

Se la reala postulo estas envenanta IPv4-gastigado, diskutu kun la provizanto subtenatan envenantan aranĝon, denaskan adresadon aŭ alian aliran dezajnon. Se la postulo estas tekokomputilo atinganta malproksiman servilon, demandu anstataŭe pri tiu preciza elira fluo. Ordo de laboro: nomu la direkton, konfirmu la provizitan reĝimon, testu simplan IPv4 kaj unu transporton, poste ŝanĝu la aliran planon nur se la direkto tion efektive postulas.