VPN trên router hoạt động nhưng máy khách LAN không có internet

Trạng thái báo đường hầm đã lên, trình duyệt trên chính router vẫn tải được trang, vậy mà mọi thiết bị phía sau vẫn hết thời gian chờ. Sự kết hợp đó thu hẹp vấn đề vào một tầng mà hầu hết hướng dẫn VPN không bao giờ nhắc tới: router không phải máy chủ duy nhất có gói tin cần sống sót qua đường hầm. Lưu lượng sinh ra tại chỗ và lưu lượng được chuyển tiếp đi theo những đường khác nhau trong cùng một chiếc hộp. Thử từ một máy khách và sự khác biệt không còn là lý thuyết.

Đọc lỗi từ một máy chủ LAN

Bắt đầu từ thiết bị bị lỗi, vì chẩn đoán chạy trên router trả lời một câu hỏi khác. Xác nhận rằng cổng mặc định của máy khách là router này, ghi lại địa chỉ nguồn và mạng con của nó, rồi xem thứ gì rời khỏi giao diện đường hầm của router.

Nếu địa chỉ của máy khách được dịch, phía xa thấy địa chỉ đường hầm, và từ đó mọi thứ trông khỏe mạnh trong khi máy khách vẫn lỗi. Nếu không được dịch, phía xa phải biết tuyến quay về mạng con của máy khách, và nhiều cổng không có tuyến như vậy theo mặc định. Dù thế nào, thành công của chính router là không liên quan, vì các gói tin của nó được sinh ra tại chỗ và chưa bao giờ đi qua đường chuyển tiếp.

Lưu lượng tại chỗ và lưu lượng chuyển tiếp là khác nhau

Linux và phần lớn firmware router xử lý các gói tin do chính chiếc hộp sinh ra khác với các gói tin đi qua nó. Chuỗi output thấy loại thứ nhất, chuỗi forward thấy loại thứ hai, và một chính sách điều chỉnh cho lưu lượng của chính router có thể để việc chuyển tiếp nguyên vẹn.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Kiểm tra xem việc chuyển tiếp có được bật hay không, rồi đọc chuỗi forward thay vì chuỗi output. Một quy tắc cho phép kết nối bên ngoài đã mã hóa không phải là quy tắc cho phép chuyển tiếp các gói tin đã giải mã, và nhầm lẫn hai điều đó tạo ra đúng triệu chứng này. Đường hầm đã lên chỉ chứng minh điều thứ nhất.

Đường quay về cũng phải tồn tại

Việc dịch địa chỉ nguồn quyết định có cần đường quay về hay không. Với masquerading trên giao diện đường hầm, các phản hồi quay lại địa chỉ đường hầm và router dịch ngược chúng. Không có nó, cổng phía xa cần một tuyến rõ ràng tới mạng con của máy khách, và chính sách của nó cũng phải cho phép hướng đó.

Ghi lại việc triển khai dùng kiểu nào trong hai kiểu trước khi thay đổi bất cứ điều gì, vì các cách sửa chỉ về hướng ngược nhau. Thêm dịch địa chỉ sẽ che đi một tuyến quay về bị thiếu và làm hỏng các ứng dụng cần địa chỉ nguồn gốc. Thêm tuyến quay về mà không dịch sẽ thất bại âm thầm khi tường lửa phía xa loại bỏ nguồn lạ. Chọn một, ghi thành tài liệu và làm cho phía bên kia khớp theo.

DNS của máy khách thuộc cùng một đợt rà soát. Bộ phân giải của router có thể trả lời trong khi một máy khách trỏ tới máy chủ khác không nhận được gì.

Kiểm chứng một luồng được phép và một luồng bị chặn

Sau khi sửa, hãy thử một kết nối mới từ máy khách thay vì một phiên router đang có. Rồi xác nhận rằng một đoạn mạng không nên dùng đường hầm vẫn không dùng nó.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Kiểm tra địa chỉ nguồn quan sát được ở đầu xa, vì nó cho biết kiểu nào thực sự đang chạy. Kiểm chứng cả tìm kiếm tên lẫn địa chỉ, vì hành vi của bộ phân giải là một đường riêng qua cùng chiếc hộp.

Giữ các quy tắc trong phạm vi những mạng máy khách cần đường hầm, và đừng khuất phục trước cám dỗ tắt bộ lọc chuyển tiếp để một bài kiểm tra đi qua. Thay đổi đó sửa bài kiểm tra và xóa đi ranh giới mà đường hầm lẽ ra phải cung cấp. Viết địa chỉ nguồn, quyết định dịch địa chỉ và tuyến quay về vào một ghi chú, kèm ngày tháng.