1,200 26/03/2026 07/04/2026 7 min

Succede spesso dopo un cambio rete fatto in fretta: il firewall sale, il traffico HTTP sembra vivo, ma i nomi non risolvono più o alcuni siti si piantano a metà caricamento. Il colpevole non è sempre il DNS. In scenari con nftables, routing asimmetrico e MTU 1450, basta poco per rompere i pacchetti frammentati o i reply DNS più grandi del solito.

Questo articolo parte dal caso peggiore: un host Linux dietro firewall, con reverse proxy e client interni, dopo una modifica a regole e interfacce perde la risoluzione o smette di raggiungere servizi esterni. L’obiettivo è capire cosa controllare, come fare rollback e come ripristinare in modo pulito.

Prerequisiti

  • Accesso root o sudo.
  • nftables attivo.
  • Un’interfaccia WAN o uplink con MTU non standard, tipicamente 1450.
  • Un resolver locale o remoto da testare, come systemd-resolved, Unbound o il DNS del provider.
  • Una sessione console o accesso out-of-band. Warning: se sbagli il rollback su un host remoto, puoi tagliarti fuori da solo.

Step numerati

1) Fotografare lo stato prima di toccare altro

Quando qualcosa si rompe, il primo errore è cambiare tre cose insieme. Prima salva lo stato corrente di regole, route e MTU. Ti serve per capire se il problema nasce dal firewall o dal trasporto.

nft list ruleset > /root/nft.before.txt
ip -br link
ip route show table main
resolvectl status 2>/root/resolvectl.before.txt

# Output:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
  }
}
eth0             UP             1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
10.10.0.1 dev eth0 proto static metric 100

Se vedi MTU 1500 sul link ma il path reale richiede 1450, hai già un indizio. Se le regole nft cambiano in parallelo, annota anche l’ultima modifica applicata.

2) Verificare se il guasto è DNS o PMTU

Molti confondono un problema DNS con un problema di Path MTU Discovery. Un nome può risolvere, ma la connessione TLS fallisce su pacchetti più grandi. Oppure il contrario: il resolver non risponde perché i pacchetti UDP frammentati vengono filtrati.

dig @1.1.1.1 example.com +tries=1 +time=2
ping -c 2 -M do -s 1472 1.1.1.1
tracepath 1.1.1.1

# Output:

;; communications error to 1.1.1.1#53: timed out
ping: local error: message too long, mtu=1450
 1?: [LOCALHOST]                      pmtu 1450
 2:  10.10.0.1                                         1.432ms

Se ping con DF fallisce oltre una certa soglia, il problema è quasi certamente MTU o ICMP filtrato. Se dig va in timeout ma ping piccolo funziona, controlla i filtri su UDP/53 e ICMP type 3 code 4.

3) Controllare il firewall senza fidarsi del “policy drop”

Con nftables il dettaglio conta. Un set, una chain o una regola di reject possono bloccare la frammentazione o i pacchetti di risposta. In particolare, se hai un reverse proxy dietro NAT, devi lasciare passare traffico esterno e reply correlati.

nft list ruleset | sed -n '/table inet filter/,/}/p'
nft list chain inet filter input
nft list chain inet filter forward

# Output:

ct state established,related accept
udp dport 53 accept
tcp dport 53 accept
ip protocol icmp accept

Se non vedi established,related prima del drop, il firewall può bloccare i reply. Se manca ICMP, la PMTU discovery può rompersi anche con regole apparentemente “aperte”.

4) Correggere MTU e MSS in modo coerente

In una rete con tunnel, VLAN o upstream che impone 1450, non basta abbassare l’MTU su un’interfaccia. Devi verificare anche il TCP MSS, altrimenti alcuni flussi continueranno a generare segmenti troppo grandi.

ip link set dev eth0 mtu 1450
nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu

# Output:

RTNETLINK answers: Success

Note: la seconda riga è un esempio concettuale. La sintassi esatta dipende dalla tua configurazione e dalla versione di nftables. In molti ambienti conviene usare il clamp MSS nel punto di egress del NAT, non in input.

