dnsmasq 53 portunu bağlaya bilmir: onu tutan soketi tapın

dnsmasq artıq istifadədə olan ünvan xətası ilə çıxır və jurnal günahkarı deyil, portu göstərir. VPN də işlədən maşında ilk reaksiya ötürülən marşrutları günahlandırmaqdır, lakin bağlama xətası hər hansı müştəri sorğu göndərməzdən əvvəl baş verir. Nə isə artıq soketi tutur və vəzifə onu müəyyən etməkdir. Marşrut dəyişiklikləri portu azad edə bilməz.

Bu ardıcıllıqla beş addım: xətanı təkrar et, dinləyiciləri siyahıya al, wildcard ünvanını anla, vəzifəni təyin et, sonra yoxla.

Addım 1: xətanı təkrar et və oxu

dnsmasq-ı xidmətin istifadə etdiyi eyni konfiqurasiya ilə ön planda başladın ki, xəta təxmin etməli olduğunuz jurnalda deyil, terminalınızda görünsün. Mesajdakı ünvan ailəsini və yerli ünvanı qeyd edin. Müəyyən bir ünvana bağlama ilə wildcard ünvanına bağlama fərqli sahibləri olan fərqli xətalardır.

Dəqiq mətni saxlayın. Ünvanın istifadədə olması, icazə xətası və olmayan interfeys hamısı başlatma xətası kimi gəlir və üç fərqli təmirə işarə edir.

Addım 2: sahibləri siyahıya al

Əvvəlcə soketləri siyahıya alın. Mənbə portu 53 üzrə filtr görmək səlahiyyətiniz olduqda hər iki nəqliyyatı və sahib prosesi göstərir:

ss -lntup 'sport = :53'

Çıxışı sütunlarla oxuyun: nəqliyyat, yerli ünvan, port, proses. TCP dinləyicisi və UDP dinləyicisi ayrı soketlərdir, ona görə birini dayandırmaq digərini azad etmir. Wildcard ünvanı bütün interfeysləri əhatə edir, yəni heç bir sətir adı ilə qeyd etməsə də VPN ünvanı artıq tutulub. Proses adı isə bunun distribusiya tərəfindən idarə olunan resolver, konteyner yoxsa əvvəlki təcrübədən qalan bir şey olduğunu bildirir.

Addım 3: wildcard tələsi

bind-interfaces seçimi dnsmasq-ın wildcard soketi yoxsa hər konfiqurasiya edilmiş interfeys üçün bir soket bağladığını dəyişir; dnsmasq sənədi bunu təsvir edir. Bu seçim olmadan dnsmasq wildcard ünvanını bağlaya və sorğuları interfeysə görə filtrləyə bilər, bu da başqa bir demon wildcard ünvanını tutanda dərhal uğursuz olur. Linux bind-dynamic seçimini əlavə edir; bu, işə salındıqdan sonra yaradılan interfeyslərlə işləyir və VPN interfeysi yalnız qoşulma zamanı görünəndə real problemə çevrilir.

Buna görə fərqli interfeyslər üçün konfiqurasiya edilmiş kimi görünən iki demon yenə də toqquşur. Ziddiyyət niyyətdə deyil, soketdədir. Bağlama rejimini qəsdən seçin və dəyişməzdən əvvəl versiyanız üçün sənədləşdirilmiş davranışı oxuyun.

Addım 4: vəzifəni təyin et

Hansı demonun VPN müştərilərinə, hansının isə hosta cavab verdiyini qərarlaşdırın. Tunel ünvanında dinləyib yuxarıya yönləndirən bir resolver geniş yayılmış bir quruluşdur; hər biri 53 portuna sahib olduğunu zənn edən iki resolver isə heç bir quruluş deyil.

Sonra bu qərarı hər xidmətin öz konfiqurasiyasında ifadə edin: dinləmə ünvanları, interfeys filtrləri və yönləndirmə. Onları xidmətin sahibi vasitəsilə dəyişin, istər distribusiya vahidi, istər şəbəkə meneceri, istərsə də konteyner runtimeu olsun ki, dəyişiklik yenidən başlatmadan sonra da qalsın.

Addım 5: əvvəlcə soketi, sonra yolu yoxla

Yenidən başlatmadan sonra müştərini sınaqdan keçirməzdən əvvəl nəzərdə tutulan soketlərin mövcud olduğunu təsdiqləyin. Heç vaxt bağlanmayan demonu marşrutla xilas etmək olmaz və düzgün bağlanmış soketə qarşı müştəri xətası fərqli düzəlişi olan fərqli problemdir. Sonra tuneldəki müştəridən əlçatanlığı yoxlayın. Yalnız bundan sonra tələb olunan adların həll olunub-olunmadığını soruşmağa dəyər.

Ayrı saxlanmalı üç nəticə: soket mövcuddur, müştəri ona çatır, cavab düzgündür.

Nə etməməli

Portu azad etmək üçün nədən asılı olduğunu bilmədən tanımadığınız bir resolveri dayandırmayın, çünki hostun öz sorğuları adətən ondan asılıdır. İkinci demonu ictimai dinləmə ünvanına köçürən köhnə resepti köçürməyin, çünki bu, yan təsir kimi kimin sizə sorğu verə biləcəyini həll edir. Və xəta yerli idisə, yönləndirmə əlavə etməyin.

Maşın idarə olunursa, sahiblik qərarını növbəti administratorun tapa biləcəyi yerdə qeyd edin. Port toqquşmaları hər dəfə obraz yenidən qurulanda qayıdır.