Vì sao trang quản trị router ngừng phản hồi sau một thay đổi VPN

Bạn đã đổi một tuyến hoặc một quy tắc tường lửa để thử một đường hầm trên router, và giờ trang quản trị không phản hồi từ chiếc laptop vẫn chạy tốt mười phút trước. Phản xạ đầu tiên là đổ lỗi cho VPN. Phần lớn thời gian đường hầm vẫn khỏe và một trong ba thứ khác đã hỏng: không có tuyến quay lại địa chỉ của chính router, một chính sách vào loại bỏ yêu cầu, hoặc một dịch vụ web không lắng nghe ở địa chỉ bạn đang gọi. Cả ba trông giống nhau trong trình duyệt, nên người ta khởi động lại đường hầm cả tiếng đồng hồ mà không học được gì.

Đây là lầm tưởng nên giết trước tiên: một đường hầm đang chạy không phải là đường quay vào trong. Nó là một kết nối mạng mới với những câu hỏi tin cậy của riêng nó, và nó có thể âm thầm gỡ bỏ đường quản trị cũ trong khi mở một đường mới mà không ai đã xem xét.

Đường hầm chưa bao giờ là đường quản trị

Chuyển tiếp và vào là hai việc khác nhau. "Một máy khách có tới được NAS qua đường hầm không?" là câu hỏi chuyển tiếp về các gói đi qua router. "Tôi có mở được cổng SSH của router không?" là câu hỏi vào về các gói được gửi tới chính router. Một quy tắc cho phép viết cho lưu lượng được chuyển tiếp không làm gì cho câu hỏi thứ hai, và đó là lý do phổ biến nhất khiến một đường hầm chở lưu lượng hoàn hảo vẫn từ chối phiên quản trị của bạn.

Sai lầm ngược lại là tin vào tên giao diện. Đường hầm được mã hóa tới máy ngang hàng, không tới từng dịch vụ phía sau nó, và chữ VPN trên nhãn giao diện không nói gì về nguồn nào nên được phép đăng nhập.

Tầng một: có tuyến tới địa chỉ của chính router không?

Bắt đầu trên máy khách và hỏi nhân xem gói sẽ đi đâu. Trên Linux, ip route get 10.6.0.1 in ra tuyến đã chọn, giao diện ra và địa chỉ nguồn. Nếu nó báo tuyến mặc định về phía nhà cung cấp của bạn, gói không bao giờ vào đường hầm, và không quy tắc nào trên router cứu được.

Phía đường hầm có phiên bản câu hỏi riêng. WireGuard coi AllowedIPs là bảng định tuyến khóa mã hóa: ở mỗi đầu nó khai báo máy ngang hàng được dùng những địa chỉ nguồn nào và những đích nào được gửi tới máy đó. Nếu mục của máy khách không chứa địa chỉ đường hầm của router, máy khách không có tuyến tới đó. Nếu mục của máy chủ cho máy khách đó không bao địa chỉ đường hầm của máy khách, máy chủ loại bỏ gói trước khi xem bất kỳ quy tắc tường lửa nào.

Xác nhận địa chỉ chính xác bạn mong tới trước khi gỡ lỗi chính sách. Một bản ghi DNS cũ hoặc một mục hàng xóm được lưu trong bộ nhớ đệm từ trước thay đổi sẽ đưa bạn tới địa chỉ mà router chưa bao giờ sở hữu.

Tầng hai: chính sách vào, không phải chính sách chuyển tiếp

Tường lửa đánh giá quy tắc trên giao diện nơi gói đến. Trên pfSense và OPNsense, thẻ giao diện và thứ tự quy tắc quyết định lưu lượng tới các dịch vụ của chính tường lửa có được phép hay không; một quy tắc cho máy khách LAN ra internet không phải là quy tắc cho máy ngang hàng của đường hầm mở giao diện web. Trên OpenWrt với firewall4, mỗi vùng mang một chính sách vào, option input 'ACCEPT' hoặc 'REJECT', và một giao diện đường hầm trong vùng có vào là REJECT sẽ từ chối các kết nối quản trị trong khi vẫn chuyển tiếp lưu lượng nếu việc chuyển tiếp được phép.

Đừng tắt quy tắc chống khóa để đường mới hoạt động. Quy tắc đó ngăn một quy tắc tồi khóa địa chỉ quản trị LAN; nó bảo vệ mạng con LAN, không phải mạng con đường hầm bạn vừa tạo. Thêm một quy tắc hẹp cho nguồn của quản trị viên và để lưới an toàn yên. Tài liệu pfSense về truy cập quản trị giải thích các kiểm soát đó ở đâu.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Tầng ba: có gì đang lắng nghe ở địa chỉ đó không?

