Firewall e NAT, resi semplici.

La maggior parte degli utenti non tocca mai un'impostazione del firewall per usare Remio. L'app si basa sulla stessa tecnologia di connessione che fa funzionare le app di videochiamata dietro router domestici, Wi-Fi d'albergo e VPN aziendali: trova il percorso da sola. Ma per il piccolo numero di utenti su reti molto restrittive in cui l'impostazione predefinita si blocca, questa pagina è il riferimento unico: cosa invia davvero Remio sulla rete, cosa consentire sul firewall, come leggere la diagnostica durante la sessione e cosa dire al reparto IT.

Panoramica

Remio usa un approccio a più livelli per collegare un client a un host. Prova prima il percorso più veloce, poi ripiega con grazia se serve. Ci sono tre percorsi possibili, in quest'ordine di preferenza:

1. Diretto sulla stessa rete: client e host sullo stesso Wi-Fi o LAN. I fotogrammi viaggiano da punto a punto. Circa 8 ms di latenza di elaborazione; il resto è la cadenza di aggiornamento del tuo schermo. È ciò che ottieni a casa o in una rete di un solo ufficio. Usi Tailscale? In fondo a Impostazioni → Avanzate → Rete, attiva Passa da Tailscale quando entrambi i dispositivi sono sulla stessa rete Tailscale.
2. Diretto attraverso internet (peer-to-peer): client e host su reti diverse ma entrambi in grado di stabilire una connessione UDP in uscita. Entrambi i lati si scambiano i propri indirizzi pubblici tramite il server di connessione di Remio, poi inviano i contenuti direttamente l'uno all'altro. Da 10 a 40 ms di latenza aggiuntiva a seconda della geografia.
3. Ripiego sul relay: quando UDP è bloccato o il NAT è troppo restrittivo per un percorso diretto, entrambi i lati si connettono in uscita a un server relay (la rete globale di Cloudflare, turn.cloudflare.com), su UDP quando possibile, su TCP o TLS sulla porta 443 quando UDP è bloccato, e il relay inoltra tra loro i contenuti cifrati. Da 30 a 80 ms di latenza aggiuntiva. Funziona ovunque funzioni HTTPS.

Non scegli il percorso manualmente. Remio li prova tutti e tre contemporaneamente all'inizio di ogni sessione e usa il più veloce che riesce. Se la rete cambia a metà sessione (passi dal Wi-Fi dell'ufficio a LTE), Remio ripete la prova e cambia percorso senza interrompere la sessione.

Come una sessione Remio attraversa un firewall

Dal momento in cui tocchi Connetti nel client, ecco la sequenza:

1. TLS in uscita verso il server di connessione. Sia il client sia l'host aprono un WebSocket di lunga durata verso relay.remio.net sulla porta 443. Trasporta gli handshake di associazione, lo scambio offerta/risposta e una piccola quantità di traffico di controllo per tutta la durata della sessione. Non passano mai dati dello schermo o dell'input. È HTTPS standard: ogni firewall aziendale lo lascia passare.
2. Rilevamento della rete. Ogni lato usa il servizio STUN pubblico per scoprire il proprio indirizzo pubblico (quello che vede il resto di internet). Poi chiede al server di connessione credenziali a breve durata per il relay (turn.cloudflare.com), nel caso il rilevamento fallisca.
3. Gara dei percorsi. Entrambi i lati provano contemporaneamente UDP diretto, UDP diretto tramite gli indirizzi scoperti con STUN e relay TLS. Vince la combinazione che riesce e risponde per prima. La maggior parte delle reti domestiche sceglie UDP diretto entro 200 ms; le reti restrittive ripiegano sul relay TLS in circa 2 secondi.
4. Flusso di contenuti cifrato. Una volta scelto il percorso, ogni fotogramma video, ogni tasto, ogni campione audio viene cifrato end-to-end e inviato sul percorso scelto. Anche sul percorso relay, il nodo relay vede solo testo cifrato.

