dnsmasq nu poate lega portul 53: găsiți socketul care îl deține

dnsmasq se termină cu eroarea că adresa este deja utilizată, iar jurnalul numește portul în locul vinovatului. Pe o mașină care rulează și un VPN, reflexul este să dăm vina pe rutele împinse, dar o eroare de bind apare înainte ca vreun client să trimită o interogare. Ceva deține deja socketul, iar sarcina este să identificăm acel ceva. Modificările de rută nu pot elibera un port.

Cinci pași, în această ordine: reproduceți eroarea, listați ascultătorii, înțelegeți wildcardul, atribuiți sarcina și apoi verificați.

Pasul 1: reproduceți și citiți eroarea

Porniți dnsmasq în prim-plan cu aceeași configurație pe care o folosește serviciul, astfel încât eroarea să apară în terminalul dumneavoastră, nu într-un jurnal pe care trebuie să îl ghiciți. Observați familia de adrese și adresa locală din mesaj. Un bind pe o adresă anume și un bind pe wildcard sunt erori diferite, cu proprietari diferiți.

Păstrați textul exact. O adresă în uz, o eroare de permisiuni și o interfață lipsă sosesc toate ca eroare de pornire și indică trei reparații diferite.

Pasul 2: listați proprietarii

Listați mai întâi socketurile. Un filtru pe portul sursă 53 arată ambele transporturi și procesul proprietar atunci când aveți privilegiul de a vedea asta:

ss -lntup 'sport = :53'

Citiți rezultatul pe coloane: transport, adresă locală, port, proces. Un ascultător TCP și un ascultător UDP sunt socketuri separate, așa că oprirea unuia nu îl eliberează pe celălalt. O adresă wildcard acoperă fiecare interfață, ceea ce înseamnă că adresa VPN este deja ocupată chiar dacă nicio linie nu o numește. Iar numele procesului vă spune dacă este un resolver administrat de distribuție, un container sau ceva lăsat să ruleze de un experiment anterior.

Pasul 3: capcana wildcard

Opțiunea bind-interfaces schimbă dacă dnsmasq leagă un socket wildcard sau câte un socket pentru fiecare interfață configurată, după cum descrie referința dnsmasq. Fără ea, dnsmasq poate lega wildcardul și poate filtra cererile după interfață, ceea ce eșuează imediat când alt demon deține wildcardul. Linux adaugă bind-dynamic, care tratează interfețele create după pornire, o preocupare reală când interfața VPN apare doar la conectare.

De aceea doi demoni care par amândoi configurați pentru interfețe diferite tot se ciocnesc. Conflictul este la socket, nu la intenție. Alegeți modul de bind în cunoștință de cauză și citiți comportamentul documentat pentru versiunea dumneavoastră înainte de a-l schimba.

Pasul 4: atribuiți sarcina

Decideți care demon răspunde clienților VPN și care răspunde gazdei. Un resolver care ascultă pe adresa tunelului și redirecționează în amonte este o aranjare obișnuită; doi resolvers care fiecare presupune că deține portul 53 nu este deloc o aranjare.

Apoi exprimați această decizie în configurația fiecărui serviciu: adrese de ascultare, filtre de interfață și redirecționare. Modificați-le prin proprietarul serviciului, fie că este unitatea distribuției, managerul de rețea sau runtime-ul containerelor, pentru ca modificarea să supraviețuiască unei reporniri.

Pasul 5: verificați socketul, apoi calea

După repornire, confirmați că socketurile dorite există înainte de a testa un client. Un demon care nu s-a legat niciodată nu poate fi salvat de o rută, iar o eroare de client față de un socket legat corect este altă problemă, cu altă soluție. Apoi verificați accesibilitatea de la un client din tunel. Abia după aceea merită să întrebați dacă numele necesare se rezolvă.

Trei rezultate separate care trebuie ținute distincte: socketul există, clientul ajunge la el, răspunsul este corect.

Ce să nu faceți

Nu opriți un resolver necunoscut pentru a elibera portul fără să știți de ce depinde, pentru că interogările gazdei înseși depind de obicei. Nu copiați o rețetă veche care mută al doilea demon pe o adresă de ascultare publică, fiindcă asta decide ca efect secundar cine vă poate interoga. Și nu adăugați redirecționare când eroarea era locală.

Dacă mașina este administrată, notați decizia de proprietate acolo unde o va găsi următorul administrator. Conflictele de port revin de fiecare dată când o imagine este reconstruită.