dnsmasq không thể liên kết cổng 53: tìm socket đang giữ cổng đó

dnsmasq thoát với lỗi địa chỉ đã được sử dụng, và nhật ký nêu tên cổng thay vì thủ phạm. Trên máy cũng chạy VPN, phản xạ đầu tiên là đổ lỗi cho các tuyến đường được đẩy xuống, nhưng lỗi bind xảy ra trước khi bất kỳ máy khách nào gửi truy vấn. Đã có thứ gì đó giữ socket, và việc cần làm là xác định nó. Thay đổi tuyến đường không thể giải phóng một cổng.

Năm bước, theo thứ tự này: tái hiện lỗi, liệt kê trình lắng nghe, hiểu wildcard, giao việc, rồi kiểm chứng.

Bước 1: tái hiện và đọc lỗi

Khởi động dnsmasq ở tiền cảnh với cùng cấu hình mà dịch vụ dùng, để lỗi hiện ra trong terminal của bạn thay vì trong nhật ký mà bạn phải đoán. Ghi nhận họ địa chỉ và địa chỉ cục bộ trong thông báo. Bind tới một địa chỉ cụ thể và bind tới wildcard là hai lỗi khác nhau với chủ sở hữu khác nhau.

Giữ nguyên văn bản chính xác. Địa chỉ đang được dùng, lỗi quyền và giao diện bị thiếu đều đến dưới dạng lỗi khởi động, và chúng chỉ tới ba cách sửa khác nhau.

Bước 2: liệt kê chủ sở hữu

Trước tiên hãy liệt kê các socket. Bộ lọc trên cổng nguồn 53 hiển thị cả hai giao thức vận chuyển và tiến trình sở hữu khi bạn có quyền xem:

ss -lntup 'sport = :53'

Đọc kết quả theo cột: giao thức vận chuyển, địa chỉ cục bộ, cổng, tiến trình. Trình lắng nghe TCP và trình lắng nghe UDP là hai socket riêng biệt, nên dừng cái này không giải phóng cái kia. Địa chỉ wildcard bao trùm mọi giao diện, nghĩa là địa chỉ VPN đã bị chiếm dù không dòng nào nêu tên nó. Và tên tiến trình cho bạn biết đây là resolver do bản phân phối quản lý, một container, hay thứ gì đó mà thí nghiệm trước để lại đang chạy.

Bước 3: cái bẫy wildcard

Tùy chọn bind-interfaces thay đổi việc dnsmasq liên kết một socket wildcard hay một socket cho mỗi giao diện đã cấu hình, như tài liệu tham chiếu dnsmasq mô tả. Không có nó, dnsmasq có thể liên kết wildcard và thay vào đó lọc yêu cầu theo giao diện, điều này thất bại ngay khi một daemon khác giữ wildcard. Linux thêm bind-dynamic, xử lý các giao diện được tạo sau khi khởi động, một mối lo thực sự khi giao diện VPN chỉ xuất hiện lúc kết nối.

Đó là lý do hai daemon trông như được cấu hình cho các giao diện khác nhau vẫn đụng nhau. Xung đột nằm ở socket, không phải ở ý định. Hãy chọn chế độ bind một cách có chủ đích và đọc hành vi được ghi lại cho phiên bản của bạn trước khi thay đổi.

Bước 4: giao việc

Quyết định daemon nào trả lời máy khách VPN và daemon nào trả lời máy chủ. Một resolver lắng nghe trên địa chỉ đường hầm và chuyển tiếp lên trên là cách bố trí phổ biến; hai resolver mà mỗi cái cho rằng mình sở hữu cổng 53 thì không phải là cách bố trí nào cả.

Sau đó thể hiện quyết định đó trong cấu hình của từng dịch vụ: địa chỉ lắng nghe, bộ lọc giao diện và chuyển tiếp. Thay đổi chúng qua chủ sở hữu dịch vụ, dù đó là unit của bản phân phối, trình quản lý mạng hay môi trường chạy container, để thay đổi sống sót qua lần khởi động lại.

Bước 5: kiểm chứng socket, rồi đến đường đi

Sau khi khởi động lại, xác nhận các socket dự định tồn tại trước khi thử máy khách. Một daemon chưa từng bind thì không thể cứu bằng tuyến đường, và lỗi máy khách với một socket được bind đúng là vấn đề khác với cách sửa khác. Sau đó kiểm tra khả năng tiếp cận từ một máy khách trên đường hầm. Chỉ sau đó mới đáng hỏi liệu các tên cần thiết có phân giải được không.

Ba kết quả riêng biệt cần giữ tách bạch: socket tồn tại, máy khách tiếp cận được, câu trả lời đúng.

Điều không nên làm

Đừng dừng một resolver lạ để giải phóng cổng mà không biết thứ gì phụ thuộc vào nó, vì các truy vấn của chính máy chủ thường phụ thuộc. Đừng sao chép công thức cũ chuyển daemon thứ hai sang địa chỉ lắng nghe công khai, vì điều đó như tác dụng phụ quyết định ai được phép hỏi bạn. Và đừng thêm chuyển tiếp khi lỗi là cục bộ.

Nếu máy được quản lý, hãy ghi lại quyết định sở hữu ở nơi quản trị viên tiếp theo sẽ tìm thấy. Xung đột cổng quay lại mỗi khi một image được dựng lại.