Immagina che Remote Desktop funzioni sulla tua LAN e poi smetta di funzionare nel momento in cui provi a usarlo altrove. Il client si blocca su Initiating remote connection e poi restituisce l’errore con tre possibili motivi secondo cui il computer remoto non è disponibile sulla rete. Oppure va in errore con 0x204 o 0x4 prima di raggiungere una schermata di accesso. Si tratta di un limite architetturale, non di un errore che hai commesso in Impostazioni. RDP si aspetta un percorso diretto verso l’host e non include alcun meccanismo per negoziarne uno attraverso il NAT. Quindi, a meno che un router, un gateway o un tunnel non fornisca tale percorso, non ha dove andare. Scopri più nel dettaglio perché Windows Remote Desktop senza VPN non funziona, quali opzioni native sono disponibili e le soluzioni che ti consentono di connetterti.
Se la macchina di cui hai bisogno si trova dietro una rete che non controlli, HelpWire copre il caso che RDP non può gestire. È un software di accesso remoto per team IT e tecnici che si occupano di assistenza remota, e avvia una sessione tramite una connessione in uscita su entrambi i lati invece che tramite una porta in ingresso sull’host. Privilegia un percorso diretto tra le due macchine per mantenere reattivo il controllo e utilizza una connessione di relay quando la rete non consente una connessione diretta. Più avanti è disponibile una guida completa, dopo aver esaurito le soluzioni native.
Perché una connessione al desktop remoto senza VPN non riesce tramite Internet
RDP non ha un livello di attraversamento del NAT, quindi dipende da qualcos’altro per fornire un percorso diretto all’host. Microsoft lo afferma sulla pagina ufficiale su accesso dall’esterno della tua rete, dove definisce una sessione RDP una connessione peer-to-peer. Il termine lì significa diretto piuttosto che mediato, non che RDP implementi alcuna architettura peer-to-peer. E ciò che conta è la conseguenza: hai bisogno di accesso diretto alla macchina host. La stessa pagina offre esattamente due modi per ottenere tale accesso, il port forwarding o una VPN, e associa un avvertimento al primo. Parole della stessa Microsoft, testuali: “Stai esponendo il tuo PC a internet, il che non è consigliato.”
Questo è l’intero problema così come dichiarato dal fornitore. Confrontalo con il comportamento dei moderni protocolli peer-to-peer. Includono un client STUN, scoprono il proprio indirizzo pubblico, aprono un varco attraverso il NAT e ripiegano su un relay quando il tipo di NAT li blocca. RDP non fa nulla di tutto ciò. Ascolta su TCP 3389, e se lì non arriva alcun pacchetto, non succede nulla.
Come si interrompe il percorso di connessione
Il client risolve un nome o un IP e apre una connessione TCP alla porta 3389 sull’host. Quella connessione deve attraversare il tuo ISP, il tuo router, il Windows Defender Firewall e raggiungere il listener RDP. Il NAT carrier-grade la interrompe al primo hop, perché il tuo router ha un indirizzo WAN privato e la regola di inoltro che hai configurato non riceve mai traffico. Un IP pubblico dinamico la interrompe al secondo hop dopo che l’indirizzo cambia. Un profilo del firewall senza la corrispondente regola di Desktop remoto abilitata la interrompe al terzo hop, perché tali regole sono definite per profilo e una rete classificata come Public spesso le ha disattivate. Un listener mancante la interrompe al quarto, ed è ciò che accade su Windows Home, dove il componente host è assente indipendentemente da ciò che scrivi nel registro.
Controlla l'indirizzo WAN
Il controllo richiede trenta secondi. Leggi l’IP WAN dalla pagina di stato del tuo router, poi confrontalo con quanto riporta un verificatore pubblico di IP. Se gli indirizzi coincidono, significa che il router ha l’indirizzo IPv4 pubblico, il che è una condizione necessaria e non sufficiente, perché un ISP può comunque filtrare il traffico in ingresso su 3389 a monte di te. Indirizzi diversi significano che un altro NAT è sopra di te, e l’indirizzo WAN restringe quale tipo.
Un indirizzo all’interno di 100.64.0.0/10 è spazio condiviso del carrier e indica un NAT carrier-grade, dove nessuna regola che scrivi riceverà mai traffico in ingresso. Un indirizzo all’interno di 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16 più spesso significa che un modem o gateway dell’ISP si trova davanti al tuo router. Questo è un doppio NAT ordinario e si può risolvere con una regola su entrambi i dispositivi o con la modalità bridge sull’apparato a monte. Alcuni carrier eseguono NAT carrier-grade anche su intervalli privati, quindi se le regole su entrambi i dispositivi ancora non producono nulla, trattalo come NAT carrier-grade.
L'autenticazione può fallire dopo che la rete funziona
Una volta che i pacchetti raggiungono l’host, la connessione può comunque interrompersi durante l’autenticazione, e gli errori sembrano identici a un guasto di rete dal lato client. La mancata corrispondenza della versione di CredSSP produce Si è verificato un errore di autenticazione. La funzione richiesta non è supportata. Gli host aggiunti a Microsoft Entra rifiutano il formato dominio\utente e restituiscono un messaggio che indica che la macchina remota è aggiunta a Entra. I client Windows 11 24H2 interrompevano le sessioni UDP verso host RDS legacy dopo circa 65 secondi.
RDP Shortpath è diverso
RDP Shortpath utilizza ICE per valutare i percorsi candidati, STUN per una connessione UDP diretta tra client e host della sessione, e TURN per fungere da relay quando una diretta non è possibile. Il servizio di relay è raggiunto in uscita su UDP 3478. Il percorso UDP diretto utilizza un intervallo di porte configurabile anziché uno fisso. Quando l’UDP è completamente bloccato, la sessione esegue il fallback al trasporto reverse connect basato su TCP attraverso il gateway del servizio.
Shortpath è un’ottimizzazione del trasporto all’interno di tali servizi, piuttosto che un livello di attraversamento NAT che puoi indirizzare verso qualsiasi macchina. Il client e l’host della sessione si trovano tramite il piano di controllo di Azure Virtual Desktop o Windows 365 prima, e solo allora Shortpath negozia un percorso UDP. Quella presentazione mediata è la parte che manca a una normale connessione PC a PC. Shortpath, e il più recente RDP Multipath costruito sopra di esso, sono destinati ad Azure Virtual Desktop host di sessione e ai Windows 365 Cloud PC, non a mstsc.exe verso un normale PC Windows.
Cosa prova per prima la maggior parte delle persone e perché fallisce
netsh int ip reset, netsh winsock reset, sfc /SCANNOW, e DISM si eseguono in sequenza e non cambiano nulla, perché lo stack locale non è mai stato danneggiato. Un caso documentato su Windows 10 Enterprise 22H2, build 19045.3803, ha eseguito tutti e quattro più un riavvio di Remote Desktop Services, una disattivazione completa del firewall, una commutazione dell’RD Gateway e uno svuotamento della cache delle credenziali prima che chi ha segnalato notasse l’indizio rivelatore: le connessioni verso un IP inutilizzato procedevano normalmente mentre le connessioni verso l’host reale generavano 0x4 all’istante. Quel modello indica la cache di sessione lato client o il livello di sicurezza, non l’instradamento.
DMZ modalità e UPnP vengono abilitati per aggirare CGNAT. Nessuno dei due può, perché il blocco avviene al gateway dell’operatore a cui non puoi accedere, diversi hop a monte del tuo router. DMZ amplia solo la tua esposizione locale mentre il traffico in ingresso continua a non arrivare.
Altri cambiano la porta di ascolto da 3389 nella convinzione che nasconda l’host. Gli scanner Internet identificano RDP su porte non predefinite. Disabilitano anche NLA come prima mossa anziché l’ultima, il che rimuove l’autenticazione pre-sessione da una macchina che stanno per esporre a Internet.
Abilitare RDP su Windows Home tramite fDenyTSConnections accetta il valore e non produce nulla, perché il componente host non esiste in quell’edizione. E dopo che gli aggiornamenti di gennaio 2026 hanno interrotto Remote Assistance, ha cominciato a circolare una soluzione alternativa che sostituisce msra.exe con una copia non aggiornata da un’altra macchina. Ripristina la funzionalità riaprendo CVE-2026-20824, l’aggiramento della funzionalità di sicurezza di Remote Assistance che Microsoft ha pubblicato il 13 gennaio 2026.
Desktop remoto senza VPN: soluzioni che reggono
Sono ordinate in base alla frequenza con cui risolvono il problema, a partire dalla procedura diagnostica che fa risparmiare più tempo.
Soluzione 1. Conferma che esista un indirizzo raggiungibile prima di intervenire su Windows
Nient’altro importa finché non sai se il traffico in ingresso può raggiungere il tuo router:
Apri la pagina di amministrazione del router e annota l’indirizzo IP WAN o Internet dalla schermata di stato.
Da un browser sulla stessa rete, apri qualsiasi sito di verifica dell’IP pubblico e annota l’indirizzo che riporta.
Confrontali. Identici significa che il router ha un IP pubblico instradabile. Diversi significa che c’è un altro NAT a monte, e l’indirizzo WAN ti dice di quale tipo:
100.64.0.0/10indica un NAT carrier-grade, mentre10.0.0.0/8,172.16.0.0/12o192.168.0.0/16più spesso significa un gateway dell’ISP davanti al tuo router.Se gli indirizzi coincidono, verifica che la porta sia aperta dall’esterno. Da un telefono con dati mobili, non sul tuo Wi‑Fi, esegui un controllo della porta verso il tuo IP pubblico sulla porta
3389.Se un gateway dell’ISP si trova davanti al tuo router, inoltra la porta su entrambi i dispositivi oppure imposta l’apparato a monte in modalità bridge, quindi ripeti il test.
Se l’indirizzo WAN è carrier-grade, o le regole su entrambi i dispositivi non producono ancora nulla, chiama l’ISP e chiedi un indirizzo
IPv4pubblico. Alcuni lo forniscono gratuitamente su richiesta, mentre altri applicano un piccolo canone mensile. Se rifiutano, passa alla sezione di fallback.
Correzione 2. Abilita correttamente l'host e dimostra che il listener è attivo
Il flag del registro, da solo, non apre il firewall, ed è proprio questo il passaggio che la maggior parte delle guide omette:
Apri un Prompt dei comandi con privilegi amministrativi sull’host e abilita il protocollo:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /fAttiva le regole del firewall. Imposta l’ambito su
DomainePrivatea meno che non ti serva davveroPublic:netsh advfirewall firewall set rule group="remote desktop" new enable=Yes profile=domain,privateIn un’installazione non in inglese, il nome del gruppo visualizzato è localizzato e quel comando non corrisponde a nulla. I nomi delle regole non sono localizzati, quindi fai riferimento direttamente a questi:
Get-NetFirewallRule -Name "RemoteDesktop-UserMode-In-TCP","RemoteDesktop-UserMode-In-UDP" | Set-NetFirewallRule -Enabled True -Profile Domain,PrivateConferma che il servizio sia impostato per l’avvio automatico e sia in esecuzione:
sc config TermService start= autosc query TermServiceVerifica che il listener sia associato:
netstat -an | findstr :3389Una configurazione predefinita restituisce sia
TCP 0.0.0.0:3389 ... LISTENINGsiaTCP [::]:3389 ... LISTENING. Un listener associato a un singolo indirizzo o a un singolo stack mostra meno voci, il che è normale su un host personalizzato. Un risultato vuoto è il segnale di errore.Aggiungi esplicitamente l’account, poiché l’appartenenza agli amministratori locali non sempre viene ereditata come si pensa:
net localgroup "Remote Desktop Users" "DOMAIN\username" /addVerifica che le regole del firewall siano abilitate anziché essere semplicemente presenti:
netsh advfirewall firewall show rule group="remote desktop"Se il passaggio 4 non restituisce nulla, l’host è dell’edizione Home, oppure
TermServicenon è riuscito ad avviarsi. Nessuna delle due è risolvibile con ulteriori modifiche al Registro di sistema.
Correzione 3. Metti RDP dietro RD Gateway su TCP 443
Microsoft supporta questo metodo per il desktop remoto senza VPN, perché mette RDP dietro a un gateway HTTPS invece di esporre direttamente la porta 3389. RD Gateway incapsula RDP all’interno di HTTPS, così la porta 3389 non è mai esposta a internet, e il client si autentica al gateway prima che la sessione raggiunga la macchina di destinazione. La porta in uscita 443 è inoltre aperta su quasi tutte le reti di hotel, caffè e aeroporti che bloccano 3389.
Su un host Windows Server, installa il servizio ruolo Gateway Desktop remoto tramite Server Manager.
Associa un certificato SSL il cui nome del soggetto corrisponda al FQDN esterno. Un certificato pubblicamente attendibile richiede meno lavoro, perché un certificato autofirmato deve essere installato nell’archivio Trusted Root di ogni client che si connette.
Crea un Criterio di autorizzazione della connessione e un Criterio di autorizzazione delle risorse che specificano il gruppo di utenti autorizzato e gli host interni autorizzati.
Posiziona il gateway in una DMZ ed esponi verso di esso la porta TCP
443in ingresso, oltre alla porta UDP3391se desideri il trasporto UDP. Nient’altro.Sul client, aprire
mstsc.exe, espandere Mostra opzioni, andare alla scheda Avanzate, fare clic su Impostazioni sotto Connetti da qualsiasi luogo e immettere l’FQDN del gateway.Esegui un test da una rete esterna prima di dismettere qualsiasi percorso di accesso esistente.
Sii realistico sui costi. Questo approccio richiede Windows Server, un certificato che acquisti o distribuisci tu stesso e una progettazione di rete DMZ. La gestione delle licenze dipende da ciò che si trova dietro il gateway, perché le CAL RDS sono legate all’uso dell’Host sessione Desktop remoto piuttosto che al ruolo di gateway in sé. Quindi una distribuzione che fa da broker delle connessioni verso singoli PC client ha una situazione diversa rispetto a una farm di host di sessione. Verifica la tua situazione prima di definire il budget. Per un singolo PC domestico o un ufficio di due persone, è sproporzionato, ed è un motivo legittimo per guardare altrove.
Soluzione 4. Eliminare correttamente l'errore dell'oracolo di crittografia di CredSSP
La soluzione corretta è applicare le patch a entrambe le parti, non indebolire il client.
L’errore esatto recita: Si è verificato un errore di autenticazione. La funzione richiesta non è supportata. Computer remoto: <name>. Questo potrebbe essere dovuto alla correzione dell'oracolo di crittografia CredSSP. Risale a CVE-2018-0886 e all’aggiornamento di imposizione del maggio 2018, che ha impedito ai client aggiornati di connettersi a host non aggiornati.
Installa l’aggiornamento cumulativo più recente sull’host. Questo risolve l’errore in modo definitivo ed è l’unica soluzione che Microsoft approva.
Se non è possibile applicare immediatamente la patch all’host, applica la soluzione temporanea lato client documentata da un Prompt dei comandi con privilegi amministrativi. Il valore 2 è il livello di protezione Vulnerabile:
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2Applica la patch all’host, quindi ripristina il client. I tre livelli di protezione sono 0 per Client aggiornati forzatamente, 1 per Mitigato e 2 per Vulnerabile, e il valore predefinito dopo l’aggiornamento
CredSSPè 1. Ripristina tale valore predefinito:REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 1Usa
0invece di1per Client aggiornati forzatamente, che è più restrittivo e rifiuta qualsiasi host che stia ancora eseguendo unCredSSPnon patchato. Se il valore del registro di sistema non rimane impostato, il Criterio di gruppo Correzione Oracle della crittografia lo sta sovrascrivendo. Controlla Configurazione computer > Modelli amministrativi > Sistema > Delega delle credenziali > Correzione Oracle della crittografia e imposta il criterio stesso anziché la chiave.
Soluzione 5. Utilizza il formato corretto del nome utente sugli host aggiunti a Microsoft Entra
Le macchine aggiunte a Microsoft Entra rifiutano il formato domain\user senza eccezioni e restituiscono: Remote machine is Microsoft Entra joined. If you are signing in to your work account, try using your work email address.
Inserisci le credenziali come
user@domain.comoAzureAD\user@domain.com. Maidomain\user.Aggiungi l’account al gruppo Remote Desktop Users dell’host nello stesso formato:
net localgroup "Remote Desktop Users" "AzureAD\user@domain.com" /addPer l’autenticazione completa con Entra, apri mstsc.exe, vai alla scheda Avanzate e seleziona Usa un account Web per accedere al computer remoto. Questo corrisponde alla proprietà RDP
enablerdsaadauth.Connetti tramite nome host, non tramite IP. L’opzione account Web non accetta indirizzi IP letterali e il nome deve corrispondere al nome host del dispositivo registrato in Entra ID.
Se l’accesso continua a non riuscire con credenziali valide, verifica la presenza di un’impostazione MFA legacy per utente sull’account. L’imposizione per utente blocca questo percorso e deve essere rimossa a favore di Accesso condizionale.
Versione minima per l’opzione di account web: Windows 11 con KB5018418 o successivo, Windows 10 20H2 o successivo con KB5018410 o successivo, Windows Server 2022 con KB5018421 o successivo. Le password temporanee non funzionano mai per l’accesso RDP, quindi reimposta prima la password in un browser.
Correzione 6. Applica patch alle note regressioni di Windows 11 invece dello switch UDP
Tre regressioni distinte hanno colpito le build recenti di Windows 11. Tutte e tre sono già state corrette, e una disabilitazione permanente dell’UDP è la risposta sbagliata a ciascuna di esse.
| Sintomo | Configurazione interessata | Risoluzione confermata |
| La sessione si blocca poco dopo la connessione, mouse e tastiera non rispondono | Windows 11 24H2 dopo KB5050094 del 28 gennaio 2025, le cui modifiche KB5051987 dell’11 febbraio 2025 sono state portate nel canale di sicurezza | KB5052093, l’aggiornamento facoltativo del 25 febbraio 2025, o qualsiasi aggiornamento cumulativo successivo |
| Lo stesso blocco sul lato server | Windows Server 2025 dopo il suo aggiornamento di sicurezza di febbraio 2025 | KB5055523, rilasciato l’8 aprile 2025, o successivo |
| La sessione si disconnette dopo circa 65 secondi su UDP | Windows 11 24H2 client verso host RDS su Windows Server 2016 o precedenti | KB5053656 o successivo |
| L’accesso non riesce immediatamente in Windows App o Desktop remoto con un errore di autenticazione | Windows 11 24H2 build 26100.7623 e 25H2 build 26200.7623 dopo KB5074109, con regressioni corrispondenti su Windows 10 e Windows Server dopo i rispettivi aggiornamenti del 13 gennaio 2026 | Gli aggiornamenti fuori banda del 17 gennaio 2026, elencati per versione nel passaggio 2, o qualsiasi aggiornamento cumulativo successivo |
| Nessuno dei due sintomi, ma le sessioni si interrompono comunque | Qualsiasi | Diagnostica il trasporto separatamente prima di disabilitare UDP |
Esegui
winvere conferma la build.24H2appartiene alla famiglia26100, e la stringa di versione da sola non conferma che la patch sia presente.Apri Impostazioni > Windows Update > Cronologia degli aggiornamenti. Per le due regressioni del 2025,
KB5053656o qualsiasi aggiornamento cumulativo successivo copre entrambe. Per la regressione dell’autenticazione di gennaio 2026, Microsoft ha distribuito aggiornamenti fuori banda il 17 gennaio 2026:KB5077744per Windows 1125H2e24H2,KB5077797per Windows 1123H2,KB5077796eKB5077795per Windows 10,KB5077793per Windows Server 2025,KB5077800per Windows Server 2022 eKB5077792per Windows Server versione23H2.Se il dispositivo è gestito e non può ancora essere aggiornato con una patch, distribuisci il criterio Known Issue Rollback tramite il modello di Criteri di gruppo fornito da Microsoft per questo problema, aggiorna il criterio e riavvia.
Solo se le disconnessioni persistono dopo aver applicato le patch, effettua un test con l’UDP disattivato in Configurazione computer > Modelli amministrativi > Componenti di Windows > Servizi Desktop remoto > Client Connessione Desktop remoto > Disattiva UDP sul client, e consideralo una misura diagnostica piuttosto che uno stato permanente.
Non disinstallare l’intero aggiornamento cumulativo 24H2. Questo rimuove correzioni di sicurezza non correlate per risolvere un problema che è stato corretto oltre un anno fa.
Il desktop remoto è sicuro senza VPN?
Sì, una connessione al desktop remoto senza VPN è sicura se c’è un gateway o un tunnel davanti ad essa. No, quando 3389 rimane aperta su un IP pubblico.
La distinzione è importante perché spesso le due vengono trattate come un’unica cosa. RD Gateway, un tunnel autenticato e una connessione mediata da un broker tengono tutti il listener RDP fuori da Internet pubblico e sono difendibili. Una porta inoltrata è tutt’altra cosa. Il Report Sophos Active Adversary 2026, basato su 661 casi di incident response e managed detection gestiti tra novembre 2024 e ottobre 2025, colloca ancora RDP in cima all’elenco dei binari Microsoft abusati. L’uso interno di RDP è apparso nel 66% dei casi e l’uso esterno nel 10%. Il solo brute force ha rappresentato il 15.58% delle cause all’origine, e le cause legate all’identità hanno raggiunto complessivamente il 67.32%. Sophos ha anche registrato un dimezzamento dei sistemi RDP esposti nel corso dell’anno, che è un progresso, non un via libera.
Limitazioni: Cosa non può darti una porta esposta
Una porta 3389 inoltrata non ha alcuna barriera di pre-autenticazione oltre NLA, nessuna regola di accesso per utente o per orario e nessun filtro geografico. La registrazione dei log esiste ma è disattivata per impostazione predefinita. Windows Defender Firewall scrive in %systemroot%\system32\LogFiles\Firewall\pfirewall.log, ma solo dopo che imposti Log dropped packets and Log successful connections su Yes nelle impostazioni di registrazione per ciascun profilo in wf.msc, e per impostazione predefinita entrambi sono su No. Senza di essi, l’unico segnale è un Security event log che si riempie di errori 4625 all’incirca una volta al secondo durante un attacco a forza bruta attivo. Vale la pena conoscere quest’ultimo sintomo, perché una macchina sotto attacco inizia a generare An internal error has occurred per esaurimento delle risorse, e l’errore non dice nulla sulla causa.
Se comunque mantieni una porta aperta, fai queste quattro cose. Limita l’intervallo di IP sorgente sul router anziché sull’host, poiché un filtro che esiste solo in Windows Firewall consente comunque al traffico di raggiungere la macchina. Rinomina l’account Administrator e imposta una soglia di blocco tra tre e cinque tentativi falliti. Imposta una lunghezza minima della password di dodici caratteri per ogni account nel gruppo Remote Desktop Users. Mantieni NLA attivo, perché impone l’autenticazione prima che venga creata una sessione e nega alle richieste non autenticate le risorse da poter esaurire.
Ci sono casi in cui una VPN è ancora la scelta giusta, e fingere il contrario sarebbe disonesto. Ambienti regolamentati con mandati di tunnel crittografati, reti multisito che necessitano di controllo degli accessi centralizzato. E le infrastrutture con supervisione IT minima traggono tutte beneficio dal perimetro di rete che una VPN fornisce. In quegli ambienti, una VPN è lo strumento giusto. È sproporzionata quando una sola persona ha bisogno di accedere a una sola macchina.
Se Desktop remoto di Windows continua a non connettersi senza VPN
Due fallback nativi si applicano a situazioni specifiche ed entrambi hanno un limite invalicabile.
Quick Assist, solo per supporto assistito. Quick Assist opera tramite il relay at remoteassistance.support.services.microsoft.com sulla porta TCP 443 con TLS 1.2, quindi non è necessaria alcuna porta in ingresso su nessuna delle due macchine. È disponibile sulle versioni supportate di Windows 10 e Windows 11 ed è distribuito e aggiornato tramite Microsoft Store. L’operatore accede con un account Microsoft o aziendale, genera un codice a tempo e il destinatario lo inserisce e approva la sessione. Usalo quando una persona è presente alla macchina remota. Non dispone di una modalità non presidiata, quindi non sostituisce RDP per l’accesso al proprio PC non presidiato e non lascia alcun registro della sessione da rivedere in seguito. Gli ambienti gestiti che necessitano di più utilizzano Remote Help, che Microsoft concede in licenza separatamente.
IPv6, quando entrambi gli endpoint lo hanno. RDP, per impostazione predefinita, si associa a tutte le interfacce, motivo per cui netstat mostra TCP [::]:3389 LISTENING. IPv6 non prevede NAT, quindi il CGNAT smette di essere rilevante e basta un’apertura nel firewall sul router e sull’host. Devono sussistere tre condizioni. Entrambi gli endpoint devono avere un IPv6 funzionante, cosa che test-ipv6.com confermerà. L’operatore non deve filtrare in blocco l’IPv6 in ingresso, e diversi lo fanno, con T-Mobile Home Internet come caso ampiamente segnalato. E serve un modo stabile per raggiungere l’host. La selezione dell’indirizzo IPv6 su Windows varia a seconda della configurazione e il prefisso dell’ISP può cambiare alla riconnessione; quindi un record AAAA mantenuto aggiornato da un client di DNS dinamico è la soluzione duratura. Se confermi che l’indirizzo di cui hai bisogno ruota, questi due comandi affrontano meccanismi distinti. Il primo interrompe la randomizzazione dell’identificatore di interfaccia. Il secondo disattiva gli indirizzi temporanei. Nessuno dei due conserva l’indirizzo quando l’ISP cambia il tuo prefisso, motivo per cui il record DNS ha più peso:
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set privacy state=disabled
Una nota su Windows App. Windows App è il client unificato di Microsoft per Windows 365, Azure Virtual Desktop, Microsoft Dev Box, Remote Desktop Services e PC remoti. Ma ciò a cui può accedere dipende dalla piattaforma su cui lo esegui e, su Windows, al momento non copre i Remote Desktop Services, che invece sono coperti da macOS, iOS, iPadOS e Android, mentre le connessioni a PC remoti su Windows sono in anteprima. Il client Remote Desktop autonomo installato tramite MSI e il client web di Remote Desktop hanno entrambi perso il supporto per gli ambienti cloud commerciali il 27 marzo 2026, con il client MSI esteso fino al 28 settembre 2026 per Azure Government, Azure gestito da 21Vianet e AVD Classic. Allo stesso tempo, mstsc.exe rimane l’opzione generalmente disponibile per le comuni connessioni da PC a PC e nulla di tutto ciò cambia il modo in cui i pacchetti raggiungono l’host.
Se nessuna delle due si applica, il problema non è più un problema di Windows. Si tratta di una rete che non puoi modificare e la sezione successiva tratta ciò che funziona lì.
Quando non spetta a te modificare la rete: HelpWire
HelpWire è un software di accesso remoto che raggiunge macchine che RDP non può raggiungere, perché nessuna delle due parti ha bisogno di una porta in ingresso. L’app dell’operatore e l’app del client stabiliscono entrambe connessioni in uscita. Questo è lo scenario in cui ogni percorso nativo finisce: nessun IP pubblico a cui inoltrare, nessun Windows Server per ospitare un gateway e nessuno seduto alla macchina remota per leggere un codice di Assistenza rapida.
Come funziona HelpWire
L’operatore invia il link di connessione generato via email, chat o ticket dell’helpdesk. Il cliente segue il link, il download inizia con il sistema operativo rilevato automaticamente e avvia l’app. L’app client è portatile per impostazione predefinita, quindi non c’è un programma di installazione e non sono necessari diritti di amministratore per eseguirla. Fa clic su Concedi accesso, e inizi a fornire assistenza da remoto.
Per lavori che proseguono oltre una singola sessione, puoi in seguito richiedere l’accesso non presidiato. Il cliente approva una volta sola e, da quel momento, l’operatore e i suoi colleghi si connettono dal portale senza alcuna azione da parte del cliente, a condizione che la macchina sia accesa e online. Le sessioni si ricollegano dopo un riavvio, il che è importante per le installazioni di driver e gli aggiornamenti di Windows che altrimenti interromperebbero prematuramente una chiamata di supporto.

