DS-Lite blocca l’hosting IPv4 in ingresso, non la VPN in uscita

DS-Lite è un modo per dare a un cliente connettività IPv4 su una rete di accesso che trasporta solo IPv6. Il router di casa non ha un proprio indirizzo IPv4 pubblico dedicato, e questo unico fatto convince le persone che una VPN IPv4 non possa funzionare da quella connessione. In uscita di solito funziona bene. La connessione viene tradotta dal provider, e l’estremo remoto vede un normale client IPv4. Quello che si rompe è la direzione opposta: ospitare qualcosa che si aspetta IPv4 in ingresso non richiesto. La distinzione è quale lato inizia la conversazione.

Quale lato inizia la connessione

Un client che avvia una connessione crea stato di traduzione man mano che procede. Il traduttore del provider vede il primo pacchetto, assegna una mappatura e lo inoltra. Il traffico di ritorno corrisponde a quella mappatura perché la mappatura esiste già.

Un server che attende connessioni non ha uno stato del genere da creare. Qualcuno dall’esterno deve raggiungere un indirizzo e una porta che il provider non ha accettato di mappare, e questa è una richiesta del tutto diversa.

Segui una richiesta in uscita

L’architettura nella RFC 6333 nomina entrambi gli estremi. L’elemento lato cliente è il B4, che incapsula IPv4 in IPv6. L’elemento lato provider è l’AFTR, che esegue la traduzione degli indirizzi e inoltra il pacchetto come IPv4.

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

Il server VPN riceve una normale connessione IPv4 dall’indirizzo tradotto del provider. Non ha bisogno di una modalità DS-Lite, di una porta speciale o di sapere che la rete di accesso del cliente è solo IPv6. È questa la parte che le persone trascurano: l’estremo remoto non può accorgersene.

La configurazione del client stesso è altrettanto ordinaria. Serve un percorso IPv4 funzionante verso il server, che B4 e AFTR forniscono, e serve che il nome host del server si risolva in un indirizzo IPv4.

Perché l’hosting in ingresso è il caso che fallisce

Eseguire un server VPN IPv4 a casa è il progetto che si scontra con l’indirizzamento condiviso del provider. Il traduttore del provider possiede l’indirizzo pubblico e la tabella di mappatura, e non ha motivo di creare una mappatura in ingresso permanente per un solo abbonato.

Una regola di port forwarding sul router di casa non può configurare l’AFTR. La regola è reale e corretta sul dispositivo locale, e non cambia nulla a monte, per questo il sintomo sembra un problema di firewall che non se ne va.

Qui è anche dove la traduzione a livello di operatore differisce da un singolo indirizzo pubblico: persino un forward locale corretto può finire su un indirizzo condiviso da molti abbonati.

Diagnostica prima di cambiare il piano di accesso

Per prima cosa conferma la modalità provisionata. Il doppio stack nativo, DS-Lite e una rete solo IPv6 che usa un altro meccanismo di traduzione sono tre disposizioni diverse, e i nomi commerciali del provider non sempre corrispondono a quello tecnico.

Poi stabilisci quattro osservazioni per un guasto in uscita. Il client risolve il nome host della VPN in una destinazione IPv4? Funziona la connettività IPv4 semplice, invece di una richiesta del browser che forse ha usato IPv6 in silenzio? Quale trasporto e quale porta tenta il client, e i log dell’endpoint vedono quel tentativo? Il guasto avviene durante lo scambio iniziale, dopo un periodo di inattività o solo su trasferimenti più grandi?

Queste quattro risposte indicano filtraggio, scadenza dello stato di traduzione, un endpoint sbagliato o la gestione della dimensione dei pacchetti. Nessuna di esse si stabilisce vedendo DS-Lite nella pagina dell’account.

Leggi con attenzione i cambiamenti del provider

Un cambiamento dell’account può coincidere con una connessione funzionante mentre altera più proprietà insieme. Annota quale proprietà è cambiata, perché un nuovo nome di pacchetto non è una spiegazione tecnica.

L’istruzione di attivare il doppio stack resta ambigua finché qualcuno non conferma che cosa il provider provisioni davvero. Trattarla come un requisito universale per i client VPN IPv4 trasforma un’ipotesi in politica.

Se il requisito reale è l’hosting IPv4 in ingresso, parla con il provider di una disposizione in ingresso supportata, di indirizzamento nativo o di un altro progetto di accesso. Se il requisito è un portatile che raggiunge un server remoto, chiedi invece di quello specifico flusso in uscita. Ordine del lavoro: nomina la direzione, conferma la modalità provisionata, prova IPv4 semplice e un trasporto, poi cambia il piano di accesso solo se la direzione lo richiede davvero.