Tên điểm cuối VPN so với tên dịch vụ riêng: hai chủ sở hữu

Hai cái tên có thể mô tả cùng một chi nhánh và trả lời những câu hỏi hoàn toàn khác nhau. vpn.branch.example cho một đối tác từ xa biết nơi tìm điểm cuối VPN, và nó phải được phân giải trước khi có bất kỳ đường hầm nào. inventory.branch.example cho một người dùng được uỷ quyền biết ứng dụng riêng nằm ở đâu, và nó chỉ quan trọng sau khi đường hầm đã được dựng. Việc duy trì cái này không làm gì cho cái kia.

Hãy đặt tên cho cả hai bản ghi trước khi gỡ lỗi bất kỳ bản ghi nào

Viết cả hai ra cùng với chủ sở hữu của chúng. Với điểm cuối, ghi lại ai cập nhật địa chỉ công khai và ứng dụng VPN làm mới câu trả lời của nó như thế nào. Với dịch vụ, ghi lại ai sở hữu địa chỉ riêng, vùng nào giữ bản ghi và những bộ phân giải nào phải trả lời cho nó.

Danh sách ngắn đó ngăn chặn chẩn đoán sai phổ biến nhất trong lĩnh vực này: khởi động lại một đường hầm chi nhánh đang hoạt động để sửa một bản ghi nằm hoàn toàn bên trong nó. Đường hầm là phương tiện vận chuyển cho tên dịch vụ; nó không phải là thẩm quyền của tên đó.

Khi một thay đổi được đề xuất, hãy hỏi nó chạm vào bản ghi nào trong hai bản ghi. Nếu không ai trả lời được, thay đổi đó chưa sẵn sàng để lên lịch.

Điểm cuối phải được phân giải trước khi có bất kỳ đường hầm nào

Giả sử kết nối internet của chi nhánh nhận được một địa chỉ công khai mới. Trình cập nhật điểm cuối công bố địa chỉ mới, và bản triển khai VPN từ xa phải đọc được câu trả lời đã thay đổi. Bất kỳ bộ phân giải nào cung cấp câu trả lời đó đều phải truy cập được mà không cần đường hầm, nếu không ứng dụng khách đang đuổi theo một cái tên mà nó chỉ phân giải được sau khi kết nối tới thứ nó không tìm thấy.

Sự phụ thuộc khởi động đó đáng được nói thẳng, vì rất dễ tạo ra nó do vô tình khi mọi bộ phân giải nội bộ đều nằm sau VPN. Hãy giữ một đường dẫn trước đường hầm cho việc tra cứu điểm cuối, và xác nhận hành vi kết nối lại của ứng dụng khách thay vì cho rằng câu trả lời mới được tiếp nhận ngay lập tức.

DNS động cũng có những giới hạn mà việc cập nhật bản ghi không thể vượt qua. Cập nhật bản ghi không mở cổng tường lửa, không tạo ánh xạ NAT và không chứng minh danh tính đối tác. Một địa chỉ được công bố với cổng đóng cho ra một ứng dụng khách phân giải đúng và vẫn không thể kết nối tới bất cứ thứ gì.

Cuối cùng, một ứng dụng khách đang chạy có thể tiếp tục dùng điểm cuối đã lưu trong bộ nhớ đệm cho tới khi kết nối lại. Hãy tách việc công bố, bộ nhớ đệm và chính sách kết nối lại trong ghi chú của bạn, để một đối tác cũ không bị nhầm là trình cập nhật hỏng.

Tên dịch vụ mô tả nơi ứng dụng sinh sống

Bây giờ giả sử đường hầm vẫn khoẻ nhưng máy chủ kiểm kê chuyển từ 172.26.14.20 sang 172.26.14.35. Bản ghi điểm cuối công khai không bị ảnh hưởng, trong khi bản ghi dịch vụ riêng phải thay đổi. Dùng một địa chỉ dành riêng cho dịch vụ đó, hoặc một phép gán tĩnh, khiến việc này hiếm hơn; một đường cập nhật được uỷ quyền xử lý những lần điều đó là có chủ đích.

Hai cơ chế cập nhật bị nhầm lẫn ở đây. RFC 2136 định nghĩa một giao thức để thêm và xoá bản ghi DNS trong một vùng, trong khi một nhà cung cấp DNS động thương mại có thể công bố một API HTTP hoàn toàn khác cho mục đích khác. Dùng cái này không có nghĩa cái kia tồn tại trong môi trường của bạn. Hãy kiểm tra vùng của bạn thực sự chấp nhận cơ chế nào trước khi viết trình cập nhật dựa trên nó.

Một câu trả lời riêng đúng chỉ là điều kiện đầu tiên. Để một bên gọi từ xa dùng được nó, ứng dụng khách cần một bộ phân giải mang vùng riêng, một chính sách cho phép truy vấn tới bộ phân giải đó, và chuyển tiếp cho địa chỉ trả về. Một cái tên phân giải tới địa chỉ mà ứng dụng khách không thể với tới tạo ra một lần hết thời gian trông giống như lỗi máy chủ.

Hãy thử hai đường dẫn riêng rẽ

Kiểm tra điểm cuối từ bên ngoài đường hầm và dịch vụ từ bên trong, và giữ kết quả như hai sự thật độc lập:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Nếu truy vấn đầu tiên thất bại, vấn đề là việc công bố công khai hoặc đường phân giải trước đường hầm, và không thay đổi nội bộ nào giúp được. Nếu truy vấn thứ hai trả về một địa chỉ nhưng truy vấn thứ ba không cho thấy tuyến nào qua đường hầm, lớp DNS vẫn ổn và chính sách chuyển tiếp thì không.

Chạy cặp này sau mỗi lần đổi địa chỉ, và ghi lại bản ghi nào đã di chuyển. Một bản bàn giao chỉ nói «DNS đã được cập nhật» để mặc kỹ sư tiếp theo đoán xem vòng đời nào trong hai vòng đời đã thực sự chạy.