Chỉ định tuyến một dịch vụ web cục bộ ra ngoài VPN theo cổng

Một dịch vụ của máy chủ phải trả lời internet qua đường lên vật lý trong khi mọi thứ khác trên máy vẫn dùng đường hầm. Ba điều kiện quyết định liệu định tuyến dựa trên chính sách có gánh được tải đó hay không, và mỗi điều kiện đều rẻ để kiểm tra trước khi viết quy tắc. Dịch vụ phải kết thúc trên máy chủ này chứ không phải sau DNAT hay một cổng được chuyển tiếp, chính các quy tắc của VPN phải cho phép ngoại lệ, và bạn phải khớp phản hồi chứ không phải yêu cầu. Nếu một trong ba thất bại, các lệnh bên dưới vẫn nạp sạch nhưng không làm gì hữu ích.

Kiểm tra ba điều kiện trước khi viết quy tắc

Một container công bố cổng qua DNAT, hoặc một máy chủ nằm sau chuyển tiếp cổng, tạo ra các gói không bắt nguồn từ máy chủ này. Những gói đó được chuyển tiếp, nên một quy tắc dựa trên đầu vào cục bộ của máy chủ không bao giờ thấy chúng và lưu lượng tiếp tục đi theo tuyến mặc định. Xác nhận dịch vụ thực sự chạy ở đâu trước khi tiếp tục, vì đây là điều kiện mà mọi người hay nhầm nhất.

Điều kiện thứ hai là chính sách chứ không phải cơ chế. Bất kỳ tuyến nào đi vòng qua đường hầm đều là ngoại lệ đối với mục đích của đường hầm, và trên một máy chủ được quản lý, quyết định đó thuộc về người sở hữu chính sách, không phải người đang gỡ lỗi thời gian chờ.

Khớp phản hồi, không phải cổng đích của máy khách

Phản hồi từ một máy chủ lắng nghe trên TCP 443 rời máy chủ với cổng nguồn 443. Trình duyệt trên cùng máy chủ khi kết nối tới một trang HTTPS từ xa sẽ gửi một cổng nguồn tạm thời và cổng đích 443. Cả hai đều là lưu lượng cổng 443 và chỉ một trong số đó nên dùng bảng WAN, đó là lý do vì sao khớp theo cổng đích sẽ bắt nhầm nửa kia.

Hướng phản hồi là thứ bạn có thể phân biệt. Khớp cổng nguồn, giới hạn quy tắc cho các gói được tạo cục bộ, và quy tắc bao phủ các phản hồi của chính dịch vụ mà không đụng tới các yêu cầu của trình duyệt.

Xây dựng một bảng trả về đầy đủ trước khi quy tắc trỏ tới nó

Bảng rỗng nghĩa là không có tuyến, trông giống dịch vụ hỏng hơn là chính sách hỏng. Hãy điền trước, với số bảng và mức ưu tiên mà không thứ gì khác trên máy chủ đòi:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Đọc các con số từ máy chủ đang chạy thay vì sao chép. ip -4 rule show cho bạn biết mức ưu tiên nào đã bị chiếm, và thêm một quy tắc vào mức ưu tiên đã tồn tại sẽ âm thầm đổi thứ tự của hai quy tắc mà xét riêng đều trông ổn.

Hai bộ chọn làm công việc thực sự ở đây. iif lo là cách nhân báo cáo các gói do chính máy chủ tạo ra, nên quy tắc không thể vô tình bắt lưu lượng được chuyển tiếp đến từ bên ngoài. ipproto tcp sport 443 thu hẹp nó vào một giao thức vận chuyển và một cổng, chặt như yêu cầu cho phép. Bỏ bộ chọn giao thức đi và quy tắc cũng bắt UDP 443, một dịch vụ khác với hành vi khác.

Giữ các phản hồi riêng tư bên trong đường hầm

Nếu cùng một bộ lắng nghe cũng trả lời các máy khách ở phía riêng tư, một tuyến WAN mặc định bắt tất cả trong bảng 100 sẽ cố gửi những phản hồi đó trở lại qua đường lên. Thêm các tiền tố riêng tư không được đi theo mặc định WAN, hoặc để chúng rơi xuống quy tắc chính sách tiếp theo:

ip -4 route add table 100 throw 10.90.0.0/24

Một tuyến throw kết thúc việc tra cứu trong bảng này và trả gói về danh sách quy tắc, nên chính sách VPN theo sau có cơ hội của nó. Bản thân nó không định tuyến gì vào đường hầm, và nếu không quy tắc nào sau đó có tuyến khớp, gói vẫn thất bại; hãy xác minh chính sách tiếp theo thay vì cho rằng throw là cách sửa.

Lọc đường dẫn ngược và các quy tắc tường lửa của máy chủ vẫn áp dụng cho yêu cầu đến. Hãy xem phán quyết thực của chúng trước khi nới lỏng kiểm tra, vì ngoại lệ định tuyến không làm rp_filter chấp nhận một đường quay về mà nó coi là bất khả thi.

Thử TCP, rồi QUIC, rồi khởi động lại

Mở một kết nối từ máy khách bên ngoài được cấp quyền và một từ phía riêng tư, rồi kiểm tra việc tra cứu phản hồi với địa chỉ và cổng thực. Nếu phản hồi bên ngoài dùng bảng 100 còn phản hồi riêng tư thì không, chính sách đang làm đúng như bạn yêu cầu.

HTTP/3 được phục vụ trên UDP và sẽ không khớp với quy tắc TCP, nên một bộ lắng nghe QUIC cần bộ chọn riêng, nếu không nó sẽ tiếp tục dùng đường hầm trong khi HTTPS hoạt động. Lưu các quy tắc bạn chọn với thành phần sở hữu giao diện, và xác nhận chúng sau khi kết nối lại hoặc gia hạn DHCP. Khi một trình quản lý đối thủ xoá một tuyến thời gian chạy sau khi khởi động lại, đó là vấn đề sở hữu cần sửa tại nguồn, không phải lý do để thêm các quy tắc NAT rộng hơn lên trên.