DS-Lite blochează găzduirea IPv4 de intrare, nu VPN-ul de ieșire

DS-Lite este o modalitate de a da unui client conectivitate IPv4 printr-o rețea de acces care transportă doar IPv6. Routerul de acasă nu are o adresă IPv4 publică dedicată proprie, iar acest singur fapt convinge oamenii că un VPN IPv4 nu poate funcționa de pe acea conexiune. În direcția de ieșire, de obicei funcționează bine. Conexiunea este tradusă de furnizor, iar capătul îndepărtat vede un client IPv4 obișnuit. Ce se strică este direcția opusă: găzduirea a ceva care așteaptă IPv4 de intrare nesolicitat. Distincția este care capăt începe conversația.

Care capăt începe conexiunea

Un client care inițiază o conexiune creează stare de traducere pe parcurs. Traducătorul furnizorului vede primul pachet, alocă o mapare și îl redirecționează. Traficul de retur corespunde acelei mapări pentru că maparea există deja.

Un server care așteaptă conexiuni nu are o astfel de stare de creat. Cineva din exterior trebuie să ajungă la o adresă și un port pe care furnizorul nu a fost de acord să le mapeze, iar aceasta este o cerere complet diferită.

Urmați o cerere de ieșire

Arhitectura din RFC 6333 numește ambele capete. Elementul din partea clientului este B4, care încapsulează IPv4 în IPv6. Elementul din partea furnizorului este AFTR, care efectuează traducerea adresei și redirecționează pachetul ca IPv4.

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

Serverul VPN primește o conexiune IPv4 normală de la adresa tradusă a furnizorului. Nu are nevoie de un mod DS-Lite, de un port special sau de conștientizarea că rețeaua de acces a clientului este doar IPv6. Aceasta este partea pe care oamenii o ratează: capătul îndepărtat nu poate afla.

Configurația clientului însuși este la fel de obișnuită. Are nevoie de o cale IPv4 funcțională către server, pe care B4 și AFTR o oferă, și de faptul ca numele de gazdă al serverului să se rezolve într-o adresă IPv4.

De ce găzduirea de intrare este cazul care eșuează

Rularea unui server VPN IPv4 acasă este proiectul care se ciocnește de adresarea partajată a furnizorului. Traducătorul furnizorului deține adresa publică și tabelul de mapare și nu are niciun motiv să creeze o mapare de intrare permanentă pentru un singur abonat.

O regulă de redirecționare a portului pe routerul de acasă nu poate configura AFTR. Regula este reală și corectă pe dispozitivul local și nu schimbă nimic în amonte, de aceea simptomul arată ca o problemă de firewall care nu dispare.

Aici traducerea la nivel de operator diferă și ea de o singură adresă publică: chiar și o redirecționare locală corectă poate ajunge pe o adresă partajată de mulți abonați.

Diagnosticați înainte de a schimba planul de acces

Confirmați mai întâi modul provizionat. Stiva dublă nativă, DS-Lite și o rețea doar IPv6 care folosește alt mecanism de traducere sunt trei aranjamente diferite, iar numele de marketing ale furnizorului nu corespund întotdeauna celui tehnic.

Apoi stabiliți patru observații pentru o defecțiune de ieșire. Clientul rezolvă numele de gazdă al VPN într-o destinație IPv4? Funcționează conectivitatea IPv4 simplă, în locul unei cereri din browser care poate a folosit în tăcere IPv6? Ce transport și ce port încearcă clientul, și jurnalele punctului final văd măcar acea încercare? Defecțiunea apare în timpul schimbului inițial, după o perioadă de inactivitate sau doar la transferuri mai mari?

Cele patru răspunsuri indică filtrarea, expirarea stării de traducere, un punct final greșit sau tratarea dimensiunii pachetului. Niciunul nu este stabilit văzând DS-Lite pe pagina contului.

Citiți cu atenție modificările furnizorului

O modificare a contului poate coincide cu o conexiune funcțională modificând în același timp mai multe proprietăți. Notați ce proprietate s-a schimbat, pentru că un nume nou de pachet nu este o explicație tehnică.

Instrucțiunea de a activa stiva dublă este ambiguă până când cineva confirmă ce provizionează furnizorul de fapt. Tratarea ei ca cerință universală pentru clienții VPN IPv4 transformă o presupunere în politică.

Dacă cerința reală este găzduirea IPv4 de intrare, discutați cu furnizorul un aranjament de intrare acceptat, adresare nativă sau alt proiect de acces. Dacă cerința este un laptop care ajunge la un server îndepărtat, întrebați în schimb despre acel flux de ieșire exact. Ordinea lucrului: numiți direcția, confirmați modul provizionat, testați IPv4 simplu și un transport, apoi schimbați planul de acces doar dacă direcția o cere cu adevărat.