"Impossibile connettersi al computer remoto": cosa fare quando i nostri servizi non rispondono ai client

Quando tutto sembra essere configurato come da manuale ma il servizio remoto continua a non rispondere, c'è solo una cosa da fare: armarsi di questa "checklist" e... trovare l'inghippo.

Prenderò spesso ad esempio la diagnosi di un problema di connessione verso un computer con Desktop remoto, ma la procedura è la stessa anche in caso si tratti di VNC, oppure di un server web, di un server FTP e, più in generale, di tutte quelle circostanze in cui un programma "client" debba scambiare dati con la controparte "server" avviata su un computer distinto.

"Zero". In rete locale funziona?

Quando si parla di predisporre servizi client-server, la raccomandazione che aggiungo sempre ad ogni articolo è di provare il servizio in rete locale prima di aggiungere quel gigantesco tassello di complessità che è il transito per Internet. Di conseguenza, la lista di prove indicate di seguito dovrebbe essere svolta interamente in LAN fino al raggiungimento di una percentuale di successo del 100%, anche in seguito a molteplici riavvii del server, del client e degli apparati di rete. Solo in seguito si potrà tentare di sfruttare il servizio "da remoto" nel senso linguistico della locuzione.

1. Il programma "server" è davvero in esecuzione?

Il programma "server" può crashare per chissà-quale-motivo oppure una modifica errata alla configurazione può averne impedito il corretto riavvio. Come primissimo check, quindi, verificare che la componente "remota" sia effettivamente in esecuzione.

Come verificarlo (Windows): aprire Task Manager (combinazione da tastiera Ctrl+Maiusc+Esc), spostarsi alla scheda Servizi e cercare il nome del servizio sotto esame (per Desktop remoto, il nome è TermService).

Verificare che la colonna Stato reciti Avviato. In caso non fosse possibile individuare il nome qui, ripetere la verifica sotto la scheda Dettagli. In caso l'elemento sotto indagine non figurasse in nessuna delle due liste oppure fosse Arrestato, significa che il processo non è in esecuzione ed è, quindi, indispensabile avviarlo.

In caso il servizio non fosse in esecuzione e non riuscisse ad avviarsi, il Visualizzatore eventi è il primo "posto" in cui guardare per scoprire la causa.

Come verificarlo (Linux): impartire il comando ps ax | grep NomeServizio (impiegando il nome opportuno: quindi ps ax | grep httpd oppure ps ax | grep mysql per ricercare, rispettivamente, Apache o MySQL). In caso la lista mostrata fosse vuota, il demone non è in esecuzione.

Impartire tail -n 100 /var/log/syslog in ambito Ubuntu oppure tail -n 100 /var/log/messages sotto CentOS per visualizzare il log con gli errori.

2. Il server riesce a connettersi a se stesso?

C'è un modo molto semplice per capire se il malfunzionamento sia da attribuirsi ad un problema di rete: provare a far connettere il server a se stesso.

Avviate un istanza del programma "client" (lo stesso che, in seguito, utilizzerete per connettervi da remoto) direttamente sul server e impiegatelo utilizzando localhost come destinazione. Se l'applicazione è configurata correttamente ed è in grado di rispondere, mostrerà lo stesso contenuto che avrebbe inviato ad un utente esterno (collegarsi a http://localhost via browser web, ad esempio, è proprio il modo in cui si sviluppano i siti web con Apache e PHP).

Da notare che alcune applicazioni impediscono al server di connettersi a se stesso, restituendo però un'errore specifico e diverso da quello generico che si ottiene in caso ci sia un problema di irraggiungibilità. Si noti ad esempio l'immagine riportata di seguito, catturata da un computer sul quale il servizio Desktop remoto funziona correttamente: il messaggio, seppure un po' criptico, è diverso da quello generico mostrato ad inizio articolo

Se questa prova si conclude con un nulla di fatto, è inutile litigare con il client su un altro computer: il problema è da ricercarsi localmente sul server.

3. Qualche altro client riesce a connettersi?

Se il server riesce a connettersi a se stesso ma uno specifico client no, è opportuno tentare il collegamento utilizzando un terzo dispositivo come client.

