Wi-Fi khách vẫn dùng tuyến chính: hãy cho nó lối ra riêng

Bạn đã tạo một mạng khách, thêm tuyến cho nó, và khách vẫn đi ra qua kết nối internet bình thường của bạn. Đường hầm đang hoạt động, LAN chính hoạt động, và các thiết bị khách báo địa chỉ trong dải bạn đã cấp, nên không có gì trông như hỏng. Thứ thường thiếu không phải là tuyến mà là bộ chọn: bộ định tuyến quyết định đường đi trước khi xem xét gói đến từ giao diện nào, và trừ khi có gì đó khớp rõ ràng với lưu lượng khách, lưu lượng đó thừa hưởng giá trị mặc định. Cách sửa là một phân đoạn, một quy tắc chính sách và một đường phản hồi, theo đúng thứ tự đó.

Triệu chứng: khách vẫn đi ra qua WAN

Dấu hiệu là địa chỉ ra. Một thiết bị khách đến internet qua đường hầm sẽ báo địa chỉ của nhà cung cấp đường hầm, còn thiết bị thừa hưởng mặc định sẽ báo kết nối bình thường của bạn. So sánh cạnh nhau một thiết bị khách và một thiết bị LAN chính, vì trường hợp thú vị là khi chúng khác với cấu hình của bạn và khớp với nhau.

Dấu hiệu thứ hai là không có lưu lượng nào trên giao diện đường hầm khi khách duyệt web. Nếu bộ đếm không nhúc nhích, chính sách chưa từng được áp dụng, và việc chỉnh sửa bản thân đường hầm không thể giúp gì.

Bước 1: một phân đoạn thật, không chỉ là cái tên

Tên SSID không tạo ra cách ly. Hãy kiểm tra rằng mạng khách kết thúc trên giao diện, VLAN hoặc cầu riêng của nó, và dải địa chỉ khác với LAN tin cậy. Trên nhiều điểm truy cập tiêu dùng, SSID khách được bắc cầu vào cùng phân đoạn với mọi thứ khác, khiến phần còn lại của công việc này không thể thực hiện cho đến khi điều đó được sửa.

Sau đó xác nhận dải khách và máy chủ DHCP của nó, và giữ cài đặt bộ phân giải gắn với phân đoạn đó thay vì toàn bộ bộ định tuyến. Một mạng con khách chỉ tồn tại dưới dạng chú thích trong quy tắc tường lửa không phải là phân đoạn, và bộ định tuyến sẽ không có giao diện nào để khớp.

Đừng bắc cầu khách vào LAN chính để dễ cấu hình VPN hơn. Việc đó đánh đổi cách ly bạn muốn lấy một lối tắt định tuyến, và đó là lý do thường gặp khiến mạng khách cuối cùng có quyền truy cập máy in và NAS.

Bước 2: chọn đường hầm theo nguồn

Bảng định tuyến được chọn theo đích, nên quy tắc «gửi 0.0.0.0/0 vào đường hầm» áp dụng cho mọi người. Định tuyến theo chính sách thêm chiều thứ hai: chọn bảng theo địa chỉ nguồn. Trên bộ định tuyến dựa trên Linux, đó là một quy tắc bổ sung cộng một bảng riêng, và thứ tự quan trọng vì quy tắc khớp đầu tiên sẽ thắng:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Lệnh cuối đó trả lời trực tiếp câu hỏi: nguồn này sẽ dùng giao diện nào cho đích này. Chạy nó trước và sau khi thay đổi và bạn sẽ biết chính sách có hiệu lực hay không mà không cần chạm vào trình duyệt.

Hầu hết phần sụn bộ định tuyến diễn đạt điều tương tự như một quy tắc giao diện hoặc lựa chọn cổng dựa trên nguồn. Bất kể cú pháp nào nền tảng của bạn dùng, nguyên tắc là như nhau: khớp giao diện vào hoặc tiền tố nguồn, rồi ghi đè tuyến chỉ cho lần khớp đó. Một quy tắc khớp theo đích không thể phân biệt khách với thiết bị trong nhà.

Bước 3: đường phản hồi và phép dịch

Gói đi ra qua đường hầm phải quay về. Hoặc đối tác đường hầm biết đường về tiền tố khách, hoặc bộ định tuyến dịch nguồn khách sang địa chỉ đường hầm. Hãy chọn một và ghi lại, vì các chế độ hỏng trông khác nhau: thiếu đường về cho một kết nối được thiết lập và không bao giờ trả lời, còn thiếu phép dịch thường không tạo ra gì cả.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Nếu bạn chọn phép dịch, hãy nhớ rằng đối tác giờ chỉ thấy một địa chỉ cho mọi khách, nên mọi chính sách theo từng máy khách ở đầu xa đều biến mất. Nếu bạn giữ địa chỉ, cả hai đầu đều cần tiền tố khách trong định tuyến và chính sách của mình, việc này nhiều công hơn và dễ dự đoán hơn.

IPv6 cần quy tắc riêng. Một chính sách viết cho IPv4 không bao phủ họ còn lại, và một thiết bị khách có IPv6 hoạt động sẽ sẵn lòng dùng nó trong khi tuyến IPv4 được định tuyến cẩn thận của bạn nằm không. Hãy định tuyến cả hai họ hoặc tắt IPv6 trên phân đoạn khách, nhưng đừng cho rằng quy tắc kết hợp bạn viết bao phủ những gì thiết bị thực sự làm. Hãy kiểm tra với một máy khách bật cả hai họ, vì đó là trường hợp mà thiết kế phải chịu đựng. Một laptop ưa IPv6 trông đúng trong bài kiểm tra chỉ IPv4 và rò rỉ trong bài thực.

Kiểm tra cách ly, không chỉ duyệt web

Duyệt web chứng minh lối ra đã thay đổi. Nó không chứng minh phân đoạn được cách ly, và cách ly là lý do mạng khách tồn tại. Từ thiết bị khách, hãy thử chạm tới giao diện quản trị của bộ định tuyến, một máy chủ trong LAN tin cậy và một dịch vụ đáng lẽ phải bị từ chối; cả ba đều phải thất bại, và thất bại phải là quyết định chính sách chứ không phải một thời gian chờ mà không ai giải thích được.

Sau đó kiểm tra một thiết bị LAN chính và xác nhận lối ra của nó không thay đổi. Đó là hồi quy mà thiết kế này gây ra thường xuyên nhất: một quy tắc rộng dành cho khách, áp dụng cho mọi giao diện vì việc khớp được viết trên đích.

Cuối cùng, hãy quyết định điều gì xảy ra khi đường hầm ngừng hoạt động. Khách hoặc không có internet hoặc quay về một tuyến bạn chấp thuận, và để điều đó chưa quyết định nghĩa là âm thầm quay về kết nối bình thường, đúng là sự rò rỉ mà chính sách khách muốn ngăn chặn. Công thức định tuyến lưu lượng internet đi qua cùng cách chọn tuyến cho bộ định tuyến dựa trên pfSense.

DNS bắt nguồn từ bộ định tuyến là trường hợp khiến người ta bất ngờ cuối cùng. Nếu khách dùng bộ định tuyến làm bộ phân giải, các truy vấn của chính bộ định tuyến đi theo tuyến của nó thay vì quy tắc khách, nên việc tìm kiếm có thể đi ra qua kết nối bình thường trong khi lưu lượng ứng dụng thì không. Hãy giữ phân đoạn, bộ phân giải và chính sách hỏng trong một ghi chú, và người tiếp theo có thể kiểm tra cả ba mà không phải suy ra thiết kế lại.