A DS-Lite a bejövő IPv4-tárhelyezést blokkolja, nem a kimenő VPN-t

A DS-Lite egy mód arra, hogy egy ügyfél IPv4-kapcsolatot kapjon olyan hozzáférési hálózaton, amely csak IPv6-ot szállít. Az otthoni routernek nincs saját dedikált nyilvános IPv4-címe, és ez az egyetlen tény győzi meg az embereket arról, hogy egy IPv4-es VPN nem működhet erről a kapcsolatról. Kimenő irányban általában jól működik. A kapcsolatot a szolgáltató fordítja, és a távoli vég egy közönséges IPv4-ügyfelet lát. Ami elromlik, az az ellenkező irány: olyasmit tárhelyezni, amely kéretlen bejövő IPv4-re számít. A különbség az, melyik vég kezdi a beszélgetést.

Melyik vég kezdi a kapcsolatot

A kapcsolatot kezdeményező ügyfél menet közben fordítási állapotot hoz létre. A szolgáltató fordítója látja az első csomagot, lefoglal egy leképezést, és továbbítja. A visszatérő forgalom ehhez a leképezéshez illeszkedik, mert a leképezés már létezik.

Egy kapcsolatokra váró kiszolgálónak nincs ilyen állapota, amit létrehozna. Kívülről valakinek el kell érnie egy címet és portot, amelynek leképezéséhez a szolgáltató nem járult hozzá, és ez teljesen más kérés.

Kövessen végig egy kimenő kérést

A architektúra a RFC 6333 mindkét végét megnevezi. Az ügyfél oldali elem a B4, amely IPv4-et csomagol IPv6-ba. A szolgáltató oldali elem az AFTR, amely elvégzi a címfordítást, és IPv4-ként továbbítja a csomagot.

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

A VPN-kiszolgáló normál IPv4-kapcsolatot kap a szolgáltató fordított címéről. Nincs szüksége DS-Lite-módra, különleges portra vagy annak tudatára, hogy az ügyfél hozzáférési hálózata csak IPv6. Ezt szokták kihagyni: a távoli vég nem tudhatja.

Az ügyfél saját konfigurációja ugyanilyen közönséges. Szüksége van egy működő IPv4-útvonalra a kiszolgáló felé, amelyet a B4 és az AFTR biztosít, és arra, hogy a kiszolgáló gazdaneve IPv4-címmé oldódjon fel.

Miért a bejövő tárhelyezés az eset, amely meghiúsul

IPv4-es VPN-kiszolgálót futtatni otthon az a kialakítás, amely ütközik a szolgáltató megosztott címzésével. A szolgáltató fordítója birtokolja a nyilvános címet és a leképezési táblát, és nincs oka állandó bejövő leképezést létrehozni egyetlen előfizető számára.

Az otthoni router porttovábbítási szabálya nem tudja konfigurálni az AFTR-t. A szabály valós és helyes a helyi eszközön, és semmit nem változtat felfelé, ezért a tünet olyan tűzfalproblémának tűnik, amely nem múlik el.

Itt különbözik a szolgáltatói szintű fordítás az egyetlen nyilvános címtől is: még egy helyes helyi továbbítás is olyan címre kerülhet, amelyet sok előfizető megoszt.

Diagnosztizáljon, mielőtt a hozzáférési tervet megváltoztatja

Először erősítse meg a kiépített módot. A natív kettős verem, a DS-Lite és egy másik fordítási mechanizmust használó csak-IPv6 hálózat három különböző elrendezés, és a szolgáltató marketingnevei nem mindig egyeznek a technikaival.

Ezután állapítson meg négy megfigyelést egy kimenő hiba esetére. Feloldja-e az ügyfél a VPN gazdanevét IPv4-célpontra? Működik-e a sima IPv4-kapcsolat, nem pedig egy böngészőkérés, amely esetleg csendben IPv6-ot használt? Melyik átvitelt és portot próbálja az ügyfél, és látják-e a végpont naplói egyáltalán ezt a kísérletet? A hiba a kezdeti eszmecsere alatt, tétlenségi időszak után vagy csak nagyobb átviteleknél jelentkezik?

Ez a négy válasz a szűrésre, a fordítási állapot lejártára, egy rossz végpontra vagy a csomagméret kezelésére mutat. Egyiket sem bizonyítja az, hogy a fiókoldalon DS-Lite látható.

Olvassa figyelmesen a szolgáltató változásait

Egy fiókváltozás egybeeshet egy működő kapcsolattal, miközben egyszerre több tulajdonságot is módosít. Jegyezze fel, melyik tulajdonság változott, mert egy új csomagnév nem technikai magyarázat.

A kettős verem engedélyezésére vonatkozó utasítás addig kétértelmű, amíg valaki meg nem erősíti, mit is épít ki valójában a szolgáltató. Univerzális követelményként kezelni az IPv4-es VPN-ügyfelek számára a találgatást szabályzattá teszi.

Ha a valódi követelmény a bejövő IPv4-tárhelyezés, beszéljen a szolgáltatóval egy támogatott bejövő elrendezésről, natív címzésről vagy más hozzáférési kialakításról. Ha a követelmény egy távoli kiszolgálót elérő laptop, akkor inkább arról a pontos kimenő folyamról kérdezzen. A munka sorrendje: nevezze meg az irányt, erősítse meg a kiépített módot, tesztelje a sima IPv4-et és egy átvitelt, és csak akkor változtassa meg a hozzáférési tervet, ha az irány valóban megkívánja.