Tài liệu split-tunnel cần một quy tắc DNS bên cạnh mỗi tuyến
Tuyến quyết định theo địa chỉ, trình phân giải quyết định theo tên. Ghi lại cả hai bộ chọn cho mỗi luồng, mỗi cái kèm một phép thử, nếu không ghi chú sẽ hỏng khi DNS dịch chuyển.
Một ghi chú split-tunnel nói "lưu lượng văn phòng đi qua VPN" đã ghi lại một quyết định và ngụ ý ba quyết định khác. Ở tầng gói, một bảng định tuyến chọn giao diện theo địa chỉ đích; ở tầng tên, một trình phân giải chọn máy chủ theo truy vấn, và hai lựa chọn được thực hiện độc lập. Đó là lý do một tiền tố được ghi lại đúng vẫn có thể tạo ra một máy phân giải tên nội bộ thành địa chỉ công cộng, hoặc không phân giải gì cả trong khi tuyến trông hoàn hảo.
Hai bộ chọn, một lần thử kết nối
Khi một ứng dụng kết nối tới files.corp.example, hai lần tra cứu diễn ra trước khi có một gói. Trình phân giải quyết định máy chủ nào nhận truy vấn, dùng miền tìm kiếm, miền định tuyến theo liên kết hoặc quy tắc hồ sơ rõ ràng. Bảng định tuyến sau đó quyết định địa chỉ thu được đi đâu, dùng khớp tiền tố dài nhất với đích.
Không có gì liên kết hai quyết định đó. Một vùng riêng có thể trả lời bằng 10.20.4.11 trong khi bảng định tuyến gửi 10.20.0.0/16 vào đường hầm, và kết nối hoạt động. Đảo ngược một trong hai và nó hỏng theo cách trông giống cái kia: chính sách DNS đúng cộng tuyến thiếu cho ra tên đã phân giải và hết thời gian, trong khi tuyến đúng cộng trình phân giải công cộng cho ra địa chỉ được định tuyến gọn gàng tới sai chỗ.
DNS chân trời phân tách làm điều này sắc hơn. Cùng một tên có thể trả về địa chỉ riêng từ trình phân giải nội bộ và địa chỉ công cộng từ trình hướng ra internet, nên một ghi chú chỉ ghi tiền tố không thể dự đoán máy khách thực sự dùng địa chỉ nào. Hãy ghi lại đường đi của trình phân giải, nếu không địa chỉ chỉ là phỏng đoán.
Ghi chú chỉ có tuyến bỏ sót điều gì
Một bản ghi chỉ có tuyến là vô dụng với sự cố split-tunnel phổ biến nhất: tên. Người dùng báo rằng intranet không tải được, đường hầm đang bật và tiền tố có mặt. Người nhận phiếu không có bản ghi trình phân giải nào đáng lẽ phải trả lời, không có cách phân biệt hậu tố tìm kiếm sai với máy chủ bị chặn, và không có đường cơ sở để so sánh.
Thiếu sót thứ hai là danh sách ngoại lệ. Thiết kế split-tunnel được xác định bởi những gì ở ngoài đường hầm cũng như những gì đi vào trong, và các dải bị loại trừ thường là thứ vỡ trước, vì một tuyến cục bộ cụ thể hơn hoặc bộ lọc phía máy khách có thể lấn át ý định mà không chạm vào hồ sơ.
Thứ ba là phía xa của đường hầm. Tuyến máy khách chỉ đặt gói lên dây; cổng vẫn phải chuyển tiếp nó và có đường quay về. Hướng dẫn chuyển tiếp của strongSwan nhắc rằng các quy tắc chuyển tiếp và tường lửa trên cổng là một phần của tính năng, không phải phần ống nước bạn có thể mặc định có.
Những trường khiến ghi chú có thể thực thi
Một dòng cho mỗi luồng, và luồng là đích cộng tên cộng chủ sở hữu. Đây là những trường tồn tại khi tiếp xúc với sự cố thật:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Dòng "nó sống ở đâu" là dòng người ta bỏ qua. Một tiền tố do máy chủ đẩy, một tuyến do hồ sơ máy khách thêm và một tuyến gõ trong shell khác nhau ở chỗ ai có thể thay đổi chúng và liệu chúng có sống sót qua lần kết nối lại. Không có trường đó, kỹ sư tiếp theo không thể nói mình đang xem cái nào trong ba cái.
Một phép thử cho mỗi quy tắc, không phải mỗi đường hầm
Mỗi dòng cần hai kiểm tra vô hại: một kiểm tra tuyến và một kiểm tra tên. Với tuyến, hãy yêu cầu thứ gì đó phải đi qua đường hầm và xác nhận đường đi thay vì khả năng tiếp cận, ví dụ tracert -d 10.20.4.11 trên Windows hoặc ip route get 10.20.4.11 trên Linux. Với tên, hãy truy vấn tên riêng và ghi lại máy chủ nào đã trả lời, dùng resolvectl query files.corp.example hoặc dig files.corp.example đối với trình phân giải mà ghi chú nêu tên.
Cũng thêm một kỳ vọng phủ định: điều gì phải xảy ra khi đường hầm tắt. Một ứng dụng bị loại trừ trên thiết bị Android hoặc iOS có bật chặn không VPN có thể không có kết nối nào, và máy khách máy tính có thể để ứng dụng đó chạy trong khi đường hầm kết nối lại. Ghi lại câu trả lời dự định biến "VPN làm hỏng ứng dụng của tôi" thành một tuyên bố có thể kiểm chứng.
Giữ bản ghi cùng với cấu hình
Lưu ghi chú bên cạnh hồ sơ mà nó mô tả và tạo phiên bản cùng hồ sơ đó. Một tài liệu trên wiki không ai cập nhật là tin đồn; một bảng trong cùng kho với các tuyến được đẩy và chính sách trình phân giải có thể được xem xét trong cùng một thay đổi.
Khi có sự cố, hãy so sánh tuyến đang áp dụng và trình phân giải hiệu lực với bản ghi trước khi thêm ngoại lệ khác. Hai trong ba nguyên nhân phổ biến — quy tắc không gian tên cũ và tiến trình hỗ trợ ngoài chính sách ứng dụng — trông giống hệt lỗi VPN và không thể thấy nếu ghi chú chỉ liệt kê tiền tố.
Trước khi tuyên bố ghi chú hoàn tất, hãy xác nhận nó trả lời bằng văn bản những điều này: tiền tố nào, cho họ địa chỉ nào; không gian tên riêng nào, được trình phân giải nào trả lời; tên nào cố ý ở lại công cộng; mỗi quy tắc được cấu hình ở đâu và ai sở hữu; và lệnh duy nhất chứng minh tuyến và lệnh chứng minh tên. Nếu thiếu bất kỳ điều nào, sự cố tiếp theo sẽ được chẩn đoán từ đầu.