Tutto questo processo è invisibile per te: il client mostra semplicemente "Connesso". Ma capire la sequenza aiuta a comprendere le regole del firewall nella sezione successiva.

Cosa consentire sul firewall

Per i team IT che scrivono una policy del firewall, ecco l'elenco completo del traffico in uscita generato da Remio. Non servono mai regole in entrata.

# Outbound rules — Remio Client and Remio Host

# Required — connection setup (signaling only, no media)
ALLOW  TCP/443    ->  relay.remio.net           (TLS WebSocket)

# Required — relay fallback (media when no direct path exists)
ALLOW  TCP/443    ->  turn.cloudflare.com       (TURN over TLS — works when UDP is blocked)
ALLOW  UDP/3478   ->  turn.cloudflare.com       (TURN over UDP — optional, preferred)
ALLOW  UDP/443    ->  turn.cloudflare.com       (TURN over UDP — optional)

# Strongly recommended — enables direct peer-to-peer (lower latency)
ALLOW  UDP        ->  any (high ports 32768-65535)

# Optional — used during initial address discovery only
ALLOW  UDP/3478   ->  stun.cloudflare.com
ALLOW  UDP/19302  ->  stun.l.google.com

# Not required, never used
DENY   any inbound                              (nothing inbound is ever needed)

Se puoi consentire solo il minimo, consenti la porta TCP 443 in uscita verso relay.remio.net e verso turn.cloudflare.com: queste due regole bastano a Remio per funzionare da un capo all'altro, solo sul percorso relay invece che in diretta. Le sessioni restano cifrate e in streaming alla qualità piena; la latenza è l'unico costo.

Scenari comuni nelle reti aziendali

Le configurazioni reali dei firewall coprono una gamma ampia. Ecco cosa aspettarsi in ciascuna.

Uscita consentita per impostazione predefinita (la maggior parte dei piccoli uffici, reti domestiche)

Il firewall lascia uscire qualsiasi TCP e UDP in uscita, bloccando solo specifici intervalli malevoli. Remio trova un percorso UDP diretto entro un secondo e vi resta. La latenza è quella del round trip su internet, più 3-5 ms di overhead di Remio. Vedi Diretta nell'indicatore del tipo di connessione.

UDP bloccato in uscita (aziende medie, scuole)

Il firewall consente TLS e una manciata di protocolli noti, ma blocca in blocco l'UDP in uscita per prevenire abusi peer-to-peer. La prova UDP diretta di Remio fallisce, quella del relay TLS-443 riesce e la sessione si stabilisce sul percorso relay in circa 2 secondi. L'indicatore del tipo di connessione mostra Relay. La latenza aumenta di 30-80 ms a seconda della distanza dal nodo relay più vicino. Streaming, audio, tastiera e input funzionano tutti allo stesso modo.

Proxy con ispezione TLS (grandi aziende, finanza, sanità)

Il firewall decifra ogni connessione TLS in uscita, ne ispeziona il contenuto e la ricifra prima dell'inoltro. È il caso più insidioso. Due cose possono andare storte:

• Il proxy non riconosce il flusso di lunga durata di tipo multimediale che Remio usa e lo scarta dopo un breve timeout o ne limita la velocità fino a renderlo inutilizzabile.
• Il proxy rimuove parti dell'handshake di connessione che non comprende, lasciando Remio bloccato.

La soluzione è aggiungere relay.remio.net e turn.cloudflare.com all'elenco di esclusione dall'ispezione TLS del proxy. Ogni grande proxy aziendale (Zscaler, Palo Alto, Cisco Umbrella, Check Point, Forcepoint) supporta l'esclusione per dominio. Il traffico passa comunque dal firewall aziendale: semplicemente non viene decifrato lungo il percorso. I team IT di solito aggiungono esclusioni per le app di videoconferenza (Zoom, Teams) per lo stesso motivo; Remio rientra nello stesso schema.

