DS-Lite blokuje příchozí IPv4 hosting, ne odchozí VPN

DS-Lite je způsob, jak dát zákazníkovi připojení IPv4 přes přístupovou síť, která přenáší jen IPv6. Domácí router nemá vlastní vyhrazenou veřejnou adresu IPv4, a tento jediný fakt lidi přesvědčuje, že IPv4 VPN z takového připojení nemůže fungovat. Odchozím směrem to obvykle funguje dobře. Spojení překládá poskytovatel a vzdálená strana vidí běžného klienta IPv4. Rozbíjí se opačný směr: hosting něčeho, co očekává nevyžádaný příchozí IPv4. Rozdíl je v tom, která strana začne rozhovor.

Která strana spojení zahajuje

Klient, který spojení iniciuje, vytváří stav překladu za pochodu. Překladač poskytovatele vidí první paket, přidělí mapování a předá ho dál. Zpětný provoz odpovídá tomuto mapování, protože mapování už existuje.

Server, který čeká na spojení, nemá takový stav co vytvořit. Někdo zvenku musí dosáhnout adresy a portu, které poskytovatel nesouhlasil mapovat, a to je zcela jiný požadavek.

Projděte odchozí požadavek

Architektura v RFC 6333 pojmenovává oba konce. Prvek na straně zákazníka je B4, který zapouzdřuje IPv4 do IPv6. Prvek na straně poskytovatele je AFTR, který provádí překlad adresy a předává paket jako IPv4.

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

Server VPN dostává běžné spojení IPv4 z přeložené adresy poskytovatele. Nepotřebuje režim DS-Lite, zvláštní port ani povědomí o tom, že přístupová síť zákazníka je jen IPv6. To je část, kterou lidé přehlížejí: vzdálená strana to nemůže poznat.

Vlastní konfigurace klienta je stejně obyčejná. Potřebuje funkční cestu IPv4 k serveru, kterou B4 a AFTR zajišťují, a potřebuje, aby se jméno hostitele serveru přeložilo na adresu IPv4.

Proč je příchozí hosting případ, který selhává

Provozovat IPv4 VPN server doma je návrh, který se sráží se sdíleným adresováním poskytovatele. Překladač poskytovatele vlastní veřejnou adresu i tabulku mapování a nemá důvod vytvářet trvalé příchozí mapování pro jednoho účastníka.

Pravidlo přesměrování portu na domácím routeru nemůže nakonfigurovat AFTR. Pravidlo je na místním zařízení skutečné a správné a výše proti proudu nic nemění, a proto symptom vypadá jako problém brány firewall, který nezmizí.

Zde se také překlad na úrovni operátora liší od jedné veřejné adresy: i správné místní přesměrování může skončit na adrese, kterou sdílí mnoho účastníků.

Diagnostikujte, než změníte plán přístupu

Nejprve potvrďte zřízený režim. Nativní dvojí zásobník, DS-Lite a síť jen s IPv6 používající jiný mechanismus překladu jsou tři různá uspořádání a marketingové názvy poskytovatele ne vždy odpovídají technickému.

Pak stanovte čtyři pozorování pro odchozí selhání. Překládá klient jméno hostitele VPN na cíl IPv4? Funguje prosté připojení IPv4, místo požadavku prohlížeče, který mohl tiše použít IPv6? Který transport a port klient zkouší a vidí protokoly koncového bodu tento pokus vůbec? Dochází k selhání během počáteční výměny, po období nečinnosti, nebo jen u větších přenosů?

Tyto čtyři odpovědi ukazují na filtrování, vypršení stavu překladu, špatný koncový bod nebo zpracování velikosti paketu. Nic z toho se neprokáže tím, že na stránce účtu uvidíte DS-Lite.

Čtěte změny poskytovatele pozorně

Změna účtu se může krýt s funkčním spojením a přitom měnit několik vlastností najednou. Zaznamenejte, která vlastnost se změnila, protože nový název balíčku není technické vysvětlení.

Pokyn zapnout dvojí zásobník je nejednoznačný, dokud někdo nepotvrdí, co poskytovatel skutečně zřizuje. Považovat ho za univerzální požadavek pro klienty IPv4 VPN mění domněnku v politiku.

Pokud je skutečným požadavkem příchozí IPv4 hosting, proberte s poskytovatelem podporované příchozí uspořádání, nativní adresování nebo jiný návrh přístupu. Pokud je požadavkem notebook dosahující na vzdálený server, ptejte se místo toho na přesně tento odchozí tok. Pořadí práce: pojmenujte směr, potvrďte zřízený režim, otestujte prosté IPv4 a jeden transport, a teprve pak měňte plán přístupu, pokud to směr skutečně vyžaduje.