51 05/04/2026 07/04/2026 8 min

Risoluzione dei problemi di rete su RHEL, AlmaLinux e RockyLinux

Quando una macchina RHEL, AlmaLinux o RockyLinux “non va in rete”, la causa reale sta quasi sempre in uno dei livelli sotto: interfaccia, indirizzamento, routing, DNS, firewall, servizi di rete o upstream fisico/virtuale. L’errore tipico è partire subito da firewall e configurazioni complesse senza verificare prima lo stato del link e della tabella di routing.

Il metodo corretto è semplice: confermare il sintomo, identificare il layer rotto, raccogliere evidenza minima, applicare la modifica più piccola possibile e verificare subito l’effetto.

Sequenza di diagnosi: dal layer fisico al servizio

Se il problema è “sito giù”, “non raggiungo Internet”, “non risolve i nomi” o “SSH non risponde”, procedi in quest’ordine:

  1. Link e interfaccia
  2. IP e routing
  3. DNS
  4. Firewall e policy
  5. Servizio applicativo o demone di rete
  6. Upstream, switch, VLAN, hypervisor o provider

Questa sequenza evita cambi inutili e riduce il blast radius. Se il nodo è remoto, prima raccogli evidenze non invasive, poi modifica.

Verifica iniziale: interfaccia, link e indirizzo IP

Il primo controllo è vedere se l’interfaccia esiste, è UP e ha un indirizzo valido.

ip link show
ip addr show
nmcli device status
nmcli connection show --active

Interpretazione rapida:

  • INTERFACE DOWN: il link o la configurazione non è attiva.
  • NO-CARRIER: problema fisico, virtuale o lato switch/hypervisor.
  • IP assente: DHCP fallito, profilo NetworkManager errato o config statica mancante.
  • IP presente ma rete non va: passa a routing, DNS e firewall.

Su sistemi moderni RHEL-like, NetworkManager è il punto di controllo principale. Se l’interfaccia è corretta ma senza IP, verifica il profilo attivo:

nmcli connection show
nmcli connection show "NOME_PROFILO"

Se usi configurazioni statiche, controlla anche i file in /etc/NetworkManager/system-connections/ o i file legacy sotto /etc/sysconfig/network-scripts/ se presenti in ambienti più vecchi.

Routing: gateway, default route e percorsi mancanti

Se hai link e IP ma non esci dalla subnet, il problema è spesso nel routing. La verifica minima è:

ip route show
ip route get 8.8.8.8
ping -c 3 <gateway>

Casi frequenti:

  • manca la default route;
  • gateway errato o non raggiungibile;
  • tabella di routing sovrascritta da più profili o da DHCP;
  • policy routing che manda il traffico fuori dal percorso atteso.

Se ip route get mostra un’interfaccia sbagliata o un gateway non coerente, la causa è quasi sempre nel profilo NetworkManager o nella configurazione del provider/VLAN.

Correzione minima con NetworkManager:

nmcli connection modify "NOME_PROFILO" ipv4.gateway 192.0.2.1
nmcli connection modify "NOME_PROFILO" ipv4.method manual
nmcli connection up "NOME_PROFILO"

Se l’host usa DHCP, controlla che il server distribuisca gateway e DNS corretti. Se la modifica è locale, fai prima backup del profilo o annota il contenuto attuale con nmcli connection show "NOME_PROFILO".

Se il gateway risponde ma il traffico verso Internet no, il problema può essere a monte: NAT, ACL, routing upstream o policy del cloud provider.

DNS: il sistema funziona ma i nomi non si risolvono

Molti ticket di rete sono in realtà problemi DNS. Se ping 1.1.1.1 funziona ma ping google.com no, la connettività IP c’è: il guasto è nella risoluzione nomi.

resolvectl status
cat /etc/resolv.conf
getent hosts example.com
dig example.com +short

Su RHEL-like recenti /etc/resolv.conf può essere gestito da NetworkManager o systemd-resolved. Verifica quale resolver è realmente in uso, non solo il file statico.

Problemi tipici:

  • DNS sbagliato ricevuto via DHCP;
  • resolver interno non raggiungibile;
  • record errati o TTL scaduto;
  • split DNS non coerente con VPN o rete aziendale;
  • search domain che genera risoluzioni inattese.

Se il DNS è errato, la correzione minima è aggiornare il profilo di rete:

nmcli connection modify "NOME_PROFILO" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli connection modify "NOME_PROFILO" ipv4.ignore-auto-dns yes
nmcli connection up "NOME_PROFILO"

Se il nodo usa DNS interni, non sostituirli con pubblici senza capire impatto su domini privati, AD, servizi interni e reverse lookup.

Firewall: pacchetti arrivano ma il servizio resta irraggiungibile

Su RHEL, AlmaLinux e RockyLinux il firewall predefinito è spesso firewalld. Un servizio può essere attivo ma non esposto sulla porta giusta. Prima di cambiare regole, verifica stato e zone:

systemctl status firewalld
firewall-cmd --state
firewall-cmd --get-active-zones
firewall-cmd --list-all

Se un servizio locale non risponde dall’esterno ma risponde in localhost, il firewall è un sospetto concreto. Verifica anche su quale indirizzo il demone ascolta:

ss -lntp
ss -lnup

Casi frequenti:

  • servizio in ascolto solo su 127.0.0.1;
  • porta non aperta nella zona corretta;
  • interfaccia nella zona sbagliata;
  • regole nftables/firewalld in conflitto con configurazioni manuali.

Per aprire una porta in modo controllato:

firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --reload
firewall-cmd --list-ports

Rollback rapido:

firewall-cmd --permanent --remove-port=443/tcp
firewall-cmd --reload

