Một thiết bị qua VPN của router cần ba quy tắc, không phải một công tắc

Trên VPN của router không có công tắc cho từng thiết bị; công tắc bạn đang tìm là một lối tắt ghi các quy tắc định tuyến chính sách thay bạn. Thời điểm một laptop, một dải cổng, một danh sách địa chỉ hoặc một phân đoạn LAN phải dùng đường hầm trong khi mọi thứ khác ở lại WAN, bạn đang xây một tuyến chính sách chứ không phải bật một tính năng. Công việc có ba phần chuyển động, và mỗi phần hỏng theo một cách: một bảng được đánh dấu mà không có tuyến trông như im lặng, một dấu đặt sai chuỗi trông như không có gì xảy ra, và một quy tắc NAT thiếu trông như đường hầm kết nối được mà không chở gì. Hai phần nữa cũng mất vì chúng không bao giờ xuất hiện trong quy tắc mangle, và đó là DNS cùng IPv6.

Lầm tưởng: đường hầm là một thiết lập của máy khách

Máy khách VPN phía router làm tốt một việc thô: nó đặt 0.0.0.0/0 vào bảng định tuyến chính và trỏ vào đường hầm. WireGuard rút ra điều đó từ AllowedIPs, OpenVPN và từ một redirect-gateway do máy chủ đẩy xuống, và cả hai đều đổi đường đi cho mọi máy chủ sau router. Thu hẹp AllowedIPs hoặc thêm route-nopull thay đổi thứ máy khách cài đặt. Nó không thay đổi việc bản cài đặt áp dụng cho ai, vì máy khách không bao giờ nhìn thấy thiết bị. Nó chỉ thấy gói tin.

Chọn theo nguồn hoặc đích là một quyết định định tuyến, nên nó thuộc lớp chính sách của router: một quy tắc mangle cộng một bảng thứ hai trên RouterOS, một MARK cộng một ip rule trên OpenWrt hoặc DD-WRT, hoặc một quy tắc tường lửa có cổng là đường hầm trên pfSense. Công thức máy khách WireGuard của Netgate là thứ cần đọc trước khi đoán, vì trên nền tảng đó cổng của quy tắc, việc gán giao diện và mục NAT đi ra đều phải đồng ý trước khi một máy khách dùng đường hầm.

Nửa còn lại của lầm tưởng là router thứ hai. Mua thêm một hộp nữa, hoặc chuyển thiết bị sang SSID khách, thường hiệu quả, và lý do không phải phần cứng: nó đặt thiết bị vào subnet riêng, điều này cho bạn bộ chọn nguồn mà firmware đã hiểu. Nếu bạn định nghĩa được phân đoạn đó trên router mình sở hữu, chiếc hộp thêm chỉ giải một vấn đề bạn không có.

Phần một: một đường hầm không phải tuyến mặc định

Trên RouterOS, thêm máy khách không có tuyến mặc định và cho đường hầm bảng riêng. Tuyến đầu là mặc định được đánh dấu; tuyến thứ hai là nửa thất bại.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Tuyến không thể tới là lý do bảng được đánh dấu thắng danh sách ngoại lệ trong bảng chính. Khi đường hầm sập, gói được đánh dấu nhận ngay không thể tới thay vì lặng lẽ quay về WAN, nên lỗi hiện ra trong thông báo lỗi của ứng dụng chứ không phải trên một trang định vị địa lý bạn kiểm tra một giờ sau đó.

RouterOS 7 tách những gì 6.x giữ chung: bạn khai báo bảng bằng /routing table add name=vpn fib, rồi tham chiếu nó theo tên trên tuyến và trong quy tắc mangle. Một đoạn 6.x ghi routing-mark mà không định nghĩa bảng sẽ nạp sạch và không khớp gì cả. Kiểu cổ điển khác là hai nửa 0.0.0.0/1, hoặc hai mặc định cùng khoảng cách trong một bảng: nhân chọn một, và hành vi có thể đổi sau khi khởi động lại.

Phần hai: đánh dấu trước khi tra tuyến

Bộ chọn quyết định gói nào vào bảng đó. RouterOS thường bắt đầu bằng một danh sách địa chỉ cho chính sách đích, hoặc một địa chỉ nguồn cho chính sách thiết bị:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Firmware Linux làm điều tương tự với một dấu netfilter và một quy tắc dẫn gói được đánh dấu vào bảng bạn đã nạp:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Chuỗi không phải lựa chọn phong cách. Khi gói tới FORWARD thì việc tra tuyến đã xảy ra rồi, nên MARK hay DROP ở đó chỉ có thể ghi lại hoặc bỏ. Dấu phải rơi vào PREROUTING cho lưu lượng được chuyển tiếp và vào OUTPUT cho lưu lượng do chính router tạo ra, nơi DNS, NTP và các kiểm tra cập nhật của router sống. Chính đường ra đó là lý do thường gặp khiến một cấu hình được đưa toàn bộ vào đường hầm vẫn trả lời từ resolver của nhà mạng trong bài kiểm tra rò rỉ.