Se gestisci il firewall da pannello, vai in Firewall → Regole personalizzate e cerca opzioni come TCP MSS clamping, Allow ICMP Fragmentation Needed o MTU fix. Il terminale resta utile per confermare il risultato reale sul link.

5) Ripristinare il DNS con un rollback minimo

Quando il DNS si rompe, non riscrivere tutto. Fai prima un rollback sul resolver o sulla regola che tocca UDP/53 e TCP/53. Se il problema è nato da un file applicato con nft -f, conserva una copia valida e ricaricala.

cp /root/nft.before.txt /root/nft.rollback.txt
nft -f /root/nft.rollback.txt
systemctl restart systemd-resolved
resolvectl flush-caches

# Output:

Flushing caches... done

Se usi un pannello come Plesk o un’interfaccia del provider, il percorso più veloce è spesso Servizi di rete → DNS resolver → Riavvia. Dopo, controlla che il file di configurazione non venga rigenerato da un template difettoso.

6) Ripristinare routing e NAT senza toccare il resto

Quando il routing è errato, il sintomo tipico è un servizio che risponde solo dall’interno oppure solo verso alcuni client. Qui il rollback deve essere chirurgico: route, policy routing e NAT vanno verificati separatamente.

ip rule show
ip route show table 100
nft list chain ip nat postrouting

# Output:

100: from 10.10.0.0/24 lookup 100
default via 10.10.0.254 dev eth0
ip saddr 10.10.0.0/24 oifname "eth0" masquerade

Se la default route sparisce dalla tabella giusta, il traffico può uscire da un’interfaccia sbagliata e tornare su un percorso diverso. Questo crea timeout intermittenti, molto difficili da leggere senza tcpdump.

7) Salvare una configurazione che si possa davvero ripristinare

Il ripristino migliore è quello che fai in due minuti alle tre di notte. Per questo conviene tenere una configurazione minima, commentata e separata dal resto. Evita file monolitici con regole sparse e dipendenze implicite.

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport 53 accept
    tcp dport 53 accept
    ip protocol icmp accept
  }
}

# Output:

ruleset loaded

Note: se il servizio è in produzione, testa prima con nft -c -f file.nft. Il controllo sintattico non basta a garantire la correttezza logica, ma evita di caricare regole rotte.

Verifica finale

Dopo il rollback o la correzione, verifica sempre tre cose: risoluzione, percorso e dimensione utile del pacchetto.

  • dig example.com deve rispondere in meno di pochi secondi.
  • tracepath deve mostrare una PMTU coerente con l’upstream.
  • curl -I https://example.com deve chiudersi senza reset o timeout.
dig example.com +short
tracepath example.com
curl -I https://example.com --max-time 5

# Output:

93.184.216.34
 1?: [LOCALHOST]                      pmtu 1450
HTTP/2 200

Se il DNS funziona ma HTTPS no, il problema è quasi sempre MTU, MSS o routing. Se HTTPS va e il DNS no, rivedi le regole UDP/53 e la catena di input.

Troubleshooting

Errore 1: dig: communications error to 1.1.1.1#53: timed out

Causa: UDP/53 o i reply correlati sono bloccati dal firewall, oppure il percorso frammentato viene scartato.

Fix:

nft insert rule inet filter input ct state established,related accept
nft insert rule inet filter input udp dport 53 accept

Errore 2: ping: local error: message too long, mtu=1450

Causa: l’MTU del link o del tunnel non è allineata al path reale.

Fix:

ip link set dev eth0 mtu 1450
tracepath 1.1.1.1

Errore 3: RTNETLINK answers: File exists

Causa: stai aggiungendo una route o una rule già presente, spesso dopo un tentativo di ripristino manuale.

Fix:

ip route del default via 10.10.0.254 dev eth0 table 100
ip route add default via 10.10.0.254 dev eth0 table 100

Conclusione

Quando DNS, routing e MTU si mescolano, il sintomo inganna. Il metodo giusto è isolare i livelli, fare rollback minimo e rimettere in ordine il percorso prima di toccare altro.

Il prossimo passo concreto è semplice: crea un file di backup del ruleset, annota la MTU reale dell’uplink e prepara un test dig + tracepath + curl da lanciare dopo ogni modifica.