Vì sao một subnet vẫn đi vòng qua tuyến mặc định của VPN

Bạn chuyển VPN sang tunnel đầy đủ, phần lớn lưu lượng tuân theo, và rồi một địa chỉ phản hồi trực tiếp — một máy in, một NAS, một máy chủ nhảy trên 10.x. Cách đọc hiển nhiên là tunnel đang rò rỉ, nên bạn hạ chỉ số trên tuyến mặc định và không có gì thay đổi. Lần thử thất bại đó chính là manh mối: tuyến mặc định là phương án dự phòng, không phải phán quyết. Việc tra cứu tuyến lấy tiền tố khớp dài nhất trước khi so sánh chỉ số, nên một /24 tiếp tục thắng một /0, bất kể bạn gắn con số nào vào cái nào. Khi trật tự đó đã rõ, rò rỉ thường là một tuyến ai đó cố ý cài đặt, hoặc một tiền tố mà máy khách chưa bao giờ định bao phủ.

Tuyến mặc định thực sự hứa điều gì

0.0.0.0/0 khớp với mọi đích IPv4 với không bit đặc hiệu. Nó tồn tại để một máy chủ có thể chạm tới mọi thứ mà bảng của nó không mô tả tốt hơn. Một tuyến tới 192.168.1.0/24 mang 24 bit khớp, nên với 192.168.1.40 nó thắng trước khi ai đó so sánh chỉ số, khoảng cách quản trị hay bất cứ thứ gì máy khách gọi là trường ưu tiên. Cùng quy tắc đó áp dụng trong Linux FIB, bảng định tuyến Windows và ngăn xếp BSD phía sau macOS.

Trên một LAN bình thường, hành vi đó là một tính năng. Subnet cục bộ được kết nối trực tiếp, máy in tiếp tục hoạt động trong khi tunnel mang lưu lượng duyệt web của bạn, và không có gì bị cấu hình sai. Câu hỏi đáng đặt ra không phải là vì sao địa chỉ đó đi thẳng, mà là tiền tố nào trong bảng nào khớp với nó, và ai đã đặt nó ở đó.

Nửa mặc định, hay vì sao mục mặc định có thể trông như không bị đụng tới

Ví dụ sạch nhất là redirect-gateway def1 trong OpenVPN. Thay vì xóa và thay thế tuyến mặc định của bạn, nó thêm 0.0.0.0/1 và 128.0.0.0/1. Cùng nhau cặp này bao phủ toàn bộ IPv4, mỗi tiền tố dài hơn /0, và cả hai đánh bại tuyến mặc định của router trong khi vẫn để nó tại chỗ. Chạy danh sách tuyến sau đó và tuyến mặc định ban đầu vẫn còn đó, vẫn trỏ tới cổng của bạn; nó chỉ không bao giờ được chọn cho các đích internet.

wg-quick của WireGuard đạt cùng kết quả qua định tuyến dựa trên chính sách. Khi AllowedIPs bao phủ 0.0.0.0/0, nó tạo bảng riêng, gửi các gói đã đánh dấu tới đó và thêm một quy tắc bỏ qua tiền tố độ dài không của bảng chính. Bảng chính giữ mục mặc định của nó, và các quy tắc quyết định rằng bảng tunnel được hỏi trước cho lưu lượng mà giao diện sở hữu.

Cả hai thiết kế cần đúng một tuyến nằm ngoài tunnel: một tuyến máy chủ tới địa chỉ của chính máy chủ VPN qua cổng ban đầu. Không có nó, máy khách sẽ cố mang các gói dựng nên tunnel vào bên trong tunnel, và kết nối sẽ không bao giờ hoàn tất. Vì vậy một tuyến không phải tunnel trong bảng của bạn là bình thường ngay cả trên hồ sơ tunnel đầy đủ nghiêm ngặt. Những tuyến đáng bị chất vấn là những tuyến bao phủ các đích bạn thực sự quan tâm.

Chỉ số quyết định hòa, tiền tố quyết định người thắng

Chỉ số chỉ được so sánh giữa các ứng viên khớp đích tốt như nhau. Trên Linux ip route get 10.20.5.9 in ra người thắng cùng bảng của nó, và ip route show table all liệt kê các ứng viên, bao gồm mọi nửa mặc định và mọi bảng mà một quy tắc trỏ tới. Trên Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 trả về tuyến được chọn và địa chỉ nguồn, trong khi Get-NetRoute hiển thị bảng thô — nhưng chi phí hiệu dụng là chỉ số tuyến cộng chỉ số giao diện, nên một bộ điều hợp chậm có thể thua một trận hòa mà nó trông như đang thắng.

Ba trường hợp bao phủ phần lớn những gì bạn sẽ thấy:

• Cùng đích, /24 với /0: /24 thắng về độ dài tiền tố, bất kể chỉ số nói gì.
• Cùng đích, hai /24 với chỉ số khác nhau: chỉ số hiệu dụng thấp hơn thắng.
• Cùng đích, hai bảng, một bảng được một quy tắc chính sách chọn: quy tắc chọn bảng trước, và việc so sánh tiền tố diễn ra bên trong nó.

Trường hợp thứ ba là nơi phần lớn các báo cáo này kết thúc. ip rule của Linux hay một bộ lọc lưu lượng VPN của Windows có thể gửi lưu lượng tới một bảng chưa bao giờ giữ tuyến mặc định của tunnel, và bảng chính trông hoàn hảo suốt thời gian.

Ai thường sở hữu việc đi vòng

Hãy bắt đầu từ hồ sơ, không phải từ bảng. Cấu hình split-tunnel và cài đặt VPN theo từng ứng dụng cố ý để các tiền tố có tên nằm ngoài tunnel; một hồ sơ công việc bảo vệ một subnet riêng và để việc duyệt web chung đi thẳng hoạt động đúng như thiết kế, và việc ghi đè nó phá vỡ chính sách mà nó được tạo ra để thực thi. Hướng dẫn định tuyến VPN của Microsoft vạch cùng ranh giới giữa lưu lượng bị buộc vào tunnel và các ngoại lệ rõ ràng, khiến nó thành một bước kiểm tra chéo hữu ích trước khi sửa bất cứ thứ gì.

Sau đó tìm phần còn sót. Một tuyến trỏ tới giao diện không còn tồn tại, hoặc tới địa chỉ từ mạng trước, xuất hiện sau khi dock, bộ điều hợp USB và cầu nối container đến rồi đi. Xóa nó một lần không phải là kết thúc: hồ sơ kết nối NetworkManager, tệp netplan và các tuyến cố định của Windows cài lại nó ở lần kết nối hoặc khởi động kế tiếp, nên hãy tìm tệp hoặc hồ sơ sở hữu nó trước khi sửa bất cứ thứ gì.

Sau đó kiểm tra IPv6 riêng. ip -6 route và Get-NetRoute -AddressFamily IPv6 giữ trạng thái riêng, tuyến mặc định riêng và hành vi máy khách riêng. Một cuộc kiểm toán chỉ IPv4 không nói gì về một máy chủ hai ngăn xếp lặng lẽ ưu tiên đường IPv6 gốc, và chỉ điều đó có thể khiến một máy khách trông như split-tunnel.

Xác nhận bằng chính luồng của ứng dụng

Ghi lại đích mà ứng dụng thực sự dùng, rồi hỏi hệ thống về đường nó sẽ đi từ địa chỉ nguồn mà ứng dụng đó gắn vào. ip route get 10.20.5.9 from 192.168.1.40 trả lời điều đó trên Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 cộng địa chỉ cục bộ làm điều đó trên Windows. So sánh kết quả với điều hồ sơ tuyên bố. Trang IP công khai của trình duyệt kiểm tra một đích trên một giao thức và không nói gì về địa chỉ riêng đã khởi phát khiếu nại.

Sửa đối tượng hẹp nhất giải thích khác biệt. Nếu ngoại lệ đã được phê duyệt, hãy ghi lại tiền tố và để nguyên; nếu không, hãy xóa tuyến hoặc thêm một tuyến hẹp rõ ràng qua tunnel thay vì hạ chỉ số của tuyến mặc định. Hạ chỉ số không thể vượt một tiền tố dài hơn, và việc sửa tuyến mặc định trong khi hai tuyến /1 sở hữu đường internet cũng không thay đổi gì.

Sau đó kết nối lại tunnel và lặp lại câu hỏi đó. Máy khách cài lại tuyến ở mỗi lần kết nối, nên một thay đổi chỉ tồn tại tới lần bắt tay kế tiếp là chưa được kiểm chứng. Nếu đường vẫn khác, các nghi phạm còn lại là một quy tắc chính sách, một bảng thứ hai hoặc một bộ lọc phía máy khách — không phải tuyến mặc định.

• Nêu tên đích và địa chỉ nguồn mà ứng dụng thực sự dùng.
• In tuyến thắng bằng ip route get hoặc Find-NetRoute.
• Kiểm tra xem một cặp /1 hay một bảng chính sách sở hữu đường internet.
• Liệt kê mọi tiền tố dài hơn /0 khớp với đích.
• Lặp lại kiểm tra IPv6 riêng.
• Truy nguyên tuyến còn lại về tệp, hồ sơ hoặc bộ lọc đã cài nó.
• Kết nối lại và chạy lại câu hỏi trước khi gọi nó đã sửa.

Nếu cả bảy đồng ý với hồ sơ, tunnel đang làm đúng điều nó được cấu hình để làm, và bản sửa thuộc về hồ sơ chứ không phải chỉ số.