Connessione solo IPv6, servizio IPv4: lasciate che un proxy SOCKS faccia da ponte

Non serve un indirizzo della famiglia di destinazione per raggiungerla, purché qualcosa lungo il percorso sia disposto a inoltrare. L'applicazione si connette al proxy, e il proxy apre una seconda connessione verso la destinazione. Sono due socket con famiglie di indirizzi indipendenti, e nulla in nessuno dei due protocolli richiede che coincidano. È inoltro a livello applicativo, non un percorso IPv4 nativo, e la distinzione decide cosa funzionerà e cosa no. Confondere le due cose è il modo in cui un portatile finisce descritto come dotato di connettività IPv4 quando tutto ciò che ha è un proxy.

Due socket, due famiglie di indirizzi

Una richiesta SOCKS5 nomina la destinazione in una di tre forme: un indirizzo v4 letterale, un indirizzo v6 letterale o un nome che il proxy deve risolvere. La richiesta descrive dove il proxy deve connettersi, non come appare la connessione client-proxy.

Leggete questi tipi di indirizzo come tre scelte indipendenti all'interno di un unico messaggio. Un proxy raggiungibile via IPv6 può aprire un socket di destinazione IPv4 ogni volta che dispone di un'uscita IPv4 funzionante e la sua politica consente la richiesta. La specifica SOCKS5 li definisce senza alcun riferimento al trasporto del client.

Un esempio SSH controllato

Prendete un host SSH che siete autorizzati a usare, che risponde su IPv6 e può esso stesso raggiungere un servizio HTTPS esistente solo su v4. Il forwarding dinamico di OpenSSH colloca un listener SOCKS locale sulla vostra macchina mentre la sessione di accesso passa su v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

L'host e l'account sopra sono esempi, e il binding loopback mantiene il listener su questo computer. Non sostituitelo con un binding wildcard affinché un ufficio possa condividere un proxy non autenticato. ExitOnForwardFailure=yes esiste perché un forwarding fallito termini la sessione invece di lasciare un comando silenzioso in esecuzione in background.

Con la sessione attiva, la richiesta appare così:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

La connessione loopback non è un percorso Internet IPv4. Ciò che esce dalla vostra macchina è la sessione di accesso su v6, ed è il lato remoto ad aprire il socket di destinazione. La forma socks5h delega anche la risoluzione dei nomi a quel lato, cosa che conta quando il client non ha un proprio percorso di risoluzione IPv4.

Cosa vede davvero la destinazione

La destinazione vede l'indirizzo di uscita dell'inoltro. Nessun indirizzo appartenente al vostro portatile appare lì. Una lista di autorizzazione delle origini su quel servizio deve nominare l'inoltro. Anche i suoi log attribuiranno il traffico all'inoltro. Scrivetelo nel registro delle modifiche prima dell'audit, perché una lista di autorizzazione costruita attorno agli indirizzi dei client fallisce alla prima richiesta.

L'inoltro è anche il luogo in cui sono visibili le due metà della conversazione, il che è una proprietà utile durante la diagnosi e un onere se l'inoltro è condiviso senza politica.

Questo non è DNS64 né NAT64

DNS64 risponde con record sintetizzati che sostituiscono le destinazioni v4, e NAT64 riscrive i pacchetti lungo un percorso configurato. Nessuno dei due descrive ciò che accade qui, dove una conversazione di trasporto finisce e un'altra inizia e nessun indirizzo sintetizzato spiega il risultato. Una richiesta riuscita quindi non dice nulla su quali servizi di traduzione gestisce il vostro provider, e il proxy può eseguire NAT ordinario sulla propria uscita.

Entrambi i meccanismi possono esistere nella stessa rete, quindi descrivete quello che avete effettivamente verificato invece di quello che suona più vicino.

Conoscete l'ambito prima di prometterlo

Il forwarding dinamico di OpenSSH trasporta connessioni TCP, non traffico IP arbitrario, quindi UDP, ICMP e qualsiasi protocollo che ignora il proxy necessitano di un diverso progetto supportato. Mantenete la verifica della chiave host SSH, le restrizioni di forwarding del server e la validazione del certificato HTTPS, perché il proxy è un partecipante fidato aggiuntivo, non una ragione per indebolire i controlli di identità. Se l'obiettivo è portare il trasporto esterno di una VPN attraverso il proxy, verificate che entrambe le estremità supportino quel trasporto invece di presumere che qualsiasi listener SOCKS possa inoltrarlo.

Niente di tutto questo rende il client dual-stack, e niente di tutto ciò è necessario. Fa sì che un'applicazione raggiunga un servizio attraverso un inoltro, che è un'affermazione più piccola e molto più facile da verificare.