Lối ra riêng: bể VPN trên usb0, lưu lượng cổng trên eth0

Các máy khách kết nối và xác thực, rồi lưu lượng của họ đi ra qua đường lên sai, vì tuyến mặc định duy nhất trên máy thuộc về chính cổng. Thay tuyến mặc định đó sẽ làm hỏng việc cập nhật và truy cập quản trị của máy, nên việc chọn phải hẹp hơn «toàn bộ lưu lượng». Dạng khả thi là một quy tắc chính sách dựa trên địa chỉ nguồn bên trong của bể máy khách, trỏ tới bảng định tuyến thứ hai sở hữu WAN thay thế. Từ đó trở đi, danh sách kiểm tra nói về tính đầy đủ và hành vi khi lỗi, không phải về bản thân quy tắc.

Xác nhận địa chỉ nguồn còn tồn tại đến quyết định định tuyến

Một quy tắc chính sách khớp với dải nguồn chỉ kích hoạt khi gói vẫn mang nguồn đó tại thời điểm tra cứu. Lưu lượng máy khách được chuyển tiếp làm vậy, miễn là không có gì ở phía trên viết lại nó trước khi định tuyến. Lưu lượng do chính cổng tạo ra thì không, và chính vì thế tuyến mặc định của cổng có thể ở yên tại chỗ.

Đây là chỗ các thử nghiệm cục bộ đánh lừa. Một curl chạy trên cổng là luồng được tạo cục bộ với địa chỉ của cổng, nên nó dùng bảng chính và không chứng minh gì về đường đi của máy khách. Hãy thử từ một máy khách đã kết nối, hoặc tạo lưu lượng với nguồn thực sự thuộc bể.

Bắt đầu bằng việc ghi ra các giá trị thật: tiền tố của bể, giao diện đường hầm mang nó, địa chỉ và bước nhảy kế tiếp của WAN thứ hai, và số bảng bạn định dùng. Xóa các quy tắc cũ của bất kỳ lần thử trước trước khi thêm quy tắc mới, vì các quy tắc trùng nhau ở những mức ưu tiên khác nhau tạo ra lỗi trông có vẻ ngẫu nhiên.

Dựng một bảng chọn đầy đủ

Bảng không phải là tuyến mặc định có thêm một người bạn. Nó cần đủ tuyến để mọi tra cứu đều được giải quyết bên trong, gồm cả tuyến kết nối cho mạng con WAN để bước nhảy kế tiếp đến được. Với bể 10.77.0.0/24 trên tun1, địa chỉ WAN 203.0.113.20/24 với bước nhảy kế tiếp 203.0.113.1, và bảng 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Quy tắc nằm ở mức ưu tiên thấp hơn mọi quy tắc bắt-tất-cả hiện có, nên các máy khách khớp sẽ đến bảng 600 trước và mọi thứ khác rơi xuống bảng chính. Tài liệu tham chiếu ip-rule mô tả đầy đủ mô hình tra cứu có thứ tự và cú pháp của bộ chọn.

Rồi nghĩ về những gì bảng không chứa. Một đích chỉ có tuyến trong bảng chính, ví dụ mạng con quản trị đến được qua eth0, sẽ không được tìm thấy trong bảng 600 và sẽ không quay lại bảng chính khi ở đó đã có tuyến mặc định. Nếu những đường đó quan trọng, hãy thêm chúng một cách rõ ràng vào bảng đã chọn, đây thường là câu trả lời đúng cho bảng lối ra VPN.

Giữ lưu lượng của chính trình lắng nghe ra ngoài chính sách

Trình lắng nghe OpenVPN có kết nối bên ngoài riêng, được mang qua đường lên mà máy khách đã đến nó. Lưu lượng đó phải giữ đường về như khi đến, và một quy tắc rộng bao trùm địa chỉ công khai của máy chủ hoặc toàn bộ giao diện đường hầm có thể kéo nó vào bảng thay thế. Giới hạn quy tắc trong bể bên trong và không gì khác.

