DS-Lite blockerar inkommande IPv4-hosting, inte utgående VPN

DS-Lite är ett sätt att ge en kund IPv4-anslutning över ett accessnät som bara bär IPv6. Hemroutern har ingen egen dedikerad offentlig IPv4-adress, och det enda faktumet övertygar människor om att ett IPv4-VPN inte kan fungera från den anslutningen. Utgående fungerar det oftast bra. Anslutningen översätts av leverantören, och den bortre änden ser en vanlig IPv4-klient. Det som går sönder är motsatt riktning: att vara värd för något som väntar sig oombedd inkommande IPv4. Skillnaden är vilken ände som inleder samtalet.

Vilken ände som inleder anslutningen

En klient som inleder en anslutning skapar översättningstillstånd efter hand. Leverantörens översättare ser det första paketet, tilldelar en mappning och vidarebefordrar det. Returtrafik matchar den mappningen eftersom mappningen redan finns.

En server som väntar på anslutningar har inget sådant tillstånd att skapa. Någon utifrån måste nå en adress och en port som leverantören inte har gått med på att mappa, och det är en helt annan begäran.

Följ en utgående begäran

Arkitekturen i RFC 6333 namnger båda ändarna. Elementet på kundsidan är B4, som kapslar in IPv4 i IPv6. Elementet på leverantörssidan är AFTR, som utför adressöversättningen och vidarebefordrar paketet som IPv4.

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

VPN-servern tar emot en normal IPv4-anslutning från leverantörens översatta adress. Den behöver inget DS-Lite-läge, ingen särskild port och ingen kännedom om att kundens accessnät bara är IPv6. Det är den delen folk missar: den bortre änden kan inte upptäcka det.

Klientens egen konfiguration är lika vanlig. Den behöver en fungerande IPv4-väg till servern, som B4 och AFTR tillhandahåller, och den behöver att serverns värdnamn löses upp till en IPv4-adress.

Varför inkommande hosting är fallet som misslyckas

Att köra en IPv4 VPN-server hemma är den design som kolliderar med leverantörens delade adressering. Leverantörens översättare äger den offentliga adressen och mappningstabellen och har ingen anledning att skapa en permanent inkommande mappning för en enda abonnent.

En portvidarebefordringsregel på hemroutern kan inte konfigurera AFTR. Regeln är verklig och korrekt på den lokala enheten, och den ändrar ingenting uppströms, vilket är varför symtomet ser ut som ett brandväggsproblem som inte försvinner.

Det är också här översättning på operatörsnivå skiljer sig från en enda offentlig adress: även en korrekt lokal vidarebefordran kan hamna på en adress som många abonnenter delar.

Diagnostisera innan du ändrar åtkomstplanen

Bekräfta först det etablerade läget. Inbyggd dubbel stack, DS-Lite och ett nät med bara IPv6 som använder en annan översättningsmekanism är tre olika arrangemang, och leverantörens marknadsföringsnamn stämmer inte alltid med det tekniska.

Fastställ sedan fyra observationer för ett utgående fel. Löser klienten VPN-värdnamnet till en IPv4-destination? Fungerar vanlig IPv4-anslutning, i stället för en webbläsarbegäran som kanske tyst använde IPv6? Vilket transport och vilken port försöker klienten, och ser slutpunktens loggar över huvud taget det försöket? Sker felet under det inledande utbytet, efter en inaktivitetsperiod eller bara vid större överföringar?

De fyra svaren pekar på filtrering, att översättningstillståndet löper ut, en felaktig slutpunkt eller hantering av paketstorlek. Inget av dem fastställs genom att se DS-Lite på kontosidan.

Läs leverantörens ändringar noggrant

En kontoändring kan sammanfalla med en fungerande anslutning samtidigt som den ändrar flera egenskaper på en gång. Anteckna vilken egenskap som ändrades, för ett nytt paketnamn är inte en teknisk förklaring.

Instruktionen att aktivera dubbel stack är tvetydig tills någon bekräftar vad leverantören faktiskt etablerar. Att behandla den som ett universellt krav för IPv4 VPN-klienter gör en gissning till policy.

Om det verkliga kravet är inkommande IPv4-hosting, diskutera en stödd inkommande lösning, inbyggd adressering eller en annan åtkomstddesign med leverantören. Om kravet är en bärbar dator som når en fjärrserver, fråga i stället om just det utgående flödet. Arbetsordning: namnge riktningen, bekräfta det etablerade läget, testa vanlig IPv4 och en transport, och ändra åtkomstplanen bara om riktningen faktiskt kräver det.