OpenVPN redirect-gateway: mỗi cờ làm gì với các tuyến đường

Kết nối với redirect-gateway trong hồ sơ, và tuyến mặc định của máy bạn có thể biến mất, tách thành hai hoặc vẫn nằm đúng chỗ cũ, tùy thuộc vào những cờ mà không ai đọc hai lần. Tùy chọn này chỉ đổi trạng thái định tuyến và không gì khác, nên bằng chứng đáng tin duy nhất về việc nó đã làm gì là bảng mà máy khách cài đặt sau đó. Phần tiếp theo là bảng sau khi kết nối, tuyến giữ cho chính đường hầm sống, và lưu lượng IPv6 mà chỉ thị không bao giờ tuyên bố bao phủ. Mỗi bước là một lệnh bạn có thể chạy trên máy khách khi đường hầm đang hoạt động.

Mỗi cờ làm gì với tuyến mặc định

Không có cờ nào, tùy chọn xóa tuyến mặc định thông thường và đặt đường hầm vào chỗ của nó, nên cổng cũ biến mất khỏi bảng trong khi kết nối đang mở. Thêm def1 thì tuyến mặc định đó vẫn nằm trong danh sách, với hai tuyến hẹp hơn làm việc thay. Thêm bypass-dhcp thì tuyến DHCP cũng tồn tại, điều này quan trọng trên mạng nơi máy khách vẫn phải đến được máy chủ DHCP cục bộ. Danh sách cờ trên trang hướng dẫn OpenVPN 2.6 đủ ngắn để đọc một lần, và mỗi mục thay đổi những tuyến nào cuối cùng nằm trong bảng.

Tùy chọn được đẩy xuống cũng hành xử như vậy khi đến, nên hồ sơ máy khách có thể không chứa gì trong khi bảng trông như đã được chuyển hướng hoàn toàn. Điều đó bình thường: máy chủ gửi các cờ, máy khách áp dụng chúng, và tệp cục bộ chưa bao giờ nhắc đến chỉ thị. Khi một lần đẩy có vẻ không làm gì, hãy kiểm tra bộ lọc phía máy khách chấp nhận hoặc loại bỏ các tùy chọn được kéo về, vì tùy chọn bị loại bỏ không gây lỗi ở cả hai phía.

def1 thắng nhờ tính cụ thể mà không chạm vào tuyến mặc định của bạn

Hai tuyến nửa mặc định cùng nhau bao phủ không gian IPv4, 0.0.0.0/1 và 128.0.0.0/1. Mỗi tuyến cụ thể hơn 0.0.0.0/0, nên một lần tra cứu ưu tiên chúng trong khi tuyến mặc định thật vẫn nằm trong bảng cho mọi thứ yêu cầu kết quả khớp ít cụ thể nhất.

Đọc bảng chứ không đọc hồ sơ, vì chỉ bảng mới cho biết bạn đang ở trường hợp nào. Hai dòng là đủ để phân biệt chúng:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Để ý giao diện và số đo trên mỗi dòng, không chỉ đích đến. Một tuyến mặc định trỏ vào đường hầm và một cặp nửa mặc định trỏ vào đường hầm mô tả cùng một ý định và thất bại khác nhau khi đường hầm sập, vì trong một trường hợp tuyến dự phòng vẫn còn. Ghi cả hai trường vào ghi chú thay đổi. Tuyến dự phòng còn sót lại đôi khi là thứ giữ một phiên từ xa sống đủ lâu để sửa đường hầm, và nó cũng là thứ rò rỉ lưu lượng khi ý định là đường hầm đầy đủ.

Giữ điểm cuối của đường hầm luôn tiếp cận được

Máy khách cần một tuyến đến đầu xa của đường hầm mà bản thân nó không đi qua đường hầm. OpenVPN cài tuyến máy chủ đó trước khi thay đổi bất cứ thứ gì khác, và việc sửa tuyến bằng tay hoặc một máy khách VPN thứ hai có thể lấy nó đi. Triệu chứng sau đó là một kết nối báo đã kết nối rồi không cho gì đi qua.

Hỏi nhân hệ điều hành sẽ dùng giao diện nào cho địa chỉ điểm cuối khi đường hầm đang mở. Câu trả lời phải nêu giao diện vật lý và cổng của nó, không bao giờ là tun0:

ip route get 198.51.100.20

Nếu lần tra cứu đó trả về thiết bị đường hầm, đường hầm đang mang vận chuyển của chính nó và sẽ sụp ngay khi một gói phải đi ra ngoài. Các tiền tố cục bộ, bộ điều hợp thứ hai và định tuyến theo chính sách vẫn quan trọng ở đây, nên một lần chuyển hướng chạy được trên máy tính xách tay sạch có thể thất bại trên một máy chủ có giao diện quản trị và hai tuyến mặc định. Thường thì hồ sơ bị đổ lỗi cho những gì quy hoạch địa chỉ đã làm.

Lưu lượng IPv6 tiếp tục dùng bảng của riêng nó

Chuyển hướng IPv4 để yên IPv6, và hai họ được thay đổi bằng những cờ khác nhau. Trên máy chủ hai ngăn xếp có tuyến mặc định v6 hoạt động, lưu lượng v4 có thể nằm trọn trong đường hầm trong khi mọi đích hỗ trợ v6 đi ra qua liên kết vật lý. Một máy chủ trông đúng trong bảng này lại rò rỉ trong bảng kia.

Kiểm tra bảng v6 sau khi kết nối thay vì cho rằng đường hầm đã bao phủ nó. Chỉ thị mang các cờ họ địa chỉ chính vì lý do này, và hồ sơ bỏ qua chúng sẽ thừa hưởng điều nền tảng làm mặc định:

ip -6 route show default
ip -6 route get 2001:db8::10

Chứng minh ứng dụng dùng giao diện nào

Trạng thái đã kết nối không phải là chặn, và thay đổi tuyến không phải là công tắc ngắt. Nếu lưu lượng trực tiếp phải dừng khi đường hầm hỏng, chính sách đó nằm trong tường lửa và cần phép thử riêng.

Hãy thử con đường mà ứng dụng thực sự đi chứ không phải con đường hồ sơ mô tả. Hỏi tuyến trước, sau đó lần lượt gắn một yêu cầu vào từng giao diện và so sánh những gì phía xa báo cáo:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Nếu cả hai yêu cầu trả về cùng một địa chỉ, ứng dụng không dùng đường hầm dù bảng định tuyến nói rằng nó nên dùng. Nếu chỉ yêu cầu gắn với đường hầm thành công, con đường vật lý bị lọc cho đích đó và đường hầm đang làm đúng điều bạn yêu cầu. Ghi các cờ, các tuyến đã cài, lần tìm điểm cuối và cả hai kết quả ra vào nhật ký thay đổi, để người tiếp theo thừa hưởng sự thật thay vì ảnh chụp màn hình.