DS-Lite er en måde at give en kunde IPv4-forbindelse over et adgangsnetværk, der kun bærer IPv6. Hjemmeruteren har ikke sin egen dedikerede offentlige IPv4-adresse, og den ene kendsgerning får folk til at tro, at en IPv4 VPN ikke kan fungere fra den forbindelse. Udgående virker det normalt fint. Forbindelsen oversættes af udbyderen, og den fjerne ende ser en almindelig IPv4-klient. Det, der bryder, er den modsatte retning: at hoste noget, der forventer uopfordret indgående IPv4. Forskellen er, hvilken ende der starter samtalen.

Hvilken ende starter forbindelsen

En klient, der starter en forbindelse, opretter oversættelsestilstand undervejs. Udbyderens oversætter ser den første pakke, tildeler en mapping og videresender den. Returtrafik matcher den mapping, fordi mappingen allerede findes.

En server, der venter på forbindelser, har ingen sådan tilstand at oprette. Nogen udefra skal nå en adresse og en port, som udbyderen ikke har accepteret at mappe, og det er en helt anden anmodning.

Følg en udgående anmodning

Arkitekturen i RFC 6333 navngiver begge ender. Elementet på kundesiden er B4, som indkapsler IPv4 i IPv6. Elementet på udbyderens side er AFTR, som udfører adresseoversættelsen 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 modtager en normal IPv4-forbindelse fra udbyderens oversatte adresse. Den har ikke brug for en DS-Lite-tilstand, en særlig port eller nogen bevidsthed om, at kundens adgangsnetværk kun er IPv6. Det er den del, folk overser: den fjerne ende kan ikke se det.

Klientens egen konfiguration er lige så almindelig. Den har brug for en fungerende IPv4-rute til serveren, som B4 og AFTR leverer, og den har brug for, at serverens værtsnavn opløses til en IPv4-adresse.

Hvorfor indgående hosting er det tilfælde, der fejler

At køre en IPv4 VPN-server derhjemme er det design, der kolliderer med udbyderens delte adressering. Udbyderens oversætter ejer den offentlige adresse og mappingtabellen og har ingen grund til at oprette en permanent indgående mapping for én abonnent.

En portforward-regel på hjemmeruteren kan ikke konfigurere AFTR. Reglen er reel og korrekt på den lokale enhed, og den ændrer intet opstrøms, og derfor ligner symptomet et firewallproblem, der ikke vil forsvinde.

Det er også her, oversættelse på operatørniveau adskiller sig fra én offentlig adresse: selv en korrekt lokal forward kan lande på en adresse, som mange abonnenter deler.

Diagnostiser, før du ændrer adgangsplanen

Bekræft først den provisionerede tilstand. Indbygget dobbeltstak, DS-Lite og et IPv6-only-netværk, der bruger en anden oversættelsesmekanisme, er tre forskellige arrangementer, og udbyderens marketingnavne matcher ikke altid det tekniske.

Fastlæg derefter fire observationer for en udgående fejl. Opløser klienten VPN-værtsnavnet til en IPv4-destination? Virker almindelig IPv4-forbindelse, i stedet for en browseranmodning, som måske stille har brugt IPv6? Hvilken transport og port forsøger klienten, og ser slutpunktets logfiler overhovedet forsøget? Sker fejlen under den indledende udveksling, efter en inaktiv periode eller kun ved større overførsler?

De fire svar peger på filtrering, udløb af oversættelsestilstand, et forkert slutpunkt eller håndtering af pakkestørrelse. Intet af det fastslås ved at se DS-Lite på kontosiden.

Læs udbyderændringer omhyggeligt

En kontoændring kan falde sammen med en fungerende forbindelse og samtidig ændre flere egenskaber på én gang. Noter, hvilken egenskab der blev ændret, for et nyt pakkenavn er ikke en teknisk forklaring.

En instruktion om at aktivere dobbeltstak er tvetydig, indtil nogen bekræfter, hvad udbyderen faktisk leverer. At behandle den som et universelt krav til IPv4 VPN-klienter gør en formodning til politik.

Hvis det reelle krav er indgående IPv4-hosting, så drøft en understøttet indgående ordning, indbygget adressering eller et andet adgangsdesign med udbyderen. Hvis kravet er en bærbar computer, der når en fjernserver, så spørg i stedet om netop den udgående strøm. Arbejdsrækkefølge: navngiv retningen, bekræft den provisionerede tilstand, test almindelig IPv4 og én transport, og ændr kun adgangsplanen, hvis retningen faktisk kræver det.

Relaterede artikler