DS-Lite blokeerib sissetuleva IPv4-hostimise, mitte väljamineva VPN-i

Tõlke olek järgib seda poolt, mis ühenduse algatab. Jälgige väljaminevat päringut läbi B4 ja AFTR ning vaadake, miks hostimine seevastu ebaõnnestub.

DS-Lite on viis anda kliendile IPv4-ühendus juurdepääsuvõrgu kaudu, mis edastab ainult IPv6. Koduruuteril ei ole omaette spetsiaalset avalikku IPv4-aadressi ja see üks tõsiasi veenab inimesi, et IPv4 VPN ei saa sellest ühendusest töötada. Väljaminevas suunas töötab see tavaliselt hästi. Ühenduse tõlgib teenusepakkuja ja kaugpool näeb tavalist IPv4-klienti. Katki läheb vastassuund: hostida midagi, mis ootab soovimata sissetulevat IPv4-t. Erinevus on selles, milline pool vestluse algatab.

Milline pool ühenduse algatab

Ühenduse algatav klient loob tõlkeoleku jooksvalt. Teenusepakkuja tõlkija näeb esimest paketti, eraldab vastenduse ja edastab selle. Tagastuv liiklus sobib selle vastendusega, sest vastendus on juba olemas.

Ühendusi ootaval serveril ei ole sellist olekut, mida luua. Keegi väljastpoolt peab jõudma aadressi ja pordini, mida teenusepakkuja ei ole nõustunud vastendama, ja see on hoopis teine päring.

Jälgige väljaminevat päringut

Arhitektuur RFC 6333 nimetab mõlemat otsa. Kliendi poolel on element B4, mis kapseldab IPv4 IPv6 sisse. Teenusepakkuja poolel on element AFTR, mis teeb aadressitõlke ja edastab paketi IPv4-na.

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

VPN-server saab tavalise IPv4-ühenduse teenusepakkuja tõlgitud aadressilt. See ei vaja DS-Lite režiimi, spetsiaalset porti ega teadmist, et kliendi juurdepääsuvõrk on ainult IPv6. Just seda inimesed mööda vaatavad: kaugpool ei saa seda teada.

Kliendi enda seadistus on sama tavaline. See vajab töötavat IPv4-teed serverini, mille B4 ja AFTR tagavad, ning serveri hostinime lahendamist IPv4-aadressiks.

Miks sissetulev hostimine on see juhtum, mis ebaõnnestub

IPv4 VPN-serveri käitamine kodus on lahendus, mis põrkub kokku teenusepakkuja jagatud adresseerimisega. Teenusepakkuja tõlkijale kuuluvad avalik aadress ja vastendustabel ning tal ei ole põhjust luua ühele abonendile püsivat sissetulevat vastendust.

Koduruuteri pordiedastusreegel ei saa AFTR-i seadistada. Reegel on kohalikus seadmes tõeline ja õige ning see ei muuda ülesvoolu midagi, seepärast näeb sümptom välja nagu tulemüüriprobleem, mis ei kao.

Siin erineb operaatori tasandi tõlge ka ühest avalikust aadressist: isegi õige kohalik edastus võib maanduda aadressile, mida jagavad paljud abonendid.

Diagnoosige enne juurdepääsuplaani muutmist

Kinnitage kõigepealt provisioneeritud režiim. Loomulik kahekordne virn, DS-Lite ja ainult IPv6 võrk, mis kasutab teist tõlkemehhanismi, on kolm erinevat lahendust ning teenusepakkuja turundusnimed ei vasta alati tehnilisele.

Seejärel tuvastage väljamineva tõrke jaoks neli vaatlust. Kas klient lahendab VPN-i hostinime IPv4-sihtkohaks? Kas tavaline IPv4-ühendus töötab, mitte brauseripäring, mis võis vaikselt IPv6-te kasutada? Millist transporti ja porti klient proovib ning kas lõpp-punkti logid näevad seda katset üldse? Kas tõrge tekib algses vahetuses, pärast jõudeperioodi või ainult suuremate edastuste puhul?

Need neli vastust viitavad filtreerimisele, tõlkeoleku aegumisele, vale lõpp-punktile või paketi suuruse käsitlemisele. Ükski neist ei ole tuvastatav sellega, et näete kontolehel DS-Lite'i.

Lugege teenusepakkuja muudatusi hoolikalt

Konto muudatus võib langeda kokku töötava ühendusega, muutes korraga mitut omadust. Kirjutage üles, milline omadus muutus, sest uus paketinimi ei ole tehniline selgitus.

Juhis lubada kahekordne virn on mitmetähenduslik seni, kuni keegi kinnitab, mida teenusepakkuja tegelikult pakub. Selle käsitlemine universaalse nõudena IPv4 VPN-klientidele muudab oletuse poliitikaks.

Kui tegelik nõue on sissetulev IPv4-hostimine, arutage teenusepakkujaga toetatud sissetulevat lahendust, loomulikku adresseerimist või muud juurdepääsukujundust. Kui nõue on sülearvuti, mis jõuab kaugserverisse, küsige hoopis selle täpse väljamineva voo kohta. Töö järjekord: nimetage suund, kinnitage provisioneeritud režiim, testige tavalist IPv4-t ja üht transporti ning muutke juurdepääsuplaani ainult siis, kui suund seda tõesti nõuab.

Seotud artiklid