Per questo tipo di test, io preferisco usare il telefonino Android collegato alla stessa rete Wi-Fi del computer server. Sebbene si tratti di un sistema operativo basato su Linux, è una piattaforma piuttosto diversa da quelle per PC. Se nemmeno da smartphone il collegamento riesce, l'inghippo rimane sul server oppure a livello di rete. Se funziona, si può svolgere nuovamente la prova con un quarto device Windows, per poi analizzare le specifiche differenze di configurazione dei vari computer.

Un buon client gratuito per Desktop remoto compatibile con Android è PocketCloud. Per la lista delle applicazioni appropriate per testare altri tipi di servizio si veda "TurboLab.it Android Essentials". Su iOS o Windows Phone, ovviamente, è sufficiente localizzare software equivalenti.

4. Il client "vede" il server?

Quando il client non riesce a connettersi al server (il quale, però, non ha problemi a connettersi a se stesso) le probabilità che si tratti di un problema alla rete sono molto alte. Per prima cosa, è opportuno capire se i due host sono in grado di "vedersi".

La prova più diretta è lanciare un ping: avviare l'interfaccia da riga di comando e impartire ping 192.168.1.1, sostituendo a questo indirizzo IP quello specifico del server sul quale gira il servizio che stiamo diagnosticando (scoprire l'indirizzo IP con Windows / scoprire l'indirizzo IP con Linux CentOS / scoprirlo con altri sistemi). Se la risposta è sulla falsariga di Host di destinazione non raggiungibile, probabilmente le due macchine non sono in grado di parlarsi.

In questa situazione, è necessario verificare che gli indirizzi IP e le altre impostazioni di rete siano correttamente impostati. Il punto di partenza è "La Grande Guida alla condivisione di file in rete locale (LAN)".

5. Sul server, c'è un firewall che blocca le connessioni in ingresso?

Se il server si connette a se stesso, i client riescono a pingarlo ma ancora è impossibile raggiungere il servizio, il responsabile potrebbe essere un firewall in esecuzione sul server.

La soluzione corretta sul lungo termine prevede di capire quale sia la porta sulla quale "ascolta" il processo ed aprirla, ma per una verifica rapida è sufficiente disattivare completamente il software di protezione e riprovare.

La procedura varia a seconda del firewall scelto, ma abbiamo preparato alcuni approfondimenti specifici:

• Windows: "Guida: come disattivare Windows Firewall"
• Ubuntu: "Ubuntu, firewall e ufw: guida rapida per aprire le porte e bloccare gli IP"
• CentOS: "Linux CentOS: come disattivare il firewall"

6. Sul client, c'è un firewall che blocca le connessioni in uscita?

Come argomentato nell'articolo "TLI risponde: devo veramente installare un firewall sul PC oppure basta Windows Firewall?", la funzionalità principale di un firewall software in esecuzione sul PC client deve essere quella di regolare le connessioni in ingresso dall'esterno. Per questo motivo, Windows Firewall è saggiamente impostato per lasciar uscire qualsiasi programma senza alcuna limitazione. Altri prodotti, però, potrebbero aver optato per un comportamento più restrittivo, a causa del quale all'applicazione sul client potrebbe venir vietato l'accesso alla rete.

Anche in questo caso, la prova è di disabilitare temporaneamente il firewall. Nella specifica circostanza, però, agiremo sul client e non sul server.

7. Sul server remoto, c'è forse un router sul quale non è stata aperta l'opportuna porta?

Se, come raccomandato in apertura, siete riusciti a far funzionare tutto in rete locale ma avete problemi a replicare il successo via Internet, potreste aver dimenticato di configurare a dovere l'inoltro delle porte (port forwarding) sul router che consente al server di sfruttare la linea ADSL. In questo caso, consultare "Aprire le porte sul router: la guida definitiva".

Altri suggerimenti?

Ti sei scontrato anche tu con problemi di connessione client/server? se la risposta è "sì", condividi la tua esperienza tramite i commenti qui sotto: potresti aiutare qualcun altro! In particolare, puoi seguire questo schema:

1. ​Quali erano i programmi client/server che stavi cercando di far parlare?
2. Alla fine, qual era il problema?
3. Come sei arrivato a scoprire che il problema era proprio quello?
4. come hai risolto?