UDP e QUIC tramite proxy

Un proxy può superare una verifica web e non riuscire comunque a trasportare il traffico necessario al programma. Per esempio, un gioco potrebbe effettuare l’accesso attraverso il proxy ma non scambiare gli aggiornamenti della partita. Un sito potrebbe aprirsi normalmente mentre il browser usa HTTP/2 invece di HTTP/3. Queste operazioni usano capacità di rete diverse.

Per la scelta più generale del protocollo, consulta Proxy SOCKS e HTTP. Questo articolo spiega come UDP raggiunge una destinazione attraverso un proxy, che cosa richiede QUIC a quel percorso e come verificare che l’applicazione usi il trasporto e l’IP di uscita previsti.

Che cosa fanno UDP, QUIC e HTTP/3

TCP consegna un flusso ordinato di byte. Se alcuni dati vanno persi, ne organizza la ritrasmissione e trattiene i byte successivi dall’applicazione finché il vuoto non viene colmato. UDP invia messaggi separati, chiamati datagrammi. UDP stesso non garantisce consegna, ordine o protezione dai duplicati; il programma che lo usa decide come gestire queste situazioni.

Questo lascia alle applicazioni la possibilità di scegliere comportamenti diversi. Un’applicazione vocale può scartare un pacchetto audio arrivato troppo tardi per essere riprodotto. Un gioco può preferire un aggiornamento recente della posizione a uno vecchio. Uno scambio DNS può consistere in una breve domanda e risposta. Il trasporto effettivo dipende dal programma: questi esempi non significano che ogni chiamata, gioco o richiesta DNS usi UDP.

QUIC è un protocollo di trasporto costruito su UDP. Aggiunge instaurazione della connessione, recupero dei dati persi, controllo della congestione e flussi affidabili. Un file trasferito su un flusso QUIC affidabile può arrivare completo e in ordine. Il fatto che i suoi pacchetti viaggino dentro datagrammi UDP non elimina l’affidabilità fornita da QUIC.

QUIC permette anche a più flussi di condividere una connessione. Quando i dati di un flusso vanno persi, gli altri flussi i cui dati sono arrivati possono continuare. Questo può ridurre l’attesa rispetto al trasporto di tutti i flussi in una connessione TCP ordinata. Il risultato dipende comunque da percorso, perdita di pacchetti, server e client; scegliere QUIC da solo non garantisce un’applicazione più veloce.

HTTP/3 trasporta HTTP su QUIC. HTTP/1.1 e HTTP/2 usano normalmente TCP. Tutti e tre possono servire un sito HTTPS, quindi https:// nell’indirizzo non identifica la versione HTTP e non conferma l’uso di UDP.

La cifratura è una proprietà separata. UDP non cifra i dati. QUIC usa TLS 1.3 per stabilire la protezione del traffico applicativo. Una normale applicazione UDP può usare un altro meccanismo di sicurezza o trasmettere il proprio contenuto senza cifratura; inoltrarlo attraverso un proxy non aggiunge automaticamente tale protezione.

Come SOCKS5 trasporta UDP

SOCKS5 definisce un relay UDP: un servizio che accetta datagrammi dal client, ne invia i contenuti alla destinazione e restituisce le risposte. Il client predispone prima questo inoltro tramite TCP. La connessione di controllo e il percorso dei datagrammi esistono poi affiancati.

1. Il client si connette al server SOCKS5 tramite TCP e completa la procedura di autenticazione concordata.
2. Richiede UDP ASSOCIATE. Se il proxy accetta, la risposta fornisce indirizzo e porta UDP del relay.
3. Il client invia datagrammi al relay con un’intestazione SOCKS che identifica la destinazione. Il relay rimuove quell’intestazione prima di inoltrare il contenuto. Per le risposte, aggiunge un’intestazione SOCKS prima di rimandare il datagramma al client.
4. Il client mantiene aperta la connessione di controllo TCP mentre usa il relay. Chiuderla termina l’inoltro UDP predisposto da quella connessione. Questo legame tra la connessione di controllo e l’inoltro UDP è chiamato associazione UDP.

Il relay può usare un indirizzo o una porta diversi dall’endpoint TCP inserito nelle impostazioni proxy. Inviare UDP grezzo a quell’endpoint conosciuto non esegue lo scambio SOCKS5. Un client che implementa soltanto CONNECT può usare SOCKS5 per TCP, ma non dispone della procedura necessaria qui. SOCKS4 non definisce questa funzione di relay UDP.

Questo spiega un successo parziale comune: un firewall permette la connessione TCP e l’autenticazione, ma blocca i datagrammi verso il relay negoziato. La password funziona; l’applicazione continua a non ricevere risposte UDP. Entrambe le parti del percorso devono essere disponibili.

Un proxy HTTP può inoltrare UDP?

Una normale richiesta HTTP CONNECT chiede al proxy di aprire una connessione TCP alla destinazione e trasportare un flusso di byte. Non stabilisce l’inoltro UDP. Usare TLS per la connessione a un proxy HTTPS protegge quella connessione senza cambiare il tipo di tunnel richiesto.

