Tên DNS riêng hay chỉ một địa chỉ IP? Quyết định trước khi chia sẻ

Hai câu hỏi bị trộn lẫn khi một dịch vụ riêng được mở cho người dùng từ xa. Câu thứ nhất là khách hàng nên dùng tên nào; câu thứ hai là dịch vụ nên chấp nhận những nguồn nào. Hãy trả lời theo đúng thứ tự đó, vì một tên đúng phía sau quy tắc truy cập sai vẫn thất bại, và một quy tắc đúng phía sau một tên không phân giải được thì không bao giờ được kiểm tra.

Điều kiện một: khách hàng có đường đi bộ phân giải nào?

Một tên riêng chỉ hoạt động nếu bộ phân giải của khách hàng có thể trả lời nó. Điều đó có nghĩa là khách hàng từ xa được cấp quyền phải tiếp cận được máy chủ DNS giữ vùng, hoặc qua đường hầm hoặc qua bộ phân giải mà tổ chức đã chạy cho người dùng từ xa. Đường hầm là phương tiện vận chuyển, không phải thư mục. Nó cho khách hàng một đường đến bộ phân giải, và nó không nói cho khách hàng biết phải hỏi vùng nào.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Một bộ phân giải công cộng sẽ không học được vùng riêng chỉ vì máy tính xách tay đã kết nối với VPN.

Hậu tố cũng đáng được quan tâm như vậy. Hãy dùng một tên miền con của tên miền mà tổ chức kiểm soát, để quyền sở hữu và kế hoạch chứng chỉ vẫn rõ ràng. Tránh .local: đặc tả DNS đa hướng gắn hậu tố đó với phân giải link-local, và một đường hầm được định tuyến không tái tạo hành vi đó cho bạn.

Điều kiện hai: dịch vụ nhận nguồn nào?

Các quy tắc chấp nhận được viết theo địa chỉ, nên câu hỏi hữu ích là dịch vụ nhìn thấy địa chỉ nào sau khi định tuyến và chuyển đổi. Với một dịch vụ ví dụ tại 10.20.30.40, khách hàng văn phòng đến từ 10.20.30.0/24 và khách hàng từ xa đến từ một nhóm riêng như 10.99.0.0/24.

Nếu một cổng chuyển đổi nhóm từ xa, dịch vụ nhìn thấy bộ chuyển đổi, và một quy tắc viết cho 10.99.0.0/24 sẽ không khớp.

Hãy đọc điều này từ phía dịch vụ chứ không phải từ phía khách hàng. Nhật ký trình lắng nghe hoặc bắt gói trên máy chủ dịch vụ cho thấy nguồn thực sự đã đến; địa chỉ của chính khách hàng chỉ là một phỏng đoán về những gì đã sống sót qua đường đi.

Điều kiện ba: tên gắn với dịch vụ hay với máy chủ?

Một tên trỏ đến địa chỉ của một máy sẽ gắn mọi khách hàng với máy đó. Một tên trỏ đến bộ cân bằng tải hoặc địa chỉ dịch vụ ổn định sẽ tồn tại qua việc thay thế máy chủ phía sau nó. Hãy chọn có chủ đích, vì thay đổi điều này sau đó nghĩa là thay đổi dấu trang của mọi khách hàng và chủ thể của mọi chứng chỉ.

Với một dịch vụ nội bộ duy nhất, một bản ghi trực tiếp thường là phù hợp và dễ suy nghĩ hơn.

Với bất cứ thứ gì sẽ bị thay thế, xây lại hoặc mở rộng, một giao diện trước ổn định đáng để cấu hình thêm. Bài kiểm tra rất đơn giản: nếu bạn có thể thay phần phía sau mà không nói với người dùng, tên gắn với dịch vụ; nếu không, nó gắn với máy chủ.

Kiểm tra hai quyết định riêng rẽ

Phân giải trước, rồi kết nối. Một bài kiểm tra phân giải trả về địa chỉ mong đợi chứng minh đường đi của tên và không nói gì về việc chấp nhận. Một bài kiểm tra kết nối chứng minh đường đi và quy tắc cùng lúc, vì vậy chỉ chạy nó sau khi phân giải thành công.

curl -sv --max-time 5 https://files.corp.example/health

Sau đó kiểm tra một nguồn bị cấm một lần, và ghi lại kết quả.

Giữ hai bản ghi tách biệt trong tài liệu của bạn: tên và vùng của nó, các nguồn được chấp nhận và chủ sở hữu quy tắc. Khi một thứ thay đổi, thứ kia không nhất thiết phải thay đổi.

Nơi quyết định thường sai

Lỗi phổ biến là một dịch vụ được công bố dưới một tên chỉ phân giải trên mạng văn phòng, với một quy tắc chấp nhận chỉ chấp nhận dải văn phòng. Người dùng từ xa sau đó báo cáo một dịch vụ hỏng mà thực ra là hai thiếu sót riêng biệt. Lỗi phổ biến thứ hai là ngược lại: một quy tắc chấp nhận rộng được thêm vào để xóa một vấn đề về tên lại để dịch vụ có thể tiếp cận từ những nguồn mà không ai định trước. Cả hai đều là thiếu sót trong cấu hình, và từ chỗ ngồi của người dùng chúng trông giống nhau.

Không lỗi nào trong hai lỗi là nhìn thấy được từ một bài kiểm tra thành công. Vì vậy hai quyết định xứng đáng có bản ghi riêng và bài kiểm tra riêng, ngay cả khi cùng một người đưa ra cả hai.

Hãy viết cả hai trước khi dịch vụ đi vào vận hành, vì thay đổi tiếp theo sẽ dễ suy nghĩ hơn. Bản ghi rất ngắn: một dòng cho tên và vùng của nó, một dòng cho các nguồn được chấp nhận và chủ sở hữu quy tắc.