Bảng định tuyến so với tra cứu thực tế: lưu lượng VPN đi đâu

Kết xuất bảng định tuyến là chẩn đoán ít hữu ích nhất khi khắc phục sự cố VPN và là thứ thường được dán nhiều nhất. Bốn mươi dòng tiền tố cho bạn biết máy có thể làm gì, không phải nó đã làm gì cho yêu cầu thất bại. Cơ chế bạn thực sự muốn là tra cứu: với nguồn này và đích này, quy tắc nào khớp, bảng nào được tham vấn, và giao diện cùng bước nhảy tiếp theo nào xuất ra. Bắt đầu từ một đích và một nguồn, rồi đọc bảng với câu hỏi đó trong tay, và cùng đầu ra đó trở thành bằng chứng thay vì nhiễu.

Bảng là một tập ứng viên, không phải quyết định

Mỗi mục mô tả một tiền tố và việc cần làm với lưu lượng khớp với nó: gửi đến một giao diện, chuyển cho bước nhảy tiếp theo, hoặc loại bỏ. Không có gì trong danh sách đó được sắp theo ý định, và mục trông có vẻ cụ thể nhất với con người không phải lúc nào cũng là mục kernel chọn, vì việc chọn đi theo khớp tiền tố dài nhất và, giữa các tiền tố bằng nhau, theo metric.

Vì vậy bước đầu tiên là hỏi kernel thay vì đọc danh sách. Lệnh tra cứu trả lời cho một đích, và với đối số nguồn nó trả lời cho cặp chính xác mà một kết nối được chuyển tiếp hoặc ràng buộc sẽ dùng:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Mỗi địa chỉ ở trên là một ví dụ tài liệu. Điểm mấu chốt là hình dạng câu trả lời: giao diện, địa chỉ nguồn được chọn, cổng và bảng mà mục đó đến từ đó. Nếu đầu ra đó không khớp với giao diện bạn mong đợi, bạn đã khoanh vùng được sự cố bằng một lệnh, và đọc toàn bộ bảng dù nhiều đến đâu cũng không cho bạn biết ứng viên nào đã thắng.

Tra cứu đi qua các quy tắc trước, rồi qua các bảng

Trên Linux quyết định gồm hai giai đoạn. Các quy tắc chính sách được đánh giá theo thứ tự ưu tiên, và quy tắc đầu tiên khớp sẽ nêu tên bảng cần tham vấn; bảng đó sau đó thực hiện khớp tiền tố dài nhất. Một quy tắc có thể khớp theo nguồn, đích, dấu tường lửa, giao diện hoặc tổ hợp, nên bản kết xuất bảng chính có thể hoàn toàn chính xác và hoàn toàn không liên quan đến gói tin bạn đang điều tra.

ip rule show
ip route show table all | head -40
ip route show table 100

Nếu một quy tắc gửi lưu lượng từ nhóm VPN của bạn đến bảng 100, thì bảng 100 mới là bảng quan trọng, và bảng chính là mồi nhử. Đây cũng là cơ chế đằng sau định tuyến dựa trên nguồn trên router: cùng một đích có thể có hai câu trả lời khác nhau tùy thuộc gói tin đến từ đâu, và chỉ tra cứu với đối số nguồn mới tiết lộ câu nào áp dụng.

IPv6 có quy tắc và bảng riêng. Một thiết kế chạy cả hai họ cần cả hai tra cứu, và một câu trả lời IPv4 hoạt động không nói gì về đường đi v6 mà một máy khách hai chồng có thể thích hơn.

Máy khách VPN cài đặt gì