HTTP dispone di un meccanismo aggiuntivo di tunneling UDP, comunemente chiamato CONNECT-UDP e sviluppato come parte di MASQUE. Con client e server compatibili, il client richiede un tunnel verso una destinazione UDP. Il proxy inoltra i datagrammi a quella destinazione e riporta le risposte. Serve un supporto esplicito su entrambi i lati.

Sulla connessione client-proxy, gli HTTP Datagrams possono essere trasportati in frame QUIC DATAGRAM quando sono supportati HTTP/3 e le estensioni richieste. Possono essere trasportati anche in capsule: messaggi delimitati all’interno di un flusso HTTP affidabile, incluso HTTP/2 su TCP. In quel caso, il proxy continua a inviare UDP alla destinazione anche se la prima parte del percorso usa TCP.

Questa scelta influisce sui tempi. Se la connessione TCP perde dati, i byte successivi possono attendere il recupero, ritardando i datagrammi trasportati al loro interno. Il tunnel può funzionare ma essere inadatto a un determinato carico in tempo reale. Inserire semplicemente un indirizzo proxy http:// in un programma non abilita nessuno di questi meccanismi UDP aggiuntivi.

Quale connessione usa QUIC?

L’espressione “proxy QUIC” richiede un contesto. Può descrivere il trasporto usato per raggiungere il proxy oppure la connessione dell’applicazione alla destinazione. Sono parti separate dello scambio.

Nel normale inoltro UDP, il proxy non deve terminare la connessione QUIC dell’applicazione. Inoltra i pacchetti mentre applicazione e destinazione restano gli estremi dello scambio cifrato. Il proxy conosce comunque la destinazione del traffico e può osservarne volume e tempi.

Perché conta il supporto dell’applicazione

Un programma deve implementare il metodo di inoltro offerto dal servizio. Una casella SOCKS5 non indica se supporti UDP ASSOCIATE. Analogamente, un programma può supportare HTTP/3 per connessioni dirette ma offrire solo connessioni proxy TCP.

Chrome offre un esempio concreto: il supporto SOCKS5 integrato instrada tramite proxy le richieste URL basate su TCP e non inoltra UDP tramite SOCKS5. Caricare una pagina con quell’impostazione non verifica il relay UDP del servizio. Il limite riguarda quella specifica modalità del client; altri client o programmi esterni di instradamento possono avere capacità diverse.

Controlla anche l’ambito dell’impostazione. Accesso, download di file, voce e gioco possono usare componenti di rete diversi nella stessa applicazione. Un proxy configurato per richieste web può coprirne solo alcuni. Anche un’impostazione proxy di sistema dipende dal fatto che ogni programma la segua.

Un programma che reindirizza il traffico di un’altra applicazione può inviarne l’UDP tramite un proxy, purché supporti UDP e il metodo di inoltro del servizio. Reindirizzare il solo TCP non basta. Se il programma usa un’interfaccia di rete virtuale, le regole di instradamento decidono quale traffico vi entra. Testa la combinazione completa: applicazione, programma di instradamento ed endpoint proxy.

Ripiego, errore e connessione diretta

Quando il percorso richiesto è indisponibile, il risultato dipende dalle capacità e dalle regole dell’applicazione. Tre risultati possono sembrare simili se ci si chiede soltanto se qualcosa si sia aperto:

Passare a una versione HTTP basata su TCP è chiamato fallback, o ripiego. Può conservare la normale navigazione quando QUIC è indisponibile. Il client apre una connessione diversa; QUIC stesso non si trasforma in TCP. Disabilitare QUIC può quindi aiutare un’applicazione web a usare un percorso TCP disponibile, ma non può fornire UDP a una funzione che lo richiede.

Andare direttamente alla destinazione è una decisione di instradamento. L’UDP non supportato non viene sempre inviato direttamente: il programma può fermarsi, provare un altro trasporto o seguire una regola di esclusione configurata. Se tutto il traffico dell’attività deve passare attraverso il proxy, usa una modalità che si fermi quando quel percorso non funziona e verificane il comportamento con il proxy indisponibile.

Perché UDP può smettere di funzionare dopo l’avvio

Regole delle porte e percorso di ritorno

La porta TCP 443 e la porta UDP 443 appartengono a trasporti diversi. Consentirne una non apre l’altra. Per SOCKS5, il client deve raggiungere l’endpoint del relay UDP restituito; il relay deve anche poter raggiungere la porta UDP della destinazione. HTTP/3 può usare porte diverse da 443, quindi controlla l’endpoint realmente usato dall’applicazione.

Le risposte devono tornare attraverso relay, firewall ed eventuale NAT, che traduce indirizzi e spesso porte tra reti. Un solo datagramma inviato non dimostra che questo percorso di ritorno funzioni. Un cambiamento di rete può modificare l’IP pubblico del client o l’associazione delle porte. I relay SOCKS5 devono rifiutare datagrammi da un IP di origine diverso da quello registrato per l’associazione UDP, quindi un indirizzo cambiato può richiedere una nuova associazione.

Pause e stato scaduto

