Metric tuyến OpenVPN: vì sao tuyến đã chọn vẫn thua

Bạn đã thêm metric cho một tuyến trong hồ sơ, kết nối lại, mà lưu lượng vẫn đi ra qua giao diện sai. Con số hiếm khi là vấn đề. Metric chỉ sắp thứ tự các ứng viên mà hệ điều hành đang so sánh, còn một tiền tố cụ thể hơn hoặc một bảng chính sách được xét trước sẽ quyết định trước khi bất kỳ metric nào được đọc.

Hãy xem hồ sơ trước, rồi bảng đã cài, rồi các quy tắc chọn. Thứ tự đó khớp với cách ứng dụng dựng tuyến và ngăn bạn chỉnh một giá trị không bao giờ tham gia phép so sánh.

Đọc dòng tuyến theo thứ tự trường

Ứng dụng Community OpenVPN 2.6 chấp nhận bốn trường trên một dòng route cho IPv4: mạng, mặt nạ mạng, cổng và một metric tùy chọn. Vị trí cổng là nơi đặt từ khóa đặc biệt vpn_gateway. Nó nghĩa là chặng kế tiếp phía VPN cho kết nối này, không phải số bảng định tuyến và không phải router vật lý của bạn. Nếu bỏ sót điều đó, phần còn lại của dòng sẽ được đọc với hiểu nhầm về việc nó làm gì. Tài liệu tham chiếu tùy chọn mạng mô tả cả bốn trường.

Với một đích riêng tư, dòng có thể như sau:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Số 30 tường minh áp dụng cho tuyến đó, còn 50 vẫn là mặc định cho mọi tuyến khác trong hồ sơ không ghi số. Đọc dòng từ trái sang phải là đủ để biết giá trị nào áp dụng ở đâu.

route-metric là một giá trị mặc định, không phải thứ hạng

route-metric đặt giá trị dự phòng cho các tuyến không mang số riêng. Nó không đẩy một tuyến lên trên bất cứ thứ gì và không sắp xếp lại các tuyến đã cài với metric tường minh.

Sự phân biệt đó quan trọng khi hồ sơ trộn cả hai dạng. Một dòng route-metric gần đầu trông có vẻ quyết định và dễ bị đổ lỗi, trong khi tuyến thực sự chở lưu lượng có thể mang metric riêng ở ba dòng bên dưới.

Nếu bạn muốn một tuyến ưu tiên một đường đi, hãy đặt con số vào tuyến đó. Nếu bạn muốn một mặc định nhất quán trong hồ sơ được tạo tự động, hãy dùng route-metric và để nguyên các dòng riêng lẻ. Trộn cả hai mà không có lý do là cách một hồ sơ kết thúc bằng một tuyến không ai giải thích được.

Xem ứng dụng đã cài gì

Khi kết nối lại xong, hãy hỏi nhân hệ điều hành chứ không hỏi hồ sơ.

ip route show liệt kê các tuyến mà ứng dụng đã thêm, và ip route get 172.20.5.10 trả lời câu hỏi hữu ích hơn: đích này thực sự sẽ dùng tuyến nào, với địa chỉ nguồn nào. Nếu đích không có trong bảng, ứng dụng đã không cài nó.

Một chỉ thị cục bộ, một lần đẩy từ máy chủ hoặc một trình quản lý mạng khác có thể thêm hoặc bỏ cùng tiền tố, và bên ghi sau cùng thắng. Hãy để tuyến tới điểm cuối trong tầm mắt khi làm việc, vì kết nối cần một đường tới máy chủ từ xa không chạy qua đường hầm mà nó đang dựng.

Vì sao metric nhỏ hơn vẫn thua

Metric so sánh các tuyến tới cùng một đích. Chúng không làm một tiền tố rộng trở nên cụ thể hơn. Khi redirect-gateway def1 được dùng, ứng dụng cài 0.0.0.0/1 và 128.0.0.0/1, và hai tiền tố đó bao phủ toàn bộ không gian IPv4 cụ thể hơn 0.0.0.0/0. Một metric bằng 1 trên tuyến mặc định không vượt qua chúng.

Logic tương tự áp dụng cho mọi cặp chồng lấn. Một /24 thắng một /16 cho một địa chỉ nằm trong nó, bất kể các con số gắn kèm, vì tra cứu chọn kết quả khớp cụ thể nhất trước rồi mới so sánh metric giữa các tuyến ngang nhau.

Đây là phần trông như lỗi metric mà không phải. Hãy kiểm tra độ dài tiền tố ở cả hai ứng viên trước khi đổi bất kỳ con số nào.

Quy tắc chính sách chạy trước bảng

Trên Linux, ip rule quyết định bảng định tuyến nào được tra. Các quy tắc được đánh giá theo thứ tự ưu tiên, nên một bảng trước đó có thể trả về một tuyến trước khi bảng chính được đọc. Một metric nằm trong main không thể vượt qua kết quả khớp trong một bảng được tra trước.

Dùng ip rule show rồi truy vấn bảng cụ thể, ví dụ ip route show table 100, để xem quy tắc đó sẽ trả về gì. Nếu một ứng dụng VPN hoặc môi trường chạy container đã thêm quy tắc, câu trả lời có thể ở đó chứ không ở bảng bạn đang đọc. Địa chỉ nguồn cũng quan trọng, vì một quy tắc có thể khớp theo nguồn và phân giải cùng một đích khác nhau cho lưu lượng đường hầm và lưu lượng LAN.

Kiểm tra đích, không phải thứ hạng

Phép thử kết thúc tranh luận là một truy vấn duy nhất tới một máy chủ trong mạng con dự định, cộng với việc kiểm tra địa chỉ nguồn mà nhân hệ điều hành đã chọn. Nếu cặp đó khớp với thiết kế, metric đang làm đúng việc của nó kể cả khi danh sách không trông như một thứ hạng gọn gàng.

Để IPv6 và DNS ra ngoài phép kiểm tra này. Chúng được cấu hình bằng các chỉ thị khác và được phân giải bằng các cơ chế khác, và một tuyến IPv4 hoạt động không nói gì về cả hai. Hãy đổi từng lớp một rồi chạy lại truy vấn.