DS-Lite blokkerer innkommende IPv4-hosting, ikke utgående VPN

DS-Lite er en måte å gi en kunde IPv4-tilkobling over et aksessnett som bare bærer IPv6. Hjemmeruteren har ingen egen dedikert offentlig IPv4-adresse, og dette ene faktum overbeviser folk om at en IPv4-VPN ikke kan fungere fra den tilkoblingen. Utgående fungerer det vanligvis fint. Tilkoblingen oversettes av leverandøren, og den fjerne enden ser en vanlig IPv4-klient. Det som bryter sammen, er motsatt retning: å hoste noe som forventer uoppfordret innkommende IPv4. Forskjellen er hvilken ende som starter samtalen.

Hvilken ende som starter forbindelsen

En klient som starter en forbindelse, lager oversettelsestilstand mens den går. Leverandørens oversetter ser den første pakken, tildeler en mapping og videresender den. Returtrafikk passer til den mappingen fordi mappingen allerede finnes.

En server som venter på forbindelser, har ingen slik tilstand å lage. Noen utenfra må nå en adresse og en port som leverandøren ikke har gått med på å mappe, og det er en helt annen forespørsel.

Følg en utgående forespørsel

Arkitekturen i RFC 6333 navngir begge ender. Elementet på kundesiden er B4, som kapsler inn IPv4 i IPv6. Elementet på leverandørsiden er AFTR, som utfører adresseoversettelsen og videresender pakken som IPv4.

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

VPN-serveren mottar en normal IPv4-tilkobling fra leverandørens oversatte adresse. Den trenger ikke DS-Lite-modus, en spesiell port eller kunnskap om at kundens aksessnett bare er IPv6. Det er denne delen folk går glipp av: den fjerne enden kan ikke se det.

Klientens egen konfigurasjon er like vanlig. Den trenger en fungerende IPv4-rute til serveren, som B4 og AFTR gir, og den trenger at serverens vertsnavn løses til en IPv4-adresse.

Hvorfor innkommende hosting er tilfellet som feiler

Å kjøre en IPv4 VPN-server hjemme er designet som kolliderer med leverandørens delte adressering. Leverandørens oversetter eier den offentlige adressen og mappingtabellen, og den har ingen grunn til å lage en permanent innkommende mapping for én abonnent.

En portforward-regel på hjemmeruteren kan ikke konfigurere AFTR. Regelen er reell og riktig på den lokale enheten, og den endrer ingenting oppstrøms, derfor ser symptomet ut som et brannmurproblem som ikke går bort.

Det er også her oversettelse på operatørnivå skiller seg fra én offentlig adresse: selv en riktig lokal forward kan lande på en adresse som mange abonnenter deler.

Diagnostiser før du endrer aksessplanen

Bekreft først den provisjonerte modusen. Innebygd dobbeltstabel, DS-Lite og et kun-IPv6-nett som bruker en annen oversettelsesmekanisme er tre forskjellige ordninger, og leverandørens markedsføringsnavn samsvarer ikke alltid med det tekniske.

Fastsett deretter fire observasjoner for en utgående feil. Løser klienten VPN-vertsnavnet til en IPv4-destinasjon? Virker vanlig IPv4-tilkobling, i stedet for en nettleserforespørsel som kanskje stille brukte IPv6? Hvilken transport og port prøver klienten, og ser endepunktets logger i det hele tatt det forsøket? Skjer feilen under den innledende utvekslingen, etter en inaktiv periode eller bare ved større overføringer?

Disse fire svarene peker på filtrering, utløp av oversettelsestilstand, et feil endepunkt eller håndtering av pakkestørrelse. Ingen av dem fastslås ved å se DS-Lite på kontosiden.

Les leverandørendringer nøye

En kontorendring kan falle sammen med en fungerende tilkobling samtidig som den endrer flere egenskaper på én gang. Noter hvilken egenskap som ble endret, for et nytt pakkenavn er ikke en teknisk forklaring.

Instruksen om å aktivere dobbeltstabel er tvetydig til noen bekrefter hva leverandøren faktisk provisjonerer. Å behandle den som et universelt krav for IPv4 VPN-klienter gjør en antakelse til policy.

Hvis det reelle kravet er innkommende IPv4-hosting, diskuter en støttet innkommende ordning, innebygd adressering eller et annet aksessdesign med leverandøren. Hvis kravet er en bærbar PC som når en ekstern server, spør i stedet om nettopp den utgående strømmen. Arbeidsrekkefølge: navngi retningen, bekreft den provisjonerte modusen, test vanlig IPv4 og én transport, og endre aksessplanen bare hvis retningen faktisk krever det.