Chính sách thiết bị cần một sự khớp không trôi. Hãy đặt trước địa chỉ trong DHCP, hoặc khớp một giao diện cho phân đoạn riêng; một địa chỉ chuyển sang thiết bị khác sau này sẽ lặng lẽ áp đường hầm cho máy khách sai. Một cầu nối theo từng SSID với subnet riêng là phiên bản bền hơn của cùng ý tưởng, và nó cũng cho các quy tắc IPv6 một chỗ để sống.

Phần ba: NAT, DNS và ngoại lệ LAN

Lưu lượng đi ra qua đường hầm cần một địa chỉ nguồn mà phía bên kia sẽ trả lời. Thu hẹp việc dịch địa chỉ vào giao diện đường hầm: out-interface=VPN_NAME trên RouterOS, -o tun0 trên Linux, một mục NAT đi ra khớp trên pfSense. Một quy tắc masquerade không có phạm vi đó sẽ ghi lại lưu lượng bạn định để yên, và triệu chứng là thiết bị không ở trong đường hầm mất địa chỉ công cộng.

Ngoại lệ LAN tạo ra nhiều chủ đề hỗ trợ hơn chính đường hầm. Nếu bảng được đánh dấu chỉ có một tuyến mặc định, một đích máy in hay NAS từ thiết bị được chọn sẽ khớp với mặc định đó và biến mất vào đường hầm. Thêm tuyến LAN vào cùng bảng, hoặc loại subnet cục bộ trong bộ chọn; cả hai đều chạy, và việc loại trừ dễ giữ đúng hơn khi bạn thêm VLAN sau này.

DNS đi một đường riêng. Các truy vấn router chuyển tiếp bắt nguồn từ router và theo OUTPUT, không theo dấu được chuyển tiếp, nên một laptop được đưa toàn bộ vào đường hầm vẫn có thể phân giải tên qua nhà mạng. Hãy trỏ máy khách tới một resolver tiếp cận được qua đường hầm, hoặc đánh dấu lưu lượng port-53 của chính router, rồi kiểm tra địa chỉ đã phân giải thay vì cho rằng câu trả lời đã đi cùng yêu cầu web.

Khi quy tắc khớp nhưng ứng dụng vẫn dùng WAN

Danh sách đích già đi rất nhanh. Một tên phân giải thành địa chỉ không có trong danh sách, nên yêu cầu đi qua WAN trong khi mọi bài kiểm tra bạn làm với địa chỉ trong danh sách đều chạy. Hãy làm mới danh sách từ đúng resolver mà máy khách dùng, và ưu tiên bộ chọn dựa trên nguồn khi bạn thật sự muốn toàn bộ lưu lượng từ một thiết bị.

IPv6 là đường vòng im lặng. Thiết bị có một họ địa chỉ thứ hai với tuyến mặc định và bộ quy tắc riêng, và chỉ khớp địa chỉ IPv4 là một nửa chính sách. Hãy áp dụng cùng bộ chọn cho ip6tables hoặc tương đương nftables, hoặc tắt IPv6 trên phân đoạn đó một cách có chủ ý chứ không phải vô tình.

Các kết nối đã thiết lập cũng quan trọng. Một mục conntrack tạo trước khi thay đổi vẫn tiếp tục đi theo đường cũ cho tới khi hết hạn, nên một trình duyệt để mở trong lúc sửa trông y hệt một quy tắc chưa bao giờ được áp. Hãy mở một kết nối mới, hoặc xóa trạng thái, trước khi đánh giá chính sách.

Kiểm tra bằng hai thiết bị và một lần khởi động lại

Thử thiết bị cần ở trong đường hầm và thiết bị không cần, rồi so bước nhảy thứ hai thay vì một con số tốc độ. Traceroute từ mỗi bên cho thấy hoặc cổng của đường hầm hoặc cổng của nhà mạng ở bước nhảy thứ hai; nếu cả hai trông giống nhau thì dấu hoặc bảng không làm đúng như quy tắc nói. Dùng kết nối mới cho bài kiểm tra.

Sau đó khởi động lại. Thứ tự khởi động là nơi một chính sách đang chạy trở nên hỏng, vì máy khách phải sống trước khi tuyến không thể tới được cài đặt, và một ảnh chụp đã lưu khôi phục bộ quy tắc cũ sẽ ghi đè bảng của bạn. Kiểm tra rằng mọi quy tắc có trong cấu hình đã lưu và mặc định được đánh dấu tồn tại sau khi khởi động, không chỉ sau khi bạn gõ nó.

Nếu có gì hỏng, hãy bỏ dấu trước và xem lưu lượng bình thường có trở lại không, rồi bỏ bảng. Thứ tự đó cho bạn biết mình đang đuổi theo một vấn đề định tuyến hay một vấn đề tường lửa, và nó để lại cho gia đình một cái máy in còn chạy trong khi bạn làm xong việc.