DS-Lite blokkeer inkomende IPv4-hosting, nie uitgaande VPN nie

DS-Lite is ’n manier om aan ’n kliënt IPv4-konnektiwiteit te gee oor ’n toegangsnetwerk wat net IPv6 dra. Die tuisroeteerder het geen toegewyde publieke IPv4-adres van sy eie nie, en daardie enkele feit oortuig mense dat ’n IPv4-VPN nie vanaf daardie verbinding kan werk nie. Uitgaande werk dit gewoonlik goed. Die verbinding word deur die verskaffer vertaal, en die ander kant sien ’n gewone IPv4-kliënt. Wat breek, is die teenoorgestelde rigting: om iets te host wat onversoekte inkomende IPv4 verwag. Die onderskeid is watter kant die gesprek begin.

Watter kant begin die verbinding

’n Kliënt wat ’n verbinding inisieer, skep vertaalingstoestand soos dit vorder. Die verskaffer se vertaler sien die eerste pakkie, ken ’n kartering toe en stuur dit aan. Terugkerende verkeer pas by daardie kartering omdat die kartering reeds bestaan.

’n Bediener wat vir verbindings wag, het geen sulke toestand om te skep nie. Iemand van buite moet ’n adres en ’n poort bereik wat die verskaffer nie ingestem het om te karteer nie, en dit is heeltemal ’n ander versoek.

Volg ’n uitgaande versoek

Die argitektuur in RFC 6333 noem albei kante. Die kliëntkant-element is die B4, wat IPv4 in IPv6 inkapsel. Die verskafferkant-element is die AFTR, wat die adresvertaling doen en die pakkie as IPv4 aanstuur.

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

Die VPN-bediener ontvang ’n normale IPv4-verbinding vanaf die verskaffer se vertaalde adres. Dit het geen DS-Lite-modus, spesiale poort of enige bewustheid nodig dat die kliënt se toegangsnetwerk slegs IPv6 is nie. Dit is die deel wat mense mis: die ander kant kan dit nie sien nie.

Die kliënt se eie konfigurasie is ewe gewoon. Dit benodig ’n werkende IPv4-pad na die bediener, wat die B4 en AFTR verskaf, en dit benodig die bediener se gasheernaam om na ’n IPv4-adres op te los.

Waarom inkomende hosting die geval is wat misluk

Om ’n IPv4-VPN-bediener by die huis te bedryf, is die ontwerp wat bots met gedeelde verskafferadressering. Die verskaffer se vertaler besit die publieke adres en die karteringstabel, en dit het geen rede om ’n permanente inkomende kartering vir een intekenaar te skep nie.

’n Poortaanstuur-reël op die tuisroeteerder kan nie die AFTR konfigureer nie. Die reël is werklik en korrek op die plaaslike toestel, en dit verander niks stroomop nie, en daarom lyk die simptoom soos ’n firewall-probleem wat nie wil weggaan nie.

Dit is ook waar vertaling op diensverskaffervlak van ’n enkele publieke adres verskil: selfs ’n korrekte plaaslike aanstuur kan op ’n adres beland wat baie intekenare deel.

Diagnoseer voordat jy die toegangsplan verander

Bevestig eers die voorsiene modus. Inheemse dubbele stapel, DS-Lite en ’n slegs-IPv6-netwerk met ’n ander vertaalmeganisme is drie verskillende reëlings, en die verskaffer se bemarkingsname stem nie altyd met die tegniese een ooreen nie.

Stel dan vier waarnemings vas vir ’n uitgaande fout. Los die kliënt die VPN-gasheernaam na ’n IPv4-bestemming op? Werk gewone IPv4-konnektiwiteit, eerder as ’n blaaierversoek wat dalk stilweg IPv6 gebruik het? Watter vervoer en poort probeer die kliënt, en sien die eindpunt-logboeke daardie poging hoegenaamd? Gebeur die fout tydens die eerste uitruiling, ná ’n stil periode, of net by groter oordragte?

Daardie vier antwoorde wys op filtering, verstryking van vertaalingstoestand, ’n verkeerde eindpunt of hantering van pakkiemoorde. Nie een daarvan word vasgestel deur DS-Lite op die rekeningblad te sien nie.

Lees verskafferveranderinge noukeurig

’n Rekeningverandering kan saamval met ’n werkende verbinding terwyl dit verskeie eienskappe gelyktydig wysig. Teken aan watter eienskap verander het, want ’n nuwe pakketnaam is nie ’n tegniese verklaring nie.

’n Opdrag om dubbele stapel te aktiveer, is dubbelsinnig totdat iemand bevestig wat die verskaffer werklik voorsien. Om dit as ’n universele vereiste vir IPv4-VPN-kliënte te behandel, maak ’n vermoede ’n beleid.

As die werklike vereiste inkomende IPv4-hosting is, bespreek ’n ondersteunde inkomende reëling, inheemse adressering of ’n ander toegangsontwerp met die verskaffer. As die vereiste ’n skootrekenaar is wat ’n afgeleë bediener bereik, vra eerder oor daardie presiese uitgaande vloei. Orde van werk: benoem die rigting, bevestig die voorsiene modus, toets gewone IPv4 en een vervoer, en verander die toegangsplan net as die rigting dit werklik vereis.