dnsmasq nie może związać portu 53: znajdź gniazdo, które go trzyma

dnsmasq kończy się błędem, że adres jest już w użyciu, a dziennik podaje port zamiast winowajcy. Na maszynie, na której działa też VPN, odruchem jest obwinianie wypchniętych tras, ale błąd bind występuje, zanim jakikolwiek klient wyśle zapytanie. Coś już trzyma gniazdo, a zadaniem jest to zidentyfikować. Zmiany tras nie uwolnią portu.

Pięć kroków w tej kolejności: odtwórz błąd, wypisz nasłuchujące procesy, zrozum wildcard, przydziel zadanie, a następnie zweryfikuj.

Krok 1: odtworzyć i odczytać błąd

Uruchom dnsmasq na pierwszym planie z tą samą konfiguracją, której używa usługa, aby błąd pojawił się w twoim terminalu, a nie w dzienniku, który musisz zgadywać. Zwróć uwagę na rodzinę adresów i adres lokalny w komunikacie. Bind na konkretny adres i bind na wildcard to różne błędy z różnymi właścicielami.

Zachowaj dokładny tekst. Adres w użyciu, błąd uprawnień i brakujący interfejs przychodzą wszystkie jako błąd uruchomienia i wskazują na trzy różne naprawy.

Krok 2: wypisać właścicieli

Najpierw wypisz gniazda. Filtr na porcie źródłowym 53 pokazuje oba transporty i proces będący właścicielem, gdy masz uprawnienia, by to zobaczyć:

ss -lntup 'sport = :53'

Czytaj wyjście w kolumnach: transport, adres lokalny, port, proces. Nasłuch TCP i nasłuch UDP to osobne gniazda, więc zatrzymanie jednego nie uwalnia drugiego. Adres wildcard obejmuje każdy interfejs, co oznacza, że adres VPN jest już zajęty, nawet jeśli żadna linia nie wymienia go z nazwy. A nazwa procesu mówi ci, czy to resolver zarządzany przez dystrybucję, kontener, czy coś, co poprzedni eksperyment zostawił uruchomione.

Krok 3: pułapka wildcard

Opcja bind-interfaces zmienia to, czy dnsmasq wiąże gniazdo wildcard, czy po jednym gniazdzie na każdy skonfigurowany interfejs, jak opisuje dokumentacja dnsmasq. Bez niej dnsmasq może związać wildcard i zamiast tego filtrować żądania według interfejsu, co natychmiast zawodzi, gdy wildcard trzyma inny demon. Linux dodaje bind-dynamic, który obsługuje interfejsy tworzone po starcie, realny problem, gdy interfejs VPN pojawia się dopiero przy połączeniu.

Dlatego dwa demony, które oba wyglądają na skonfigurowane dla różnych interfejsów, wciąż się zderzają. Konflikt jest przy gnieździe, nie przy zamiarze. Wybierz tryb wiązania świadomie i przeczytaj udokumentowane zachowanie dla swojej wersji, zanim go zmienisz.

Krok 4: przydzielić zadanie

Zdecyduj, który demon odpowiada klientom VPN, a który hostowi. Jeden resolver nasłuchujący na adresie tunelu i przekazujący w górę to typowy układ; dwa resolvery, z których każdy zakłada, że posiada port 53, to żaden układ.

Następnie wyraź tę decyzję w konfiguracji każdej usługi: adresy nasłuchu, filtry interfejsów i przekazywanie. Zmieniaj je przez właściciela usługi, czy to jednostkę dystrybucji, menedżera sieci, czy środowisko uruchomieniowe kontenerów, aby zmiana przetrwała restart.

Krok 5: zweryfikować gniazdo, potem ścieżkę

Po restarcie potwierdź, że zamierzone gniazda istnieją, zanim przetestujesz klienta. Demon, który nigdy się nie związał, nie może być uratowany przez trasę, a błąd klienta wobec poprawnie związanego gniazda to inny problem z inną naprawą. Następnie sprawdź osiągalność z klienta w tunelu. Dopiero potem warto pytać, czy wymagane nazwy się rozwiązują.

Trzy osobne wyniki, które trzeba rozdzielić: gniazdo istnieje, klient do niego dociera, odpowiedź jest poprawna.

Czego nie robić

Nie zatrzymuj nieznanego resolvera, aby uwolnić port, nie wiedząc, co od niego zależy, bo zapytania samego hosta zwykle zależą. Nie kopiuj starego przepisu, który przenosi drugi demon na publiczny adres nasłuchu, ponieważ to jako efekt uboczny decyduje, kto może cię pytać. I nie dodawaj przekazywania, gdy błąd był lokalny.

Jeśli maszyna jest zarządzana, zapisz decyzję o własności tam, gdzie znajdzie ją następny administrator. Konflikty portów wracają za każdym razem, gdy obraz jest przebudowywany.