dnsmasq non riesce a legare la porta 53: trovate il socket che la occupa

dnsmasq termina con un errore di indirizzo già in uso, e il registro nomina la porta invece del colpevole. Su una macchina che esegue anche una VPN, il riflesso è dare la colpa alle rotte spinte, ma un errore di bind avviene prima che qualsiasi client invii una query. Qualcosa tiene già il socket, e il compito è identificarlo. I cambi di rotta non possono liberare una porta.

Cinque passaggi, in questo ordine: riprodurre l’errore, elencare gli ascoltatori, capire il wildcard, assegnare il compito, poi verificare.

Passaggio 1: riprodurre e leggere l’errore

Avviate dnsmasq in primo piano con la stessa configurazione usata dal servizio, così l’errore compare nel vostro terminale invece che in un registro da indovinare. Annotate la famiglia di indirizzi e l’indirizzo locale nel messaggio. Un bind su un indirizzo specifico e un bind sul wildcard sono errori diversi con proprietari diversi.

Conservate il testo esatto. Un indirizzo in uso, un errore di permessi e un’interfaccia mancante arrivano tutti come errore di avvio, e indicano tre riparazioni diverse.

Passaggio 2: elencare i proprietari

Elencate prima i socket. Un filtro sulla porta di origine 53 mostra entrambi i trasporti e il processo proprietario quando avete il privilegio di vederlo:

ss -lntup 'sport = :53'

Leggete l’output in colonne: trasporto, indirizzo locale, porta, processo. Un ascoltatore TCP e un ascoltatore UDP sono socket separati, quindi fermarne uno non libera l’altro. Un indirizzo wildcard copre ogni interfaccia, il che significa che l’indirizzo della VPN è già occupato anche se nessuna riga lo nomina. E il nome del processo vi dice se si tratta di un resolver gestito dalla distribuzione, di un container o di qualcosa che un esperimento precedente ha lasciato in esecuzione.

Passaggio 3: la trappola del wildcard

L’opzione bind-interfaces cambia se dnsmasq lega un socket wildcard o un socket per interfaccia configurata, come descrive la documentazione di dnsmasq. Senza di essa, dnsmasq può legare il wildcard e filtrare le richieste per interfaccia, il che fallisce subito quando un altro demone tiene il wildcard. Linux aggiunge bind-dynamic, che gestisce le interfacce create dopo l’avvio, un problema reale quando l’interfaccia della VPN compare solo al collegamento.

Per questo due demoni che sembrano entrambi configurati per interfacce diverse entrano comunque in collisione. Il conflitto è sul socket, non sull’intenzione. Scegliete la modalità di bind deliberatamente e leggete il comportamento documentato per la vostra versione prima di cambiarla.

Passaggio 4: assegnare il compito

Decidete quale demone risponde ai client VPN e quale all’host. Un resolver che ascolta sull’indirizzo del tunnel e inoltra a monte è una disposizione comune; due resolver che ciascuno presume di possedere la porta 53 non è affatto una disposizione.

Poi esprimete quella decisione nella configurazione di ogni servizio: indirizzi di ascolto, filtri di interfaccia e inoltro. Modificateli tramite il proprietario del servizio, che sia l’unità della distribuzione, il gestore di rete o il runtime dei container, così la modifica sopravvive a un riavvio.

Passaggio 5: verificare il socket, poi il percorso

Dopo il riavvio, confermate che i socket previsti esistano prima di provare un client. Un demone che non ha mai legato non può essere salvato da una rotta, e un errore del client contro un socket legato correttamente è un altro problema con un’altra soluzione. Poi controllate la raggiungibilità da un client sul tunnel. Solo dopo vale la pena chiedersi se i nomi richiesti si risolvono.

Tre risultati separati da tenere distinti: il socket esiste, il client lo raggiunge, la risposta è corretta.

Cosa non fare

Non fermate un resolver sconosciuto per liberare la porta senza sapere cosa ne dipende, perché le ricerche dell’host stesso di solito ne dipendono. Non copiate una vecchia ricetta che sposta il secondo demone su un indirizzo di ascolto pubblico, perché ciò decide come effetto collaterale chi può interrogarvi. E non aggiungete un inoltro quando l’errore era locale.

Se la macchina è gestita, annotate la decisione di proprietà dove la troverà il prossimo amministratore. I conflitti di porta tornano ogni volta che un’immagine viene ricostruita.