Bắt tay WireGuard hoạt động, dịch vụ thì không

Cuộc bắt tay hoàn tất, máy khách hiển thị bộ đếm truyền tải gần đây, vậy mà một yêu cầu tới dịch vụ trên cùng máy chủ vẫn thất bại. Sự kết hợp này khiến người ta bối rối, vì đường hầm rõ ràng đang hoạt động. Điều chưa được chứng minh là việc giao nộp cục bộ: gói tin đã tới máy chủ, và máy chủ vẫn phải chấp nhận nó trên đúng socket rồi chuyển cho một tiến trình có quyền trả lời. Hãy đi qua ba điểm kiểm tra đó theo thứ tự.

Dừng ở điểm đầu tiên không đúng, và đừng thêm quy tắc cho các điểm còn lại.

Bắt tay chỉ chứng minh đường hầm

Bắt tay của WireGuard thiết lập khóa giữa các peer và cho phép lưu lượng cho các dải mà mỗi peer đã liệt kê. Nó không nói gì về việc tiến trình nào đang lắng nghe trên máy chủ, cũng không nói gì về việc tường lửa của máy chủ có chấp nhận các gói hướng tới một trong những địa chỉ của chính nó hay không.

Chính sự phân biệt cuối cùng ấy thường bị bỏ sót nhất: lưu lượng tới chính máy chủ là đầu vào cục bộ, còn lưu lượng đi qua máy chủ tới nơi khác là chuyển tiếp. Chúng được xử lý bởi các chuỗi tường lửa khác nhau và các thiết lập khác nhau. Kiểm tra nhầm chuỗi tốn cả buổi chiều và trả về những bộ đếm trông có vẻ vô hại.

Đọc trình lắng nghe và tuyến đường

Trên máy khách, xác nhận rằng địa chỉ đường hầm của máy chủ được định tuyến vào đường hầm. Trên máy chủ, xác nhận rằng có một socket trên địa chỉ mà máy khách đang dùng, và tiến trình phía sau chính là tiến trình bạn định.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Một trình lắng nghe trên 127.0.0.1 sẽ không bao giờ trả lời yêu cầu hướng tới 10.66.0.1, bất kể tường lửa cho phép gì. Một trình lắng nghe trên địa chỉ tổng quát thì sẽ trả lời, trừ khi có quy tắc chặn nó. Vì vậy danh sách socket giải quyết một nửa số ca trước khi xem xét bất kỳ quy tắc nào. Cổng và địa chỉ cùng nhau quyết định một yêu cầu có thể tới nơi hay không.

Hãy so sánh địa chỉ máy khách dùng với địa chỉ mà máy chủ thực sự có trên giao diện đường hầm. Cấu hình cũ ở bên nào cũng tạo ra một yêu cầu được định tuyến đúng tới một peer không có địa chỉ đó.

Áp quy tắc cho đầu vào cục bộ, không phải cho chuyển tiếp

Nếu gói tin tới và socket tồn tại, ranh giới còn lại là chính sách đầu vào. Một quy tắc cho phép chuyển tiếp không cho phép giao nộp cục bộ, và một quy tắc giới hạn cho một giao diện có thể không khớp với tên giao diện đường hầm mà bạn mong đợi.

Hãy thử với một cổng được phép duy nhất tới dịch vụ dự định thay vì mở máy chủ. Sau đó kiểm tra quyền của chính ứng dụng: danh sách cho phép, yêu cầu tài khoản hoặc ràng buộc vào một tên máy chủ cụ thể có thể từ chối một yêu cầu mà mạng đã giao thành công.

Hãy giữ nguyên các kiểm tra chứng chỉ. Danh tính chứng chỉ bất ngờ là thông tin về việc máy chủ nào đã trả lời, không phải chướng ngại cần vượt qua. Bấm bỏ qua sẽ che mất manh mối duy nhất nhận diện dịch vụ sai.

Tách biệt lỗi tên, kích thước và danh tính

Một dịch vụ chạy theo địa chỉ nhưng hỏng theo tên là vấn đề DNS, và cách sửa thuộc về cấu hình trình phân giải được gửi tới máy khách, không phải tường lửa. Một dịch vụ trả lời yêu cầu nhỏ nhưng kẹt ở phản hồi lớn hơn cho thấy kích thước gói và MTU, đó là một cuộc điều tra hoàn toàn khác.

Lỗi HTTPS nêu sai máy chủ thường có nghĩa là yêu cầu đã tới một dịch vụ khác, thường vì một proxy hoặc một trình lắng nghe khác đang chiếm cổng đó. Hãy đọc chủ thể của chứng chỉ và so với máy chủ bạn muốn tới. Việc so sánh đó không tốn gì và thường kết thúc cuộc điều tra.

Ghi lại điểm kiểm tra nào đã hỏng: socket, quy tắc đầu vào hay chính sách ứng dụng. Một dòng đó phân biệt sự cố mạng với một quyết định cấp quyền. Nó cũng ngăn người tiếp theo mở những cổng chưa bao giờ là vấn đề.