dnsmasq ne povas ligi pordon 53: trovu la soketon, kiu ĝin posedas

dnsmasq finiĝas per eraro, ke la adreso jam estas uzata, kaj la protokolo nomas la pordon anstataŭ la kaŭzanton. Sur maŝino, kiu ankaŭ funkciigas VPN, la unua impulso estas kulpigi la puŝitajn vojojn, sed malsukceso de ligo okazas antaŭ ol iu ajn kliento sendas peton. Io jam tenas la soketon, kaj la tasko estas identigi ĝin. Vojŝanĝoj ne povas liberigi pordon.

Kvin paŝoj en ĉi tiu ordo: reproduktu la eraron, listigu la aŭskultantojn, komprenu la ĵokeran adreson, asignu la taskon, poste kontrolu.

Paŝo 1: reproduktu kaj legu la eraron

Startigu dnsmasq en la antaŭa plano kun la sama agordo, kiun uzas la servo, por ke la eraro aperu en via terminalo anstataŭ en protokolo, kiun vi devas diveni. Rimarku la adresan familion kaj la lokan adreson en la mesaĝo. Ligo al specifa adreso kaj ligo al la ĵokera adreso estas malsamaj malsukcesoj kun malsamaj posedantoj.

Konservu la precizan tekston. Adreso jam uzata, malsukceso de permeso kaj mankanta interfaco ĉiuj alvenas kiel malsukceso starti, kaj ili montras al tri malsamaj riparoj.

Paŝo 2: listigu la posedantojn

Unue listigu la soketojn. Filtrilo laŭ fonta pordo 53 montras ambaŭ transportojn kaj la posedan procezon, kiam vi havas la privilegion vidi ĝin:

ss -lntup 'sport = :53'

Legu la eligon laŭ kolumnoj: transporto, loka adreso, pordo, procezo. TCP-aŭskultanto kaj UDP-aŭskultanto estas apartaj soketoj, do haltigi unu ne liberigas la alian. Ĵokera adreso kovras ĉiun interfacon, kio signifas, ke la VPN-adreso jam estas okupita eĉ se neniu linio nomas ĝin. Kaj la nomo de la procezo diras al vi, ĉu temas pri distribuo-administrata solvilo, ujo aŭ io, kion antaŭa eksperimento lasis funkcii.

Paŝo 3: la kaptilo de la ĵokera adreso

La opcio bind-interfaces ŝanĝas, ĉu dnsmasq ligas ĵokeran soketon aŭ unu soketon por ĉiu agordita interfaco, kiel priskribas la referenco pri dnsmasq. Sen ĝi dnsmasq povas ligi la ĵokeran adreson kaj anstataŭe filtri petojn laŭ interfaco, kio tuj malsukcesas, kiam alia demono tenas la ĵokeran adreson. Linux aldonas bind-dynamic, kiu traktas interfacojn kreitajn post la starto, reala zorgo kiam la VPN-interfaco aperas nur ĉe konekto.

Tial du demonoj, kiuj ambaŭ aspektas agorditaj por malsamaj interfacoj, tamen kolizias. La konflikto estas ĉe la soketo, ne ĉe la intenco. Elektu la ligan reĝimon konscie kaj legu la dokumentitan konduton por via versio antaŭ ol ŝanĝi ĝin.

Paŝo 4: asignu la taskon

Decidu, kiu demono respondas al VPN-klientoj kaj kiu al la gastiganto. Unu solvilo, kiu aŭskultas ĉe la tunela adreso kaj plusendas supren estas kutima aranĝo; du solviloj, el kiuj ĉiu supozas, ke ĝi posedas pordon 53, tute ne estas aranĝo.

Poste esprimu tiun decidon en la agordo de ĉiu servo: aŭskultaj adresoj, interfacaj filtriloj kaj plusendado. Ŝanĝu ilin per la posedanto de la servo, ĉu temas pri la distribua unuo, la retadministrilo aŭ la uja plenummedio, por ke la ŝanĝo postvivu restartigon.

Paŝo 5: kontrolu la soketon, poste la vojon

Post la restartigo konfirmu, ke la celitaj soketoj ekzistas antaŭ ol testi klienton. Demono, kiu neniam ligiĝis, ne povas esti savita per vojo, kaj klienta malsukceso kontraŭ ĝuste ligita soketo estas alia problemo kun alia solvo. Poste kontrolu atingeblon de kliento en la tunelo. Nur post tio indas demandi, ĉu la bezonataj nomoj solviĝas.

Tri apartaj rezultoj tenendaj aparte: la soketo ekzistas, la kliento atingas ĝin, la respondo estas ĝusta.

Kion ne fari

Ne haltigu nekonatan solvilon por liberigi la pordon sen scii, kio dependas de ĝi, ĉar la propraj serĉoj de la gastiganto kutime dependas. Ne kopiu malnovan recepton, kiu movas la duan demonon al publika aŭskulta adreso, ĉar tio kiel flanka efiko decidas, kiu rajtas demandi vin. Kaj ne aldonu plusendadon, kiam la malsukceso estis loka.

Se la maŝino estas administrata, registru la posedan decidon tie, kie la sekva administranto trovos ĝin. Pordokonfliktoj revenas ĉiufoje, kiam bildo estas rekonstruita.