Một dịch vụ có thể đang chạy mà vẫn không tới được vì nó gắn vào một địa chỉ. uhttpd của OpenWrt giữ các mục lắng nghe rõ ràng trong /etc/config/uhttpd, ví dụ list listen_http '0.0.0.0:80'; một bản dựng chỉ gắn vào địa chỉ LAN không nhận gì ở địa chỉ đường hầm, và các sản phẩm hiển thị thiết lập giao diện lắng nghe cũng hành xử như vậy. Các lệnh lắng nghe ở trên trả lời trực tiếp điều này.

Sau đó tách từ chối khỏi im lặng. nc -vz 10.6.0.1 443 trả về kết nối bị từ chối nghĩa là gói đã tới router và có gì đó từ chối nó, hoặc cổng đóng hoặc một quy tắc từ chối rõ ràng. Treo tới hết thời gian nghĩa là gói bị loại bỏ hoặc chưa bao giờ được định tuyến. Khác biệt đó cho biết nên kiểm tra tầng nào tiếp theo, và nó tốn năm giây.

Giao diện VPN là một ranh giới, không phải đường phục hồi

Mã hóa bảo vệ dây dẫn; nó không nói gì về việc ai được mở trang quản trị. Khi đường hầm chạy, hãy cưỡng lại ý muốn giải quyết khả năng tới được bằng cách cho phép mọi thứ trên giao diện đường hầm. Hãy cho quản trị viên một quy tắc gắn với địa chỉ đường hầm của chính họ hoặc một đường hầm riêng chỉ dành cho quản trị, và giữ người dùng thường, NAS, camera và laptop của gia đình tránh xa cổng quản trị. Một máy ngang hàng cần chia sẻ tệp không nên cách đăng nhập router đúng một quy tắc.

Vai trò của router thay đổi câu trả lời. Router kết thúc đường hầm có thể nhận quản trị viên từ nó một cách chính đáng, trong khi router chỉ dùng đường hầm làm lối ra internet thường không nên. Trong cả hai trường hợp, cho phép mạng con không phải là đăng nhập, nên hãy để xác thực tài khoản và bảo mật vận chuyển bật.

Bước đối phó mà người ta làm sau khi bị khóa tệ hơn: bật quản trị qua WAN hoặc chuyển tiếp một cổng tới giao diện web. Điều đó biến một gián đoạn ngắn thành phơi bày vĩnh viễn, và trang đăng nhập khi đó tiếp cận được với mọi trình quét trên internet. Hãy thử cả phía bị từ chối, không chỉ phía được phép, để một máy ngang hàng không nên có quyền quản trị nhận thời gian chờ hoặc từ chối thay vì lời nhắc đăng nhập.

Cũng hãy thử bằng một kết nối mới. Tường lửa có trạng thái giữ các luồng hiện có trong bảng trạng thái của nó, nên phiên SSH bạn đã mở có thể sống sót qua thay đổi chặn mọi kết nối mới. Đó là cách một khóa tồn tại vô hình cho tới lần khởi động lại tiếp theo hoặc lần ngủ tiếp theo của laptop.

Chuẩn bị đường quay lại trước khi chạm vào chính sách

Viết bốn điều trước thay đổi đầu tiên: bạn sẽ tới thiết bị bằng cách nào nếu đường hầm chết, ví dụ console nối tiếp, console của nhà cung cấp hoặc một máy trong LAN; cấu hình hiện tại được xuất đi đâu; bạn định đổi đúng một quy tắc hoặc tuyến nào; và bạn sẽ hoàn nguyên chính xác mục đó ra sao. Trên OpenWrt, sysupgrade -b /tmp/backup.tar.gz nắm cấu hình, và các chỉnh sửa còn treo cho tới uci commit, điều này cho bạn một lần hoàn tác rẻ nếu để ý kịp. pfSense giữ lịch sử cấu hình, và AutoConfigBackup chỉ giúp nếu nó đã được bật. Nếu router chạy một bộ quy tắc fail-closed, hãy xác nhận đường bảo trì bạn dự kiến không nằm trong lưu lượng mà quy tắc đó chặn, và nhớ rằng khởi động lại áp dụng lại các quy tắc bền vững thay vì xóa chúng.

Đổi một ranh giới mỗi lần thử, rồi thử từ một kết nối mới thay vì từ shell bạn để mở. Nếu lần thử thất bại, hãy hoàn nguyên đúng thay đổi đó trước khi chạm tầng tiếp theo. Đường hầm có thể ở trạng thái lên suốt, nhưng biểu tượng trạng thái xanh của nó không phải bằng chứng rằng bạn vẫn vào được.

Kiểm tra nhanh trước khi đi:

• Bạn có tới được router từ một nguồn không phụ thuộc vào quy tắc bạn vừa sửa không?
• Chính sách vào trên giao diện đường hầm chỉ cho phép nguồn của quản trị viên phải không?
• Dịch vụ quản trị có gắn với một địa chỉ tồn tại trên đường hầm không?
• Bạn đã thử một máy ngang hàng bị từ chối và một phiên mới chưa?
• Bề mặt quản trị qua WAN còn đóng không?