Đường hầm đã lên, vậy tại sao tên riêng vẫn thất bại?

Mọi thứ về kết nối trông đều đúng: đường hầm đã lên và bảng điều khiển hiển thị điểm cuối riêng, nhưng mọi yêu cầu đều thất bại khi phân giải tên. Bước tự nhiên là đổ lỗi cho đường hầm, thứ thường tỏ ra vô tội. Truy vấn được gửi đến một máy chủ không biết gì về vùng riêng. Không thay đổi định tuyến nào sẽ thay đổi câu trả lời đó, vì vấn đề là đã hỏi ai.

Truy vấn đã đến trình phân giải nào?

Tìm trình phân giải gắn với từng liên kết trước khi nhìn vào đường hầm. Linux hiển thị máy chủ theo từng liên kết qua lệnh trạng thái trình phân giải, và macOS hiển thị trình phân giải có phạm vi trong bản kết xuất cấu hình DNS. Nếu câu trả lời vẫn đến từ bộ định tuyến gia đình, liên kết đường hầm chưa bao giờ được hỏi.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Ở đây trộn lẫn hai giai đoạn: máy chủ đẩy địa chỉ trình phân giải và máy khách cài đặt nó trên liên kết đang hoạt động. Hồ sơ có thể chứa tùy chọn và nhật ký có thể cho thấy nó đến, trong khi hệ điều hành vẫn tiếp tục dùng máy chủ cũ. So sánh nhật ký với những gì liên kết báo cáo, và tin vào liên kết.

Dùng địa chỉ mà mạng đám mây thực sự trả lời

Mạng đám mây thường trả lời tên riêng qua một địa chỉ dành riêng lệch hai vị trí so với cơ sở của dải, nên mạng bắt đầu từ 10.0.0.0 trả lời tại 10.0.0.2. Một số nhà cung cấp cũng công bố trình phân giải cục bộ của liên kết hoạt động mà không cần biết dải, điều này hữu ích khi mạng do người khác xây dựng. Hỏi trực tiếp địa chỉ ứng viên trước khi đẩy nó cho bất kỳ ai. Một địa chỉ không phải trình phân giải trông giống hệt việc tường lửa bỏ gói, vì truy vấn đơn giản là không bao giờ nhận được câu trả lời.

Nếu truy vấn trực tiếp trả lời từ bên trong mạng nhưng không qua đường hầm, trình phân giải ổn và đường đi giữa hai điểm không ổn. Kết quả đó chuyển cuộc điều tra sang tuyến đường, chuyển tiếp và quy tắc truy cập thay vì hồ sơ máy khách.

Đường hầm không mang không gian tên

Gói tin đi qua; tên thì không. Mỗi bên phải được cho biết không gian tên nào thuộc về bên kia, và đó là một đối tượng riêng do người giữ vùng sở hữu. Hình thức thông thường là chuyển tiếp cho một không gian tên, trỏ đến trình phân giải có thể truy cập qua đường hầm.

Trên thực tế mỗi hướng cần quy tắc riêng, vì bên sở hữu vùng phải gửi truy vấn đi tiếp. Cả hai hướng đều cần nguồn truy vấn được định tuyến và cho phép, và bên trả lời phải gửi câu trả lời qua đường hầm thay vì ra internet. Giữ chuyển tiếp hẹp, để chỉ không gian tên riêng phụ thuộc vào liên kết. Gửi mọi truy vấn qua nó biến một phụ thuộc nhỏ thành gián đoạn hoàn toàn ngay khi đường hầm sập.

Đi qua các ranh giới theo thứ tự

Kiểm tra trình phân giải được cài trên liên kết đang hoạt động, sau đó truy vấn trực tiếp đến trình phân giải đó, sau đó cùng truy vấn từ phía xa, và cuối cùng ứng dụng dùng cùng tên. Mỗi bước cô lập một ranh giới, nên lỗi cho biết nên nhìn ở đâu thay vì bắt đầu lại cuộc điều tra. Một câu trả lời hoạt động trong khi ứng dụng thất bại cho thấy niềm tin chứng chỉ hoặc chính sách API chứ không phải DNS. Những lỗi đó là thật, và không thay đổi trình phân giải nào sửa được chúng.

Ghi lại bước nào đã thất bại. Đúng một dòng đó là thứ người tiếp theo cần, và việc ghi lại mất mười giây.

Giữ chuỗi ở nơi người tiếp theo có thể tìm thấy

Ghi lại trình phân giải bị đẩy, quy tắc chuyển tiếp, nguồn truy vấn được phép và điểm cuối trả lời ở một chỗ. Khi tên riêng thất bại lần nữa, bản ghi cho thấy đường hầm có dịch chuyển, địa chỉ trình phân giải có thay đổi hay một quy tắc bị thu hẹp. Không có nó, mọi sự cố bắt đầu từ con số không và kết thúc bằng cùng ba phỏng đoán.

Giữ bản ghi đủ ngắn để vẫn chính xác: bốn dòng, một ngày và tên người sở hữu từng phần. Một bản ghi cũ tệ hơn không có, vì nó trông có thẩm quyền trong khi lại sai.