Các máy khách thường không thay thế tuyến mặc định, vì làm vậy sẽ phá vỡ đường đi bên ngoài của chính tunnel. Chúng cài đặt thứ gì đó cụ thể hơn thắng theo độ dài tiền tố: một cặp nửa-mặc-định bao phủ 0.0.0.0/1 và 128.0.0.0/1 là mẹo kinh điển, vì cả hai đều là tiền tố dài hơn 0.0.0.0/0 và cùng nhau bao phủ toàn bộ không gian. Những người khác cài tiền tố riêng cụ thể cộng một quy tắc chính sách, và một số thêm dấu để chỉ lưu lượng được chọn bị bắt.

Đó là lý do "VPN không thay đổi tuyến mặc định của tôi" không phải bằng chứng thất bại. Hãy kiểm tra nó thực sự đã thêm gì, và liệu đích được đề cập có nằm trong các tiền tố đó không:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Hai nửa tuyến rất dễ bị bỏ sót trong bản kết xuất vì chúng không giống tuyến mặc định. Một cấu hình split-tunnel quên bao gồm tiền tố sẽ tạo ra đúng triệu chứng bạn đang truy: ứng dụng lẽ ra phải dùng tunnel lại phân giải và kết nối cục bộ. Hãy so sánh các tiền tố đã cài với các đích mà người dùng thực sự cần, không phải với các địa chỉ bạn tình cờ kiểm tra. Một danh sách split-tunnel bao phủ máy chủ tệp nhưng không bao phủ trình phân giải của nó sẽ tạo ra kết nối phân giải đến địa chỉ công cộng rồi thất bại khi xác thực, trông giống vấn đề mật khẩu nhưng thực ra là vấn đề tuyến đường.

Tuyến bên ngoài cũng phải tồn tại

Tunnel tự nó là lưu lượng. Các gói mang tải trọng được đóng gói đi đến địa chỉ của peer qua giao diện vật lý, và đường đi đó không được định tuyến ngược vào tunnel. Khi điều đó xảy ra, bạn nhận được lỗi đặc trưng trong đó tunnel được thiết lập rồi ngừng truyền lưu lượng, vì phương tiện vận chuyển của tunnel giờ nằm bên trong tunnel.

Kiểm tra địa chỉ của peer như bạn đã kiểm tra đích bên trong, và xác nhận rằng nó phân giải đến giao diện vật lý chứ không phải tunnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Một tuyến đệ quy, một quy tắc chính sách bắt được peer, hoặc một tuyến mặc định bị thay thế bởi máy khách tunnel đầy đủ là ba nguyên nhân thường gặp. Cả ba đều hiển thị trong tra cứu bên ngoài, và không cái nào hiển thị trong bản kết xuất bảng chính được lấy sau sự việc.

Điều đầu ra định tuyến không thể cho bạn biết

Một tra cứu đúng nghĩa là kernel sẽ gửi gói tin đến một nơi hợp lý. Nó không có nghĩa là tường lửa cho phép, chính sách IPsec bao phủ, quy tắc NAT dịch, hay phía xa có tuyến quay về. Mỗi điều đó là một giai đoạn sau, và ghi chú của strongSwan về chuyển tiếp mô tả chuỗi mà một gói tin phải đi qua ở cả hai đầu.

Nó cũng không tính đến ràng buộc ở mức ứng dụng. Một tiến trình có thể ràng buộc với một giao diện, đặt dấu, hoặc dùng trình phân giải riêng và kết nối bằng một tên phân giải khác với thứ bạn đã kiểm tra. Khi tra cứu đúng mà kết nối vẫn thất bại, câu hỏi tiếp theo là tiến trình nào đang làm việc đó và tiến trình đó có thấy cùng bảng bạn thấy không.

Vì vậy hãy giữ chẩn đoán có trật tự: nêu tên đích và nguồn, chạy tra cứu, chỉ đọc bảng và quy tắc mà tra cứu đã nêu, rồi kiểm tra giai đoạn tiếp theo. Trình tự đó giữ một cuộc điều tra định tuyến trong vài phút và để lại một bản ghi người khác có thể theo dõi, điều mà một bảng dán vào không bao giờ làm được.