Vì sao quy tắc split tunnel của bạn không còn khớp với một dịch vụ

Split tunneling thường thất bại theo một trong hai cách. Hoặc lưu lượng lẽ ra phải ở trong đường hầm lại đi vòng qua nó, hoặc lưu lượng lẽ ra phải ở ngoài lại bị kéo vào trong. Sự cố do quy tắc cũ là kiểu thứ nhất, và nó khó hiểu hơn, vì quy tắc được thực thi đúng như đã viết. Điều đã thay đổi là đích: dịch vụ giờ trả lời trên một địa chỉ mà quy tắc chưa từng nêu tên, và trong đường hầm không có gì sai.

Quy tắc ghim điều gì và DNS trả về điều gì

Quy tắc split tunnel là một phát biểu tĩnh về các đích, thường được diễn đạt dưới dạng tiền tố, tuyến hoặc danh sách địa chỉ. Nó được đánh giá dựa trên đích của gói tin tại thời điểm gửi. Tên máy chủ là một lần tra cứu trả về một tập địa chỉ với thời gian sống và bộ nhớ đệm, và câu trả lời có thể khác nhau tùy theo resolver, loại truy vấn và phút.

Hai đối tượng đó không bao giờ thương lượng với nhau. Quy tắc vẫn khớp với tiền tố đã được cấp, dịch vụ vẫn đổi địa chỉ mà nó phát ra, và khoảng cách giữa chúng lặng lẽ lớn dần. Đó là lý do triệu chứng xuất hiện sau khi nhà cung cấp di chuyển hoặc chứng chỉ được gia hạn, chứ không phải sau khi cấu hình thay đổi. Không ai sửa đường hầm, nên không ai nhìn vào đường hầm, và chẩn đoán trôi về phía ứng dụng thay vì chính sách.

Ba cách sự khớp bị phá vỡ

Trường hợp rõ ràng là một dịch vụ đã di chuyển: nhà vận hành cấp địa chỉ mới, DNS đi theo, còn ngoại lệ thì không. Trường hợp thứ hai là một họ địa chỉ mà quy tắc chưa từng bao phủ, xảy ra khi một tên bắt đầu trả về bản ghi AAAA mà ngoại lệ chỉ dành cho IPv4 bỏ qua. Trường hợp thứ ba là khác biệt resolver: góc nhìn nội bộ và công khai có thể trả về địa chỉ khác nhau cho cùng một tên, nên địa chỉ ứng dụng của bạn dùng không phải địa chỉ bạn đã kiểm tra.

Một kết nối được đệm là biến thể thứ tư và rất dễ bỏ sót. Ứng dụng có thể vẫn đang nói chuyện với một địa chỉ mà nó đã phân giải cách đây một giờ, nghĩa là lần tra cứu mới của bạn và socket đang mở của nó không đồng ý về nơi dịch vụ nằm.

Đọc đích mà ứng dụng thực sự dùng

Hãy hỏi hệ điều hành và bảng socket, không phải thẻ trình duyệt. Lần tra cứu trả lời tên đang phân giải thành gì ngay lúc này, và bảng socket cho thấy địa chỉ mà tiến trình đang kết nối, có thể cũ hơn. Chạy cả hai trước khi lập giả thuyết, vì khác biệt giữa chúng tự nó là câu trả lời trong khoảng một nửa số trường hợp.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Sau đó so sánh với những gì quy tắc bao phủ. Nếu địa chỉ hiện tại nằm ngoài ngoại lệ và yêu cầu vẫn thất bại, bạn đã tìm ra nguyên nhân mà không cần chạm vào cấu hình đường hầm. Nếu ứng dụng kết nối với địa chỉ khớp với quy tắc và yêu cầu vẫn thất bại, vấn đề nằm ở phía bên kia đường hầm và đây là cuộc điều tra sai.

Sửa cơ chế, không phải triệu chứng

Nếu sản phẩm hỗ trợ định tuyến dựa trên tên miền được duy trì, hãy dùng nó và làm theo hành vi làm mới và phạm vi được ghi trong tài liệu. Cách này thay một phỏng đoán tĩnh bằng câu trả lời được duy trì, với cái giá là phụ thuộc vào việc tính năng hoạt động như tài liệu mô tả.

Nếu thiết kế dựa vào một danh sách tĩnh, hãy giao cho nó một người phụ trách và một kế hoạch cập nhật. Kế hoạch nên nói địa chỉ được phát hiện thế nào, ai phê duyệt thay đổi và danh sách được kỳ vọng theo kịp một lần di chuyển nhà cung cấp nhanh đến đâu. Một danh sách không có người phụ trách là sự cố tương lai với nguyên nhân đã biết.

Đừng mở rộng ngoại lệ sang một mạng lân cận lớn chỉ để bắt mọi địa chỉ bạn thấy trong một bài kiểm tra ngắn. Đó không phải là sửa chữa; đó là thay đổi vĩnh viễn ranh giới bảo mật, và nó sẽ lặng lẽ để các dịch vụ không liên quan đi vòng qua đường hầm chừng nào quy tắc còn tồn tại.

Xác minh cả hai nửa của ý định

Một thiết kế split tunnel có hai ý định, và một bản sửa chữa nên giữ cả hai. Dịch vụ được bảo vệ phải đi qua đường hầm, và các nhóm bị loại trừ phải tiếp tục đi vòng qua nó. Hãy thử một kết nối mới đến đích đã sửa, rồi thử một thứ lẽ ra phải ở ngoài.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Ghi lại địa chỉ mới, cơ chế đã chọn và ngày. Chính ghi chú đó ngăn người tiếp theo kết luận rằng VPN đã ngẫu nhiên phớt lờ cấu hình của chính nó.