DNS chia tách và VPN: quy tắc tên miền không phải tuyến IP
DNS chia tách chọn bộ phân giải theo tên, và câu trả lời vẫn cần một tuyến. Hãy thử quy tắc tên miền và đường đi riêng rẽ, trên nền tảng bạn thực sự chạy.
Máy tính xách tay của bạn phân giải intranet.corp qua đường hầm trong khi gitlab.com vẫn đi đến bộ phân giải của nhà cung cấp, và đây là cách bố trí hoạt động đúng như thiết kế. Hai quyết định riêng biệt đã tạo ra nó: một quy tắc khớp tên đã chọn bộ phân giải, và một tuyến đã mang câu trả lời trở lại. Phá vỡ một trong hai và trình duyệt hiển thị lỗi trông giống nhau từ bên ngoài. Hầu hết báo cáo về DNS chia tách mô tả lỗi thứ hai trong khi trích dẫn bằng chứng về lỗi thứ nhất.
Hai nửa nằm ở những nơi khác nhau và thường được chỉnh sửa bởi những người khác nhau. Một là chính sách DNS gắn với hồ sơ VPN, còn lại là một tuyến mà đường hầm cài đặt hoặc giữ lại. Việc gỡ lỗi dừng lại khi không ai xác định được nửa nào thực sự đã di chuyển.
Hai quyết định ẩn trong một yêu cầu
Nửa tên là một đối tượng chính sách, không phải tuyến. Trên Windows đó là chính sách phân giải tên trên hồ sơ VPN; trên nền tảng Apple là một tập tên miền khớp trên đối tượng cài đặt DNS; trên Linux là miền định tuyến, dòng bộ phân giải chia tách hoặc thứ tự chuyển mạch dịch vụ tên. Nửa đường đi là định tuyến thông thường, do đường hầm hoặc bàn tay cài đặt, và nó không biết tên máy chủ là gì. Một hồ sơ chấp nhận hậu tố chỉ quyết định ai trả lời; nó không bao giờ làm cho câu trả lời có thể tiếp cận được.
Một thử nghiệm triệu chứng nhanh phân tách chúng: thay tên bằng một địa chỉ. Nếu địa chỉ hoạt động, đường đi ổn và quy tắc sai. Nếu địa chỉ cũng thất bại, quy tắc có thể đúng và đường đi bị thiếu.
Cách mỗi nền tảng diễn đạt cùng một quy tắc tên
Ý định là giống nhau và tên trường thì không. Một ví dụ sao chép từ máy khách này sang máy khách khác được phân tích sạch sẽ và không bao giờ khớp. Ba dạng trông như sau:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Miền khớp hoặc miền định tuyến là một phép thử hậu tố, vì vậy intranet.corp bao phủ git.intranet.corp và không bao phủ corp.intranet, và đảo ngược điều đó là lỗi phổ biến nhất trong toàn bộ cấu hình. Windows mang ánh xạ dưới dạng chính sách phân giải tên gắn với hồ sơ, với thứ tự ưu tiên riêng so với bất kỳ danh sách hậu tố nào mà giao diện đã có. Các nền tảng Apple gắn các miền khớp vào đối tượng cài đặt DNS của tiện ích mở rộng mạng, và hệ thống áp dụng chúng cho từng bộ phân giải có phạm vi. Không dạng nào trong số này là tuyến, và không dạng nào có thể làm cho một địa chỉ không thể tiếp cận trở nên tiếp cận được. Tài liệu tham chiếu chính sách phân giải tên của Windows liệt kê tên trường và quy tắc ưu tiên cho nền tảng đó, và chúng không phải là những quy tắc mà tài liệu Apple hay systemd sử dụng.
Một câu trả lời đúng vẫn cần đường đi
Câu trả lời của bộ phân giải chỉ là một địa chỉ, và ứng dụng vẫn phải đến được đó. Thiết kế đường hầm chia tách thường đẩy 10.20.0.0/16 và giữ lại tuyến mặc định, vì vậy tên nội bộ được phân giải và kết nối sau đó bị treo. Trường hợp ngược lại cũng phổ biến không kém: tuyến tồn tại, một bộ phân giải công cộng trả lời tên riêng bằng NXDOMAIN, và lỗi được ghi nhận là vấn đề định tuyến. Thử đường đi trước khiến bạn nhìn chằm chằm vào các tuyến cho một cái tên không bao giờ được phân giải.
Cũng có một cổng thứ ba mà không nửa nào bao phủ. Một ACL trên cổng, một quy tắc tường lửa hoặc một chính sách phía máy khách có thể làm rơi kết nối sau khi cả hai quyết định đều đúng. Khi tên được phân giải, tuyến tồn tại và kết nối vẫn hết thời gian, hãy ngừng thử DNS.
Thử tên và đường đi theo một thứ tự cố định
Chọn một thứ tự và giữ nguyên, nếu không bạn sẽ đuổi theo bước vừa thất bại. Phân giải tên nội bộ đầy đủ đã được ghi tài liệu, xác nhận rằng câu trả lời là địa chỉ mà bảng tuyến có thể mang, rồi lặp lại với một tên công cộng để chứng minh đường hầm không bắt được mọi thứ. Trên một máy chủ systemd, truy vấn và miền định tuyến của bộ phân giải cách nhau một lệnh:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Một máy khách Windows hỏi cùng hai câu hỏi bằng các cmdlet khác. Câu thứ hai báo cáo giao diện mà hệ thống thực sự sẽ dùng:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Nếu tra cứu trả về một địa chỉ và kiểm tra đường đi nêu tên giao diện vật lý, quy tắc tên đã hoạt động và tuyến thì không. Nếu tên ngắn thất bại trong khi tên đầy đủ được phân giải, danh sách hậu tố sai chứ không phải bộ phân giải.
Nơi so sánh thường đi sai
Lỗi đầu tiên là hỏi một bộ phân giải công cộng không liên quan về một tên riêng và đọc sự từ chối như bằng chứng về VPN. Lỗi thứ hai là cho rằng một tra cứu công cộng hoạt động chứng minh đường đi của bộ phân giải đường hầm. Lỗi thứ ba là coi đường hầm chia tách và DNS chia tách như một quyết định thiết kế duy nhất, trong khi một triển khai có thể đúng ở cái này và hỏng ở cái kia. Mỗi lỗi tạo ra kết luận tự tin từ một thử nghiệm chưa bao giờ luyện tập phần bị đổ lỗi.
Một trình duyệt có DNS bảo mật riêng cũng có thể bỏ qua quy tắc hệ thống, vì vậy việc một trình duyệt thất bại trong khi trình duyệt khác thành công không phải là mâu thuẫn. Hãy so sánh bộ phân giải đã trả lời, không phải trình duyệt đã phàn nàn.
Khi cả hai nửa đều hiển thị, câu hỏi còn lại là câu hỏi chính sách chứ không phải kỹ thuật: không gian tên nào thuộc về tổ chức, ai sở hữu từng câu trả lời và cái nào trong số chúng nên rời khỏi máy. Hãy viết điều đó bên cạnh hồ sơ, vì người tiếp theo chạm vào quy tắc sẽ cần nó.