Tuyến mặc định cũ của bạn vẫn tồn tại sau OpenVPN một cách có chủ đích

Bạn kết nối đường hầm, chạy ip route, và cổng mặc định ban đầu vẫn nằm đó. Ý nghĩ tiếp theo là ứng dụng khách đã không tiếp quản được tuyến, nên bạn xóa tuyến mặc định bằng tay và mất kết nối hoàn toàn. Mục đó đáng lẽ phải được giữ lại. Với redirect-gateway def1, OpenVPN cài hai tuyến cụ thể hơn vượt trên tuyến mặc định thông thường thay vì thay thế nó. Cổng cũ vẫn ở lại và ngừng chở lưu lượng bạn đang thử nghiệm.

def1 thực sự làm gì

Cờ này thêm 0.0.0.0/1 và 128.0.0.0/1, cả hai trỏ vào đường hầm. 0.0.0.0/1 nhận mọi địa chỉ có octet đầu từ 0 đến 127, và 128.0.0.0/1 nhận từ 128 đến 255, nên mọi đích IPv4 đều có một kết quả khớp cụ thể hơn tuyến mặc định cũ. Độ dài tiền tố, không phải chỉ số metric, quyết định tuyến nào thắng.

Việc giữ nguyên tuyến mặc định ban đầu là có chủ đích. Ứng dụng khách không phải nhớ nó đã thay thế cái gì, và nó không viết lại tuyến chở kết nối của chính nó tới máy chủ VPN. Khi ngắt kết nối, nó gỡ hai nửa tuyến và bảng trở lại như cũ.

Tại sao là /1 mà không phải /0

Định tuyến chọn tiền tố khớp dài nhất, không phải metric thấp nhất, nên /1 thắng /0 bất kể metric của tuyến mặc định nói gì. Cả hai nửa tồn tại vì một /1 chỉ phủ một nửa không gian; nếu chỉ có 0.0.0.0/1, mọi thứ từ 128.0.0.0 trở lên vẫn đi theo tuyến mặc định cũ, tạo ra triệu chứng khó hiểu là một số trang hoạt động còn số khác thì không.

Tăng hay giảm metric của tuyến mặc định cũ không thay đổi gì, và một tuyến mặc định có metric thấp hơn trên giao diện khác cũng không cướp lưu lượng. Độ dài tiền tố quyết định trước, và chỉ các tiền tố bằng nhau mới quay về metric.

Đọc một bảng định tuyến thật

Một máy đã kết nối có thể hiển thị cả ba mục cùng lúc, với đường hầm chở hai nửa và cổng ban đầu vẫn được liệt kê. Các địa chỉ là ví dụ chứ không phải cấu hình để sao chép, vì tên giao diện, cấu trúc liên kết đường hầm và các tuyến bổ sung khác nhau theo nền tảng và ứng dụng khách.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Điều quan trọng là mối quan hệ: hai nửa cụ thể nằm trên một tuyến mặc định chung. Dòng cổng cũ vẫn còn vì không có gì thay thế nó.

Kiểm tra tuyến mà gói tin thực sự đi

Các tuyến cụ thể hơn vẫn có thể thắng: một tuyến cho dải riêng, một mạng con cục bộ hoặc chính địa chỉ của máy chủ VPN dài hơn một /1. Đường hầm cần một đường ra bên ngoài tới máy chủ của nó, và gửi kết nối đó trở lại đường hầm sẽ làm nó hỏng ngay lập tức. Trên Linux, hãy hỏi nhân thay vì đọc bảng bằng mắt: ip route get với đích bạn quan tâm in ra tuyến được chọn, giao diện và nguồn. Nếu định tuyến theo chính sách được cấu hình, hãy xem cả các quy tắc, vì một quy tắc có thể chọn bảng khác trước khi bảng chính được tra cứu.

Nếu chỉ một phần IPv4 cư xử sai, hãy xác nhận cả hai nửa đã được cài rồi tìm ngoại lệ khớp với đích đang lỗi. Xóa tuyến mặc định cũ không phải là cách sửa, và nó gỡ mất tuyến mà ứng dụng khách cần để dỡ đường hầm một cách sạch sẽ.

def1 không bao gồm điều gì

Hai mục IPv4 không nói gì về IPv6: một máy có kết nối IPv6 vẫn dùng tuyến mặc định riêng của nó cho tới khi có thứ gì đó chuyển hướng riêng họ giao thức đó, đó là lý do một phần lưu lượng dường như đi vòng qua đường hầm trên mạng hai chồng. Các ứng dụng khách và trình quản lý mạng khác triển khai định tuyến toàn đường hầm theo cách khác, và bảng của chúng sẽ không khớp. Hành vi def1 mô tả ở đây thuộc về cờ được ghi trong tài liệu của OpenVPN, không phải mọi VPN trên máy.

Một kill switch trả lời một câu hỏi khác: máy làm gì khi đường hầm sập. Ưu tiên định tuyến quyết định lưu lượng đi đâu khi đường hầm đang lên; nó không quyết định tường lửa làm gì sau đó. Thứ tự công việc: đọc bảng, xác nhận cả hai nửa tồn tại, chạy ip route get cho đích đang lỗi, kiểm tra quy tắc chính sách, rồi xem IPv6 riêng. Hãy để tuyến mặc định cũ ở nguyên chỗ của nó.