Cosa succede quando un percorso diretto non è disponibile
HelpWire dà priorità a una connessione diretta tra operatore e cliente per ridurre la latenza durante le attività pratiche. Quando le condizioni di rete impediscono un percorso diretto, utilizza una connessione tramite relay per mantenere la connettività invece di interrompere la sessione. L’effetto pratico si nota durante la navigazione ripetuta tra finestre di dialogo e pagine delle impostazioni.
Controllo degli accessi e crittografia
Le sessioni avvengono tramite TLS con crittografia AES-256. Il cliente approva ogni sessione assistita e può revocare l’accesso in qualsiasi momento. Gli operatori possono revocare il proprio accesso non presidiato dalla scheda workstation nel portale. L’accesso all’account utilizza Clerk con una password monouso opzionale come secondo fattore e le app sono firmate da DigiCert. Rispetto a un esposto 3389 listener, la differenza pratica è che l’accesso viene concesso per dispositivo da una persona che può revocarlo, anziché essere dedotto da chi per primo indovina una password.
HelpWire vs. altre opzioni a confronto
| Percorso | Porta in ingresso necessaria | Edizione di Windows sul PC di destinazione | Accesso non presidiato | Infrastruttura aggiuntiva |
Inoltro delle porte su 3389 | Sì, e un IP pubblico | Pro, Enterprise, Education o Server | Sì | Accesso di amministratore al router |
RD Gateway su 443 | Sì, sul gateway | Pro, Enterprise, Education o Server | Sì | Windows Server, certificato SSL, progettazione della DMZ |
| Quick Assist | No | Qualsiasi | No | Account Microsoft per l’assistente |
RDP su IPv6 | Pinhole su entrambi i firewall | Pro, Enterprise, Education o Server | Sì | ISP dual-stack su entrambe le estremità |
| HelpWire | No | Windows 7 e versioni successive | Sì | Nessuna sul lato di rete |
Nota: HelpWire è progettato attorno ai flussi di lavoro di supporto piuttosto che alla gestione di parchi macchine su larga scala. Quindi, se la tua esigenza è l’applicazione centralizzata delle policy su migliaia di endpoint, si tratta di un’altra categoria di strumenti. Per un tecnico che deve accedere a una macchina specifica su una rete che nessuno riconfigurerà, elimina il vincolo che rende RDP inutilizzabile in primo luogo.
Consiglio da esperto: testa la riconnessione, non la connessione
Configura qualunque percorso tu scelga, quindi riavvia l’host e riprova prima di farci affidamento. Per la mia esperienza, la seconda connessione fallisce più spesso della prima e i motivi sono prevedibili. La concessione DHCP ha spostato l’host su un nuovo IP interno e ha interrotto la regola di inoltro, l’IP pubblico è cambiato durante la notte senza un DDNS che lo seguisse, un indirizzo di privacy di Windows ha rigenerato l’identificatore host IPv6, oppure la macchina è andata in sospensione e ha interrotto il listener. Imposta un IP interno statico o una prenotazione DHCP, disabilita la sospensione sull’host tramite Impostazioni > Sistema > Alimentazione & batteria e verifica che il percorso sopravviva a un riavvio. Solo un percorso che sopravvive a un riavvio è uno su cui puoi fare affidamento.
Domande frequenti
Sì, tramite quattro percorsi nativi: una porta inoltrata, RD Gateway su HTTPS 443, Quick Assist tramite il relay di Microsoft, oppure RDP su IPv6. Ognuno ha un requisito imprescindibile. L’inoltro delle porte richiede un indirizzo IPv4 pubblico e l’accesso al router. RD Gateway richiede Windows Server, oltre a CAL RDS se gli utenti si collegano tramite esso a un Remote Desktop Session Host. Quick Assist richiede una persona al computer remoto. IPv6 richiede un servizio dual-stack su entrambe le estremità e un operatore che non filtri il traffico in ingresso.
La ragione più comune è il NAT carrier-grade, in cui il tuo ISP condivide un unico indirizzo IPv4 pubblico tra molti clienti e il tuo router ha un indirizzo WAN privato. Il traffico in ingresso raggiunge il gateway del carrier, che non ha alcuna regola che lo mappi a te, e viene scartato prima ancora di raggiungere il tuo router. Confronta l’IP WAN del tuo router con un verificatore dell’IP pubblico. Indirizzi diversi confermano il CGNAT.
No. Un listener esposto attira scansioni automatizzate nel giro di poche ore e non offre alcuna barriera di pre-autenticazione oltre a NLA, nessuna restrizione sull’origine e nessun registro di audit significativo. Instrada il traffico attraverso RD Gateway su 443 o tramite un tunnel in uscita.
Non è possibile ospitare una sessione RDP su qualsiasi edizione Home, perché il componente listener è assente indipendentemente da ciò che si scrive in fDenyTSConnections. Windows Home può fungere da client e connettersi a un host Pro, Enterprise, Education, o Windows Server host. Per l’accesso in ingresso a una macchina Home, utilizzare uno strumento di accesso remoto che non dipenda dal listener RDP.
Il percorso LAN salta ogni livello che interrompe il percorso internet. Nella LAN, non c’è alcun NAT da attraversare, nessun gateway dell’operatore e nessun cambio di profilo del firewall. Su internet, la stessa connessione deve superare CGNAT, un IP pubblico dinamico, una regola del router e un profilo di Windows Firewall che tratta la rete pubblica in modo diverso da quella privata.
Entrambi sono codici generici che segnalano una connessione non riuscita o interrotta senza indicarne la causa, quindi trattali come uno spunto per la diagnosi piuttosto che come una risposta in sé. Per 0x204, inizia dal livello di rete: conferma l’instradamento, le regole del firewall e se netstat -an | findstr :3389 mostra un listener in ascolto sull’host. Per 0x4, che spesso segue una disconnessione improvvisa, escludi lo stato di sessione lato client e il livello di sicurezza prima di intervenire sullo stack di rete.
No, e può causare problemi. Gli scanner Internet individuano l’RDP anche su porte non predefinite. Quindi la modifica offre pochi benefici in termini di sicurezza ed è stato segnalato che interrompe gli hook di autenticazione a più fattori che si aspettano il listener predefinito. Limita l’intervallo di IP sorgente sul router e metti il traffico dietro un gateway o un tunnel invece.