Lọc đường về cũng đáng xem vì cùng lý do. Khi các phản hồi cho máy khách đi ra qua usb0 trong khi yêu cầu đến qua một liên kết khác, một thiết lập rp_filter nghiêm ngặt có thể bỏ những gói mà chính sách định tuyến coi là hợp lệ. Hãy kiểm tra các giá trị sysctl hiệu lực trên cả hai giao diện trước khi kết luận rằng quy tắc đã thất bại.

Thứ tự cũng quan trọng so với mọi thứ khác trên máy. Cầu Docker, VPN thứ hai và mọi quy tắc có sẵn từ ảnh của nhà cung cấp đều thêm mức ưu tiên, nên hãy đọc toàn bộ danh sách quy tắc thay vì cho rằng mức ưu tiên 100 đứng một mình.

Làm cho việc chuyển tiếp và dịch địa chỉ khớp với tuyến

Định tuyến chọn đường lên; nó không cấp quyền chuyển tiếp. Nhân phải bật chuyển tiếp IPv4, và tường lửa phải chấp nhận hướng từ máy khách ra WAN cùng lưu lượng quay về. Một bảng đúng với chuỗi FORWARD bỏ luồng cho ra triệu chứng giống như thiếu tuyến, nên cả hai được kiểm tra trong cùng một lượt.

Nếu WAN thứ hai không định tuyến bể riêng trở lại phía bạn, hãy dịch nguồn ở lối ra đó. Với giao diện có địa chỉ động, lựa chọn thông thường là một quy tắc masquerade hẹp giới hạn trong bể và giao diện:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Ở đây phạm vi quan trọng hơn đích. Một quy tắc masquerade khớp với bất kỳ giao diện ra nào cũng sẽ viết lại lưu lượng đi ra đúng qua eth0, và điều đó che giấu sai sót định tuyến thay vì sửa chúng. Việc dịch chạy sau quyết định định tuyến, nên nó không bao giờ có thể sửa một gói đã bị gửi tới đường lên sai.

Chi phí đường hầm cũng cần chú ý khi các đường khác nhau. Nếu máy khách thương lượng MSS TCP lớn và WAN thay thế có MTU thấp hơn hoặc có đường hầm bên trong, các phân đoạn lớn sẽ kẹt trong khi phân đoạn nhỏ chạy được. Kẹp MSS trên đường chuyển tiếp biến điều đó thành hành vi dự đoán được thay vì treo ngắt quãng.

Quyết định điều gì xảy ra khi usb0 biến mất

Một bảng rỗng không phải trạng thái đóng khi lỗi. Nếu tuyến khớp biến mất, tra cứu tiếp tục sang quy tắc kế tiếp, đến bảng chính và lấy tuyến mặc định eth0. Lưu lượng lẽ ra phải ra qua WAN thứ hai lại lặng lẽ ra qua WAN thứ nhất, điều mà trong một triển khai định tuyến theo chính sách thường là kết quả bạn ít muốn nhất.

Ở nơi việc lùi đó không thể chấp nhận, hãy thêm một tuyến đầu cuối rõ ràng vào bảng 600, ví dụ tuyến mặc định blackhole, hoặc bỏ bể trong tường lửa khi giao diện đang xuống. Mỗi lựa chọn đều là một quyết định bạn có thể viết ra; im lặng thì không.

Tính bền vững là mục cuối. Ai sở hữu cả hai liên kết, dù là trình quản lý mạng, một script điều phối hay vòng đời của kết nối, đều phải tạo lại các tuyến và quy tắc mỗi lần kết nối lại mà không thêm bản trùng. Hãy xác minh bằng một yêu cầu từ máy khách thật và một yêu cầu riêng từ cổng, xác nhận lối ra quan sát được ở cả hai, rồi rút WAN thứ hai và xem kết quả nào trong hai kết quả bạn thiết kế thực sự xảy ra. IPv6 cần bảng, quy tắc và việc dịch riêng; quy tắc IPv4 ở trên không nói gì về nó.