dnsmasq baigia darbą su klaida, kad adresas jau naudojamas, o žurnalas nurodo prievadą, o ne kaltininką. Mašinoje, kurioje taip pat veikia VPN, pirmoji reakcija yra kaltinti stumiamus maršrutus, tačiau bind klaida įvyksta anksčiau, nei bet kuris klientas išsiunčia užklausą. Kažkas jau laiko socketą, o užduotis yra tai nustatyti. Maršrutų pakeitimai negali atlaisvinti prievado.

Penki žingsniai šia tvarka: atkurkite klaidą, išvardykite klausytojus, supraskite wildcard, paskirkite užduotį ir tada patikrinkite.

1 žingsnis: atkurti ir perskaityti klaidą

Paleiskite dnsmasq priekiniame plane su ta pačia konfigūracija, kurią naudoja tarnyba, kad klaida pasirodytų jūsų terminale, o ne žurnale, kurį reikia spėlioti. Atkreipkite dėmesį į adresų šeimą ir vietinį adresą pranešime. Susiejimas su konkrečiu adresu ir susiejimas su wildcard yra skirtingos nesėkmės su skirtingais savininkais.

Išsaugokite tikslų tekstą. Naudojamas adresas, leidimų klaida ir trūkstamas sąsaja visi ateina kaip paleidimo nesėkmė, ir jie nurodo tris skirtingus taisymus.

2 žingsnis: išvardyti savininkus

Pirmiausia išvardykite socketus. Filtras pagal šaltinio prievadą 53 rodo abu transportus ir valdantį procesą, kai turite teisę tai matyti:

ss -lntup 'sport = :53'

Skaitykite išvestį stulpeliais: transportas, vietinis adresas, prievadas, procesas. TCP klausytojas ir UDP klausytojas yra atskiri socketai, todėl sustabdžius vieną neatlaisvinamas kitas. Wildcard adresas apima kiekvieną sąsają, o tai reiškia, kad VPN adresas jau užimtas, net jei nė viena eilutė jo neįvardija. O proceso pavadinimas pasako, ar tai platinimo valdomas resolveris, konteineris, ar kažkas, ką paliko veikti ankstesnis eksperimentas.

3 žingsnis: wildcard spąstai

Parinktis bind-interfaces keičia, ar dnsmasq susieja wildcard socketą, ar po vieną socketą kiekvienai sukonfigūruotai sąsajai, kaip aprašo dnsmasq žinynas. Be jos dnsmasq gali susieti wildcard ir vietoj to filtruoti užklausas pagal sąsają, o tai iš karto nepavyksta, kai wildcard laiko kitas daemonas. Linux prideda bind-dynamic, kuris apdoroja po paleidimo sukurtas sąsajas, tikras rūpestis, kai VPN sąsaja atsiranda tik prisijungus.

Štai kodėl du daemonai, kurie abu atrodo sukonfigūruoti skirtingoms sąsajoms, vis tiek susiduria. Konfliktas yra sockete, o ne ketinime. Sąmoningai pasirinkite susiejimo režimą ir prieš keisdami perskaitykite savo versijai dokumentuotą elgseną.

4 žingsnis: paskirti užduotį

Nuspręskite, kuris daemonas atsako VPN klientams, o kuris pagrindiniam kompiuteriui. Vienas resolveris, kuris klausosi tunelio adrese ir persiunčia aukštyn yra įprasta tvarka; du resolveriai, kurių kiekvienas mano valdąs 53 prievadą, nėra jokia tvarka.

Tada išreikškite tą sprendimą kiekvienos tarnybos konfigūracijoje: klausymosi adresai, sąsajų filtrai ir persiuntimas. Keiskite juos per tarnybos savininką, ar tai būtų platinimo unitas, tinklo tvarkyklė ar konteinerių vykdymo aplinka, kad pakeitimas išliktų po paleidimo iš naujo.

5 žingsnis: patikrinti socketą, tada kelią

Po paleidimo iš naujo patvirtinkite, kad numatyti socketai egzistuoja, prieš testuodami klientą. Daemonas, kuris niekada nesusiejo, negali būti išgelbėtas maršrutu, o kliento nesėkmė prieš teisingai susietą socketą yra kita problema su kitu sprendimu. Tada patikrinkite pasiekiamumą iš kliento tunelyje. Tik po to verta klausti, ar reikalingi vardai išsprendžiami.

Trys atskiri rezultatai, kuriuos reikia skirti: socketas egzistuoja, klientas jį pasiekia, atsakymas teisingas.

Ko nedaryti

Nesustabdykite nepažįstamo resolverio, kad atlaisvintumėte prievadą, nežinodami, kas nuo jo priklauso, nes paties pagrindinio kompiuterio paieškos paprastai priklauso. Nekopijuokite seno recepto, kuris perkelia antrą daemoną į viešą klausymosi adresą, nes tai kaip šalutinis poveikis nusprendžia, kas gali jums užduoti užklausas. Ir nepridėkite persiuntimo, kai nesėkmė buvo vietinė.

Jei mašina valdoma, užrašykite nuosavybės sprendimą ten, kur jį ras kitas administratorius. Prievadų konfliktai grįžta kiekvieną kartą, kai atvaizdas sukuriamas iš naujo.

Susiję straipsniai