DS-Lite blokkerer innkomande IPv4-hosting, ikkje utgåande VPN

Omsetjingstilstanden følgjer sida som startar sambandet. Følg ei utgåande førespurnad gjennom B4 og AFTR, og sjå deretter kvifor hosting feilar i staden.

DS-Lite er ein måte å gje ein kunde IPv4-tilkopling over eit aksessnett som berre ber IPv6. Heimrutaren har inga eiga dedikert offentleg IPv4-adresse, og dette eine faktum overtydar folk om at ein IPv4-VPN ikkje kan fungere frå den tilkoplinga. Utgåande fungerer det vanlegvis fint. Tilkoplinga vert omsett av leverandøren, og den fjerne enden ser ein vanleg IPv4-klient. Det som bryt saman, er motsett retning: å hoste noko som ventar uoppfordra innkomande IPv4. Skilnaden er kva ende som startar samtalen.

Kva ende som startar sambandet

Ein klient som startar eit samband, lagar omsetjingstilstand medan han går. Omsetjaren til leverandøren ser den første pakken, tildeler ei mapping og sender han vidare. Returtrafikk passar til den mappinga fordi mappinga alt finst.

Ein tenar som ventar på samband, har ingen slik tilstand å lage. Nokon utanfrå må nå ei adresse og ei port som leverandøren ikkje har gått med på å mappe, og det er ei heilt anna førespurnad.

Følg ei utgåande førespurnad

Arkitekturen i RFC 6333 namngjev begge endar. Elementet på kundesida er B4, som kapslar inn IPv4 i IPv6. Elementet på leverandørsida er AFTR, som utfører adresseomsetjinga og sender pakken vidare som IPv4.

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

VPN-tenaren tek imot ei normal IPv4-tilkopling frå den omsette adressa til leverandøren. Han treng ikkje DS-Lite-modus, ei spesiell port eller kunnskap om at aksessnettet til kunden berre er IPv6. Det er denne delen folk går glipp av: den fjerne enden kan ikkje sjå det.

Konfigurasjonen til klienten sjølv er like vanleg. Han treng ei fungerande IPv4-rute til tenaren, som B4 og AFTR gjev, og han treng at vertsnamnet til tenaren vert løyst til ei IPv4-adresse.

Kvifor innkomande hosting er tilfellet som feilar

Å køyre ein IPv4 VPN-tenar heime er designet som kolliderer med den delte adresseringa til leverandøren. Omsetjaren til leverandøren eig den offentlege adressa og mappingtabellen, og han har inga grunn til å lage ei permanent innkomande mapping for ein abonnent.

Ein portforward-regel på heimrutaren kan ikkje konfigurere AFTR. Regelen er reell og rett på den lokale eininga, og han endrar ingenting oppstraums, difor ser symptomet ut som eit brannmurproblem som ikkje går bort.

Det er òg her omsetjing på operatørnivå skil seg frå éi offentleg adresse: sjølv ein rett lokal forward kan lande på ei adresse som mange abonnentar deler.

Diagnostiser før du endrar aksessplanen

Stadfest først den provisjonerte modusen. Innebygd dobbeltstabel, DS-Lite og eit berre-IPv6-nett som brukar ein annan omsetjingsmekanisme er tre ulike ordningar, og marknadsføringsnamna til leverandøren samsvarar ikkje alltid med det tekniske.

Fastset deretter fire observasjonar for ein utgåande feil. Løyser klienten VPN-vertsnamnet til ein IPv4-destinasjon? Verkar vanleg IPv4-tilkopling, i staden for ei nettlesarførespurnad som kanskje stille brukte IPv6? Kva transport og kva port prøver klienten, og ser loggane til endepunktet i det heile det forsøket? Skjer feilen under den innleiande utvekslinga, etter ein inaktiv periode eller berre ved større overføringar?

Desse fire svara peikar på filtrering, utløp av omsetjingstilstand, eit feil endepunkt eller handsaming av pakkestorleik. Ingen av dei vert fastslått ved å sjå DS-Lite på kontosida.

Les leverandørendringar nøye

Ei kontorendring kan falle saman med ei fungerande tilkopling samstundes som ho endrar fleire eigenskapar på ein gong. Noter kva eigenskap som vart endra, for eit nytt pakkenamn er ikkje ei teknisk forklaring.

Instruksen om å slå på dobbeltstabel er tvitydig til nokon stadfester kva leverandøren faktisk provisjonerer. Å handsame han som eit universelt krav for IPv4 VPN-klientar gjer ei antaking til policy.

Viss det reelle kravet er innkomande IPv4-hosting, drøft ei støtta innkomande ordning, innebygd adressering eller eit anna aksessdesign med leverandøren. Viss kravet er ein berbar PC som når ein ekstern tenar, spør i staden om nettopp den utgåande straumen. Arbeidsrekkjefølgje: namngje retninga, stadfest den provisjonerte modusen, test vanleg IPv4 og éin transport, og endre aksessplanen berre viss retninga faktisk krev det.

Relaterte artiklar