DS-Lite blokkeert inkomende IPv4-hosting, niet uitgaande VPN

DS-Lite is een manier om een klant IPv4-connectiviteit te geven over een toegangsnetwerk dat alleen IPv6 draagt. De thuisrouter heeft geen eigen toegewezen openbaar IPv4-adres, en dat enkele feit overtuigt mensen ervan dat een IPv4-VPN niet kan werken vanaf die verbinding. Uitgaand werkt het meestal prima. De verbinding wordt door de provider vertaald, en de andere kant ziet een gewone IPv4-client. Wat breekt, is de tegenovergestelde richting: iets hosten dat ongevraagd inkomende IPv4 verwacht. Het verschil is welke kant het gesprek begint.

Welke kant begint de verbinding

Een client die een verbinding start, maakt gaandeweg vertaalstatus aan. De vertaler van de provider ziet het eerste pakket, wijst een mapping toe en stuurt het door. Retourverkeer past bij die mapping omdat de mapping al bestaat.

Een server die op verbindingen wacht, heeft geen dergelijke status om aan te maken. Iemand van buitenaf moet een adres en een poort bereiken die de provider niet heeft toegezegd te mappen, en dat is een heel ander verzoek.

Volg een uitgaand verzoek

De architectuur in RFC 6333 noemt beide uiteinden. Het element aan de klantzijde is de B4, die IPv4 inkapselt in IPv6. Het element aan de providerzijde is de AFTR, die de adresvertaling uitvoert en het pakket als IPv4 doorstuurt.

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

De VPN-server ontvangt een normale IPv4-verbinding van het vertaalde adres van de provider. Hij heeft geen DS-Lite-modus, geen speciale poort en geen kennis nodig dat het toegangsnetwerk van de klant alleen IPv6 is. Dat is het deel dat mensen missen: de andere kant kan het niet zien.

De configuratie van de client zelf is even gewoon. Hij heeft een werkend IPv4-pad naar de server nodig, dat B4 en AFTR bieden, en hij heeft nodig dat de hostnaam van de server naar een IPv4-adres wordt omgezet.

Waarom inkomende hosting het geval is dat mislukt

Een IPv4-VPN-server thuis draaien is het ontwerp dat botst met de gedeelde adressering van de provider. De vertaler van de provider bezit het openbare adres en de mappingtabel, en heeft geen reden om een permanente inkomende mapping voor één abonnee aan te maken.

Een portforward-regel op de thuisrouter kan de AFTR niet configureren. De regel is echt en correct op het lokale apparaat, en verandert niets stroomopwaarts, waardoor het symptoom op een firewallprobleem lijkt dat niet weggaat.

Hier verschilt vertaling op operatorniveau ook van één openbaar adres: zelfs een correcte lokale forward kan landen op een adres dat veel abonnees delen.

Diagnosticeer voordat u het toegangsplan wijzigt

Bevestig eerst de ingerichte modus. Native dual stack, DS-Lite en een alleen-IPv6-netwerk met een ander vertaalmechanisme zijn drie verschillende opstellingen, en de marketingnamen van de provider komen niet altijd overeen met de technische.

Stel daarna vier observaties vast voor een uitgaande storing. Lost de client de VPN-hostnaam op naar een IPv4-bestemming? Werkt gewone IPv4-connectiviteit, in plaats van een browserverzoek dat misschien stilletjes IPv6 heeft gebruikt? Welk transport en welke poort probeert de client, en zien de logs van het eindpunt die poging überhaupt? Treedt de storing op tijdens de eerste uitwisseling, na een periode van inactiviteit of alleen bij grotere overdrachten?

Die vier antwoorden wijzen op filtering, het verlopen van vertaalstatus, een verkeerd eindpunt of de omgang met pakketgrootte. Geen daarvan wordt vastgesteld door DS-Lite op de accountpagina te zien.

Lees wijzigingen van de provider zorgvuldig

Een accountwijziging kan samenvallen met een werkende verbinding terwijl hij meerdere eigenschappen tegelijk aanpast. Noteer welke eigenschap is gewijzigd, want een nieuwe pakketnaam is geen technische verklaring.

De instructie om dual stack in te schakelen is dubbelzinnig tot iemand bevestigt wat de provider werkelijk inricht. Die als universele eis voor IPv4-VPN-clients behandelen maakt van een vermoeden beleid.

Als de werkelijke eis inkomende IPv4-hosting is, bespreek dan met de provider een ondersteunde inkomende opstelling, native adressering of een ander toegangsontwerp. Als de eis een laptop is die een externe server bereikt, vraag dan in plaats daarvan naar precies die uitgaande stroom. Werkvolgorde: benoem de richting, bevestig de ingerichte modus, test gewone IPv4 en één transport, en wijzig het toegangsplan alleen als de richting dat echt vereist.