Captive portal / Wi-Fi d'albergo

Molti hotel e aeroporti usano un captive portal che blocca tutto il traffico in uscita finché non accetti i termini. Dopo l'autenticazione, la maggior parte consente il normale HTTPS, il che significa che il percorso relay di Remio funziona. UDP è incerto: alcuni portali continuano a bloccare UDP anche dopo l'accesso. Se una sessione sembra lenta sul Wi-Fi dell'albergo, controlla l'indicatore: quasi sempre mostra Relay. Non c'è nulla da correggere; è la modalità prevista per queste reti.

NAT di classe carrier sulle reti mobili

Le connessioni 4G/5G spesso stanno dietro più livelli di NAT gestiti dall'operatore, il che rende difficile il peer-to-peer diretto. Remio lo gestisce in modo trasparente: l'UDP diretto di solito funziona in una direzione (il client mobile che raggiunge l'host) e il percorso relay è sempre disponibile come ripiego. Le prestazioni su LTE/5G sono in genere eccellenti.

Verificare il percorso della connessione

Ogni client Remio mostra il percorso di connessione scelto nella sovrapposizione delle statistiche della sessione. Aprila dalla barra degli strumenti: l'icona è un piccolo glifo a grafico a barre. Vedrai:

• Connessione — Diretta significa peer-to-peer su UDP. Latenza più bassa. I fotogrammi viaggiano direttamente dall'host al client senza passaggi intermedi.
• Connessione — Relay significa che il traffico passa dal relay (turn.cloudflare.com). Aggiunge da 30 a 80 ms di latenza. Resta cifrato end-to-end: il relay vede solo testo cifrato.
• Connessione — LAN compare quando entrambi gli estremi sono sulla stessa rete locale. Circa 8 ms di latenza di elaborazione (il resto è la cadenza di aggiornamento del tuo schermo), nessun round trip su internet.

Se ti aspetti Diretta ma vedi Relay, la rete in cui ti trovi blocca UDP da qualche parte lungo il percorso. La sessione funziona comunque, solo con latenza in più. Su una rete che controlli (il router di casa), controlla le impostazioni QoS e gli interruttori "modalità gioco" che a volte interrompono l'inoltro UDP.

Cosa può e non può vedere il relay

Una preoccupazione comune sul percorso relay è la privacy: se il mio schermo passa da un server relay, qualcuno lì può vederlo? No. Ecco perché:

• Cifratura end-to-end. Ogni fotogramma, ogni tasto, ogni campione audio viene cifrato con una chiave di sessione derivata durante l'handshake. Solo il client e l'host possiedono la chiave. Il relay inoltra testo cifrato.
• Nessun deposito di chiavi. I server di Remio non vedono né conservano mai le chiavi di sessione. Anche con pieno accesso ai log del relay e controllo fisico dei server relay, Remio non può decifrare alcuna sessione utente: passata, presente o futura.
• Nulla di leggibile da registrare. Il relay gestisce solo pacchetti cifrati e il server di connessione di Remio (relay.remio.net) trasporta solo messaggi di configurazione: mai schermo, audio o input.
• Funziona anche l'esclusione dall'ispezione TLS aziendale. Poiché i contenuti sono cifrati a un livello superiore a TLS (la cifratura avviene prima che TLS avvolga il pacchetto per il relay), un proxy TLS aziendale che decifra il TLS esterno vede comunque solo il payload interno cifrato. Nessun intermediario può leggere il tuo schermo.

Per tutta la storia della cifratura vedi Sicurezza e cifratura.

Risoluzione dei problemi di connessione

• "La connessione fallisce sul Wi-Fi aziendale ma funziona a casa": UDP è bloccato in uscita e anche il percorso relay TLS viene bloccato o alterato. Chiedi al reparto IT di consentire la porta TCP 443 in uscita verso relay.remio.net e turn.cloudflare.com e, se c'è un proxy con ispezione TLS, di aggiungere gli stessi due nomi host al suo elenco di esclusione. Questo sblocca il percorso relay; le sessioni funzionano poi da un capo all'altro.
• "La latenza è molto più alta del previsto sulla rete dell'ufficio": la connessione probabilmente passa dal relay (controlla l'indicatore della sessione). I percorsi relay aggiungono da 30 a 80 ms. Se il reparto IT può aprire UDP in uscita, Remio passerà automaticamente al percorso diretto e la latenza calerà.
• "La connessione si stabilisce ma lo stream si blocca dopo pochi secondi": tipico di un proxy con ispezione TLS che consente l'handshake iniziale ma interrompe i flussi di lunga durata. Verifica nei log IT se il proxy sta interrompendo relay.remio.net o turn.cloudflare.com e aggiungi esclusioni per entrambi.
• "Le altre app video funzionano, solo Remio fallisce": quasi sempre l'ispezione TLS o l'ispezione approfondita dei pacchetti altera l'handshake. La soluzione è la stessa: chiedi al reparto IT di aggiungere relay.remio.net e turn.cloudflare.com all'elenco di esclusione dall'ispezione.
• "A volte funziona, a volte si blocca su 'Connessione in corso'": risoluzione DNS instabile per relay.remio.net, oppure un filtro DNS aziendale che blocca il server di connessione. Prova nslookup relay.remio.net dalla stessa macchina: dovrebbe restituire un IP entro un secondo. Se va in timeout o fallisce, il collo di bottiglia è il DNS.
• "Il pulsante Connetti non fa nulla: nessun errore, nessun avanzamento": la porta 443 in uscita è completamente bloccata. È insolito ma succede su reti molto restrittive. Prova a caricare https://relay.remio.net/health in un browser; deve restituire una breve risposta di stato. Se neanche il browser lo raggiunge, il firewall blocca del tutto l'HTTPS in uscita verso quell'host.
• "Il client VPN rompe Remio quando si connette": alcuni agenti VPN catturano tutto il traffico, compresi i contenuti, il che causa scatti. Prova a escludere relay.remio.net e turn.cloudflare.com dal tunnel se la tua VPN supporta lo split tunneling.

Avanzato: restringere ulteriormente

Se il tuo team di sicurezza ha bisogno dell'elenco di autorizzazioni più stretto possibile, quello che segue è il minimo che consente comunque a Remio di funzionare da un capo all'altro:

# Minimum-viable firewall allowlist
# Allows relay-mode operation only (~30-80 ms latency)

OUTBOUND TCP/443   ->  relay.remio.net          # connection setup
OUTBOUND TCP/443   ->  turn.cloudflare.com      # relay (TURN over TLS)

# Adding these unlocks direct peer-to-peer (3-5 ms LAN, 10-40 ms WAN)
OUTBOUND UDP/3478  ->  stun.cloudflare.com      # public address discovery
OUTBOUND UDP/19302 ->  stun.l.google.com        # public address discovery (redundancy)
OUTBOUND UDP       ->  any (32768-65535)        # direct media path

Le prime due righe da sole bastano al funzionamento dell'app: ogni altra riga è un'ottimizzazione della latenza. Se vuoi sia la massima sicurezza sia la latenza più bassa, consentile tutte e cinque.

Domande su firewall e NAT

Remio richiede di aprire porte in entrata sul mio firewall?

No. Sia Remio Client sia Remio Host stabiliscono solo connessioni in uscita. Non c'è nulla da aprire sul router né nelle regole in entrata del firewall. Se la tua rete consente il normale traffico web in uscita (caricare siti, usare un'app di messaggistica), Remio funziona.

Che porte usa Remio?

TCP 443 in uscita verso relay.remio.net per la configurazione della connessione e traffico in uscita verso il relay (turn.cloudflare.com) quando non esiste un percorso diretto: UDP 3478 o 443 quando possibile, TCP o TLS sulla porta 443 quando UDP è bloccato. I contenuti peer-to-peer diretti usano UDP in uscita su porte alte casuali; il rilevamento dell'indirizzo pubblico usa UDP 3478 (stun.cloudflare.com) e UDP 19302 (stun.l.google.com). Non servono porte in entrata su nessuno dei due lati.

Remio funziona sulle reti aziendali che bloccano UDP?

Sì. Quando UDP è bloccato, Remio ripiega automaticamente sull'inoltro dei contenuti tramite TLS sulla porta 443, la stessa porta che il tuo browser usa per HTTPS. Le connessioni impiegano una frazione di secondo in più per stabilirsi e aggiungono circa 30-80 ms di latenza, ma la sessione funziona da un capo all'altro. Non c'è alcuna impostazione da cambiare: il ripiego avviene in modo trasparente.

Il mio reparto IT può ispezionare il traffico di Remio?

No. Tutti i contenuti della sessione sono cifrati end-to-end: il tuo schermo non passa mai dai nostri server e anche il relay vede solo testo cifrato. Anche quando il traffico passa dal relay sulla porta 443, il relay inoltra solo pacchetti cifrati: non può leggere il contenuto dello schermo, i tasti premuti né altri dati. Nemmeno i proxy aziendali con ispezione TLS possono vedere dentro lo stream, perché i contenuti sono cifrati a un livello superiore a TLS.

Perché la connessione funziona a casa ma fallisce in ufficio?

Le reti aziendali spesso bloccano del tutto UDP e possono bloccare anche il TLS in uscita verso host non autorizzati. Chiedi al reparto IT di consentire la porta TCP 443 in uscita verso relay.remio.net (configurazione della connessione) e verso turn.cloudflare.com (il relay che trasporta i contenuti quando UDP è chiuso). Queste due voci bastano a Remio per funzionare con UDP completamente bloccato.

Come faccio a verificare se la mia sessione è diretta o tramite relay?

Apri la sovrapposizione delle statistiche della sessione dalla barra degli strumenti. Ogni client Remio mostra un indicatore del tipo di connessione (Diretta, LAN o Relay) accanto a latenza e bitrate. Le connessioni dirette sono più reattive; quelle tramite relay aggiungono circa 30-80 ms di latenza a seconda della distanza dal nodo relay più vicino.

Remio funziona dietro una VPN o un agente zero-trust?

Sì, in quasi tutti i casi. Sia i percorsi peer-to-peer sia quelli relay usano HTTPS in uscita standard, che le VPN aziendali e gli agenti zero-trust (Zscaler, Cloudflare WARP, Tailscale, Twingate) fanno passare senza problemi. Alcuni intermediari aggressivi con ispezione approfondita dei pacchetti possono alterare lo stream: vedi la sezione sulla risoluzione dei problemi qui sopra per le soluzioni alternative.

L'intercettazione TLS della mia azienda romperà Remio?

Può succedere. I proxy con ispezione approfondita dei pacchetti che decifrano e ricifrano tutte le connessioni TLS a volte rimuovono parti dell'handshake di connessione o bloccano la natura di lunga durata dei flussi multimediali. Se vedi Remio fallire solo sulla rete aziendale, chiedi al reparto IT di aggiungere relay.remio.net e turn.cloudflare.com all'elenco di esclusione dall'ispezione TLS: la maggior parte dei proxy aziendali (Zscaler, Palo Alto, Cisco Umbrella, Check Point) supporta l'esclusione per dominio.

Guide correlate

• Configura da Mac a Mac: configurazione di base prima di ottimizzare il percorso di rete.
• Configura da Mac a iPad: stessa logica di rete, client iPad.
• Trasmetti un PC Windows a un Mac: stessa logica di rete, host Windows.
• Connessione LAN diretta: quando vuoi un peer-to-peer garantito sulla tua rete.
• Risoluzione dei problemi: guida più ampia per i problemi di connessione.
• Sicurezza e cifratura: tutti i dettagli sulla cifratura end-to-end.