I relay e i dispositivi NAT conservano registrazioni temporanee per gli scambi UDP. Queste possono scadere durante una pausa. Una chiamata o una sessione può funzionare all’inizio, poi perdere il percorso UDP finché il client non lo predispone di nuovo. Mantenere lo stesso IP di uscita non lo impedisce: lo stato necessario a inoltrare UDP e l’assegnazione IP del servizio sono cose separate.

Dimensione dei datagrammi e MTU

L’MTU è il pacchetto IP più grande che un collegamento di rete può trasportare senza frammentazione. La dimensione utilizzabile lungo un percorso è limitata dal più piccolo di questi limiti, noto come path MTU. IP, UDP e le intestazioni aggiuntive del tunnel occupano tutti spazio nel pacchetto. Un piccolo messaggio di test può passare mentre datagrammi più grandi vengono scartati, quindi l’applicazione deve tenere conto dell’intero percorso e delle intestazioni aggiunte.

Un percorso QUIC deve trasportare almeno 1 200 byte di contenuto UDP, senza contare le intestazioni IP e UDP. Il client aggiunge riempimento ai datagrammi UDP che trasportano i pacchetti QUIC Initial fino ad almeno tale dimensione del contenuto. Le intestazioni proxy nella parte client-proxy richiedono ulteriore spazio. Non è un consiglio di impostare l’MTU dell’interfaccia a 1 200: spiega perché una piccola richiesta e risposta DNS possono funzionare mentre l’handshake QUIC, più grande, non passa.

Ritardo, perdita e carico

Per una chiamata o un gioco, il tempo di consegna può contare quanto la consegna stessa. Ritardo variabile, perdita di pacchetti e limiti sulla frequenza dei pacchetti possono compromettere un relay UDP altrimenti funzionante. La sola banda non descrive queste condizioni. Un proxy aggiunge un’altra parte al percorso; può cambiare le prestazioni in entrambe le direzioni, a seconda di reti e carico di lavoro.

Come verificare UDP e HTTP/3 attraverso un proxy

Testa l’applicazione che intendi usare o un client che implementi lo stesso metodo di inoltro. Un test utile verifica risposta, trasporto e indirizzo di uscita per lo stesso scambio.

1. Scegli una destinazione che risponda al traffico richiesto. Usa il server dell’applicazione reale o un risponditore UDP controllato. Per HTTP/3, scegli una destinazione che sai supportarlo. Il silenzio da una porta UDP arbitraria non indica quale parte non abbia funzionato.
2. Conferma che il relay o il tunnel sia stato accettato. Con SOCKS5, esamina il risultato di UDP ASSOCIATE e l’indirizzo e la porta del relay restituiti. Con un tunnel HTTP UDP, conferma l’accettazione di quel tunnel. La sola autenticazione non copre questo passaggio.
3. Completa una richiesta e una risposta. Un risponditore controllato può restituire un identificatore della richiesta e registrare l’IP di origine osservato. Questo verifica l’uscita usata per quello scambio UDP. Una verifica IP web separata riguarda soltanto la propria richiesta.
4. Per HTTP/3, conferma il protocollo dello scambio con la destinazione. Cerca HTTP/3 o h3 nel log di connessione del client o del server, insieme a prove del percorso proxy. Se il client di test ha una modalità solo HTTP/3, può evidenziare un errore che il ripiego automatico nasconderebbe.
5. Ripeti nelle condizioni pertinenti: dimensioni realistiche dei datagrammi, traffico sostenuto e una pausa seguita da attività. Se il traffico diretto è vietato per l’attività, testa anche che cosa succede quando il proxy è indisponibile. Conserva la versione del client e le impostazioni di connessione insieme al risultato.

Una cattura dei pacchetti può aiutare a identificare il percorso. Il normale inoltro UDP SOCKS5 invia datagrammi al relay negoziato. Un tunnel HTTP UDP può invece usare una connessione TCP esterna, quindi l’assenza di UDP su quella prima parte del percorso non basta a dimostrare un errore.

DNS remoto e ping verificano cose diverse. Un proxy può risolvere un hostname per una connessione TCP senza inoltrare il traffico UDP dell’applicazione. Il normale ping usa ICMP. Nessuno dei due test sostituisce una richiesta e una risposta UDP osservate sul percorso proxy previsto.

Quando conviene scegliere il supporto UDP

Inizia dal traffico richiesto dalla tua attività. Il lavoro su siti e API eseguito tramite HTTP/1.1 o HTTP/2 può essere soddisfatto interamente da un proxy solo TCP. I test HTTP/3, i contenuti multimediali UDP e altre funzioni dipendenti da UDP richiedono un relay o tunnel adatto e un client che sappia usarlo.

Chiedi al servizio quali metodi di inoltro UDP e configurazioni client siano supportati. Controlla poi destinazioni e porte consentite, limiti di dimensione dei datagrammi, comportamento durante l’inattività ed eventuali limiti di traffico o frequenza dei pacchetti pertinenti al carico di lavoro. Se TCP e UDP devono usare lo stesso IP di uscita o la stessa posizione, verifica il requisito nell’applicazione effettiva. Un account condiviso o una verifica web riuscita non dimostrano un comportamento di uscita identico.