Immagina di aver appena configurato un server, impostato un firewall e lanciato un servizio sulla porta 8080. Provi a connetterti dal browser, ma ricevi l'ennesimo errore di timeout. Il panico sale: è il servizio che non è partito? È il firewall che blocca tutto? O forse hai sbagliato IP?

Qui entra in gioco nc -zv.

Netcat, spesso definito il "coltellino svizzero" del networking, permette di fare cose incredibili. Ma per chi deve risolvere problemi di connessione velocemente, la combinazione dei flag -z e -v è quella che salva la giornata.

Cosa succede esattamente quando digiti nc -zv?

Andiamo al sodo. Se guardiamo il comando scomposto, capiamo subito perché è così efficace. Il flag -z dice a Netcat di scansionare senza inviare alcun dato. In pratica, gli diciamo: "Prova solo a stabilire la connessione, se riesci chiudila subito e dimmi se era possibile".

Il flag -v (verbose), invece, è ciò che rende l'operazione leggibile per un essere umano. Senza di esso, Netcat rimarrebbe in silenzio, lasciandoti a indovinare se il comando abbia funzionato o meno.

Unendo i due, ottieni uno strumento di diagnostica istantaneo.

La sintassi base è semplicissima: nc -zv [indirizzo_ip] [porta].

Esempi pratici per non sbagliare

Supponiamo di voler verificare se un server web remoto risponde sulla porta standard 80. Il comando sarà:

nc -zv google.com 80

Se tutto funziona, vedrai un messaggio simile a Connection to google.com port 80 [tcp/http] succeeded!. Semplice. Pulito. Diretto.

Ma cosa succede se la porta è chiusa? Riceverai un errore di Connection refused o, peggio, il comando rimarrà appeso finché non scatta il timeout. Quest'ultimo caso è il più interessante: indica quasi sempre che un firewall sta "droppando" i pacchetti, ignorandoli completamente invece di rifiutarli attivamente.

Un dettaglio non da poco: puoi testare più porte contemporaneamente. Non c'è bisogno di lanciare il comando dieci volte se devi controllare un range.

Prova così: nc -zv 192.168.1.10 20-80

Netcat scansionerà ogni singola porta tra la 20 e la 80, elencandoti quali sono aperte. È un modo rapido per mappare i servizi attivi su una macchina senza dover installare strumenti pesanti come Nmap.

Perché usare Netcat invece di altri tool?

Potresti chiederti: "Perché non uso Telnet?". Beh, Telnet è ormai un reperto archeologico. Molti sistemi moderni non lo hanno nemmeno installato di default. Netcat, invece, è ubiquitario su quasi ogni distribuzione Linux e macOS.

È leggero. Non richiede configurazioni complesse. Fa esattamente quello che gli chiedi.

C'è poi la questione della velocità. Quando sei in una sessione SSH remota e devi capire perché un database non risponde, non hai tempo di scaricare software di terze parti o configurare interfacce grafiche. Ti serve una riga di comando che dia una risposta binaria: aperto o chiuso.

Gestire i timeout per evitare attese infinite

C'è un problema comune con nc -zv. Se il server di destinazione è protetto da un firewall che scarta i pacchetti (DROP), Netcat potrebbe aspettare per un tempo infinito, o quasi, prima di darti un errore.

Questo è frustrante, specialmente quando scansionate intere subnet.

La soluzione? Aggiungere il flag -w seguito dal numero di secondi. Ad esempio:

nc -zv -w 2 192.168.1.50 443

In questo modo, se Netcat non riceve risposta entro 2 secondi, chiude la connessione e passa oltre. Un risparmio di tempo enorme.

UDP vs TCP: l'altra faccia della medaglia

Di default, Netcat lavora su TCP. Ma il mondo del networking non è fatto solo di TCP. Esiste l'UDP, fondamentale per DNS, DHCP e molti servizi di streaming o gaming.

Per testare una porta UDP, devi aggiungere il flag -u.

nc -zuv 8.8.8.8 53

Attenzione però: testare l'UDP è molto più complicato che testare il TCP. Perché? Perché l'UDP non prevede un "handshake" (la stretta di mano iniziale). In molti casi, Netcat ti dirà che la porta è aperta anche se non lo è, semplicemente perché non ha ricevuto un pacchetto ICMP di errore dal server.

Non fidarti ciecamente dei risultati UDP. Verifica sempre con i log del servizio o inviando un pacchetto reale.

Errori comuni e come risolverli

A volte, digitando nc -zv, potresti ricevere l'errore command not found. Succede più spesso di quanto si pensi su alcune installazioni minimali di Ubuntu o Debian.

La soluzione è banale: installa il pacchetto necessario. A seconda della distro, potrebbe chiamarsi netcat, netcat-openbsd o nmap-ncat.

  • Su Ubuntu/Debian: sudo apt install netcat-openbsd
  • Su CentOS/RHEL: sudo yum install nc

Un altro intoppo riguarda i permessi. In generale, per scansionare porte remote non servono privilegi di root. Ma se provi a fare operazioni più avanzate (come ascoltare su una porta inferiore alla 1024), dovrai usare sudo.

Oltre lo scanning: l'utilità di Netcat nel debugging

Una volta capito che la porta è aperta tramite nc -zv, potresti voler vedere cosa risponde effettivamente il server. In questo caso, basta togliere il flag -z.

Se scrivi nc -v google.com 80 e poi premi Invio, sarai connesso al server. A quel punto puoi digitare manualmente una richiesta HTTP, come:

GET / HTTP/1.1 [Invio] Host: google.com [Invio][Invio]

Vedrai scorrere il codice HTML della pagina direttamente nel terminale. È un modo brutale ma efficace per capire se un server web sta rispondendo correttamente o se restituisce errori 500 prima ancora di aprire un browser.

Proprio così, Netcat ti permette di simulare un client senza avere il client vero e proprio.

Riepilogo rapido dei comandi

Per chi vuole solo copiare e incollare, ecco i casi d'uso più frequenti:

  • Test singola porta: nc -zv [IP] [PORTA]
  • Test range di porte: nc -zv [IP] [INIZIO-FINE]
  • Test con timeout (consigliato): nc -zvw 2 [IP] [PORTA]
  • Test porta UDP: nc -zuv [IP] [PORTA]

Usare correttamente questi strumenti trasforma un'ora di tentativi a caso in cinque secondi di certezza tecnica. Non c'è nulla di più soddisfacente che vedere quel succeeded! apparire sullo schermo dopo che hai passato mezz'ora a combattere con le regole del firewall.