Se il sistema usa regole dirette o policy custom, esporta prima la configurazione attuale per avere un rollback chiaro.

NetworkManager: profili, rotte e VLAN

Molti problemi nascono da profili duplicati o non coerenti. NetworkManager può gestire rotte statiche, VLAN, bonding e bridge: basta un profilo incompleto per perdere connettività.

Controlli utili:

nmcli connection show
nmcli device show "NOME_DEVICE"
nmcli -f GENERAL,IP4,IP6 device show "NOME_DEVICE"

Se la macchina è in VLAN, verifica che l’interfaccia sia correttamente taggata e che lo switch/hypervisor esponga la VLAN prevista. In ambiente virtualizzato, un profilo corretto lato guest non basta se il port group o la vNIC del provider è errata.

Per una VLAN con NetworkManager:

nmcli connection add type vlan con-name vlan100 dev ens192 id 100 ip4 192.0.2.10/24 gw4 192.0.2.1

Se devi correggere una VLAN esistente, cambia solo il profilo interessato e verifica subito con ip addr e ip route.

Problemi con bonding, teaming e bridge

Bonding e bridge sono utili, ma complicano la diagnosi. Se perdi rete dopo aver configurato ridondanza o bridge per VM/container, verifica che i membri siano davvero UP e che il master sia coerente.

cat /proc/net/bonding/bond0
bridge link
ip link show type bridge

Segnali critici:

  • slave non agganciati al bond;
  • stato down su una delle interfacce fisiche;
  • STP o bridge che blocca il traffico;
  • MTU incoerente tra bond, bridge e uplink.

Se il problema è nato da una modifica recente, la mitigazione più sicura è tornare alla configurazione precedente del profilo o disabilitare temporaneamente il bridge/bond nuovo, non inventare correzioni multiple insieme.

MTU e frammentazione: rete “quasi” funzionante

Quando alcuni servizi vanno e altri no, soprattutto con VPN, overlay, storage remoto o cloud, controlla l’MTU. Un MTU incoerente produce sintomi intermittenti: ping piccoli ok, HTTP/TLS bloccati o lenti.

ip link show
ping -M do -s 1472 8.8.8.8

Se il ping con payload grande fallisce ma quello piccolo no, sospetta MTU, PMTU blackhole o filtri ICMP. Verifica coerenza tra interfaccia fisica, VLAN, tunnel e bridge.

Correzione minima: allinea l’MTU sul percorso completo, non solo sulla NIC finale. Se non hai certezza del valore corretto, raccogli prima la configurazione del provider o dell’apparato upstream.

SELinux: non è la prima causa, ma va verificato

Su RHEL-like SELinux può bloccare binding, accessi o handshake apparentemente “di rete”. Se il servizio ascolta ma non risponde come previsto, verifica gli audit log.

getenforce
ausearch -m avc -ts recent
journalctl -t setroubleshoot --since "1 hour ago"

Non disabilitare SELinux come prima mossa. Se un contesto è errato, correggi etichette o policy. Esempi tipici: web server che non può connettersi a un backend, demone che non legge una porta non standard, contenuti serviti da path con label sbagliata.

Per file e directory, controlla contesto e ripristino label:

ls -Z /percorso
restorecon -Rv /percorso

Diagnosi del servizio di rete e log utili

Quando il problema sembra “di rete” ma riguarda il demone, guarda i log del servizio e lo stato systemd.

systemctl status NetworkManager
systemctl status firewalld
journalctl -u NetworkManager -b
journalctl -u firewalld -b

Per servizi applicativi, sostituisci con il nome del demone interessato. La combinazione di systemctl status e journalctl -b ti dice spesso se il problema è fallimento di avvio, porta occupata, configurazione errata o dipendenza non pronta.

Se un servizio continua a fallire dopo il restart, non insistere con riavvii ripetuti: identifica il messaggio d’errore preciso e la dipendenza mancante.

Checklist rapida in produzione

Quando devi ridurre il tempo di diagnosi, usa questa sequenza:

  1. Conferma il sintomo: curl -I, ping, dig, accesso SSH o reachability verso una porta specifica.
  2. Controlla link e IP: ip link, ip addr.
  3. Controlla route: ip route, ip route get.
  4. Controlla DNS: getent hosts, resolvectl status.
  5. Controlla ascolto e firewall: ss -lntp, firewall-cmd --list-all.
  6. Controlla log: journalctl -b, log applicativi, audit SELinux.

Questa sequenza copre la maggior parte dei casi reali senza toccare la macchina più del necessario.

Errori comuni da evitare

  • Riavviare subito l’interfaccia senza salvare lo stato attuale.
  • Disabilitare firewall o SELinux per “provare” in produzione senza rollback definito.
  • Modificare DNS, route e firewall insieme: poi non sai cosa ha funzionato.
  • Ignorare il layer fisico o virtuale e fermarsi alla config OS.
  • Non verificare la zona di firewalld associata all’interfaccia.
  • Confondere connettività IP con risoluzione DNS.

Approccio consigliato per un fix sicuro

Se devi intervenire, applica una sola modifica alla volta, preferibilmente sul profilo NetworkManager o sulla regola firewall interessata. Prima salva lo stato attuale, poi esegui il change, poi verifica con un test semplice e ripetibile.

nmcli connection show "NOME_PROFILO"
firewall-cmd --list-all
ip route
ss -lntp

Se il fix non produce effetto in pochi minuti, torna indietro e cambia ipotesi. In rete, i problemi “misti” esistono, ma la diagnosi efficace resta sempre una verifica per layer.

Assunzione: i comandi e i path indicati sono validi per una installazione standard RHEL 8/9 e derivate AlmaLinux/RockyLinux con NetworkManager e firewalld attivi.