dnsmasq nevar piesaistīt 53. portu: atrodiet ligzdu, kas to tur

dnsmasq beidzas ar kļūdu, ka adrese jau tiek izmantota, un žurnāls nosauc portu, nevis vainīgo. Mašīnā, kurā darbojas arī VPN, pirmā reakcija ir vainot piespiestos maršrutus, taču bind kļūda notiek pirms tam, kad kāds klients nosūta vaicājumu. Kaut kas jau tur ligzdu, un uzdevums ir to identificēt. Maršrutu izmaiņas nevar atbrīvot portu.

Pieci soļi šādā secībā: reproducējiet kļūdu, uzskaitiet klausītājus, saprotiet wildcard, piešķiriet uzdevumu un pēc tam pārbaudiet.

1. solis: reproducēt un izlasīt kļūdu

Palaidiet dnsmasq priekšplānā ar to pašu konfigurāciju, ko izmanto pakalpojums, lai kļūda parādītos jūsu terminālī, nevis žurnālā, kas jums jāuzmin. Pievērsiet uzmanību adrešu saimei un vietējai adresei ziņojumā. Piesaiste konkrētai adresei un piesaiste wildcard ir dažādas neveiksmes ar dažādiem īpašniekiem.

Saglabājiet precīzu tekstu. Izmantotā adrese, atļaujas kļūda un trūkstoša saskarne visi nāk kā palaišanas neveiksme, un tie norāda uz trim dažādiem labojumiem.

2. solis: uzskaitīt īpašniekus

Vispirms uzskaitiet ligzdas. Filtrs pēc avota porta 53 parāda abus transportus un īpašniekprocesu, ja jums ir tiesības to redzēt:

ss -lntup 'sport = :53'

Lasiet izvadi pa kolonnām: transports, vietējā adrese, ports, process. TCP klausītājs un UDP klausītājs ir atsevišķas ligzdas, tāpēc vienas apturēšana neatsbrīvo otru. Wildcard adrese aptver katru saskarni, kas nozīmē, ka VPN adrese jau ir aizņemta, pat ja neviena rinda to nenosauc. Un procesa nosaukums pasaka, vai tas ir izplatīšanas pārvaldīts resolveris, konteiners vai kaut kas, ko atstājis darboties iepriekšējais eksperiments.

3. solis: wildcard slazds

Opcija bind-interfaces maina, vai dnsmasq piesaista wildcard ligzdu vai vienu ligzdu katrai konfigurētajai saskarnei, kā apraksta dnsmasq rokasgrāmata. Bez tās dnsmasq var piesaistīt wildcard un tā vietā filtrēt pieprasījumus pēc saskarnes, kas nekavējoties neizdodas, ja wildcard tur cits dēmons. Linux pievieno bind-dynamic, kas apstrādā pēc palaišanas izveidotās saskarnes, reālas rūpes, ja VPN saskarne parādās tikai savienojoties.

Tāpēc divi dēmoni, kuri abi izskatās konfigurēti dažādām saskarnēm, tomēr saduras. Konflikts ir ligzdā, nevis nodomā. Apzināti izvēlieties piesaistes režīmu un pirms tā maiņas izlasiet savai versijai dokumentēto uzvedību.

4. solis: piešķirt uzdevumu

Izlemiet, kurš dēmons atbild VPN klientiem un kurš resursdatoram. Viens resolveris, kas klausās tuneļa adresē un pārsūta uz augšu ir ierasta kārtība; divi resolveri, no kuriem katrs pieņem, ka tam pieder 53. ports, nemaz nav kārtība.

Pēc tam izsakiet šo lēmumu katra pakalpojuma konfigurācijā: klausīšanās adreses, saskarņu filtri un pārsūtīšana. Mainiet tos caur pakalpojuma īpašnieku, vai tas būtu izplatīšanas units, tīkla pārvaldnieks vai konteineru izpildlaiks, lai izmaiņas pārdzīvotu restartu.

5. solis: pārbaudīt ligzdu, pēc tam ceļu

Pēc restarta apstipriniet, ka paredzētās ligzdas pastāv, pirms testējat klientu. Dēmonu, kas nekad nav piesaistījies, nevar glābt ar maršrutu, un klienta neveiksme pret pareizi piesaistītu ligzdu ir cita problēma ar citu risinājumu. Pēc tam pārbaudiet sasniedzamību no klienta tunelī. Tikai pēc tam ir vērts jautāt, vai nepieciešamie nosaukumi tiek atrisināti.

Trīs atsevišķi rezultāti, kas jāšķir: ligzda pastāv, klients to sasniedz, atbilde ir pareiza.

Ko nedarīt

Neapturiet nepazīstamu resolveri, lai atbrīvotu portu, nezinot, kas no tā ir atkarīgs, jo paša resursdatora vaicājumi parasti ir atkarīgi. Nekopējiet vecu recepti, kas pārvieto otro dēmonu uz publisku klausīšanās adresi, jo tas kā blakusefekts izlemj, kas drīkst jums uzdot vaicājumus. Un nepievienojiet pārsūtīšanu, ja neveiksme bija lokāla.

Ja mašīna tiek pārvaldīta, pierakstiet īpašumtiesību lēmumu tur, kur to atradīs nākamais administrators. Portu konflikti atgriežas katru reizi, kad attēls tiek pārbūvēts.