Wake-on-LAN qua VPN không hoạt động? Gói quảng bá không bao giờ đi qua

Bạn cho máy ở văn phòng ngủ, quay số VPN từ nhà, và nó vẫn tắt. Đường hầm đã lên, thư mục chia sẻ phản hồi, và trang wake-on-LAN của router báo rằng đã gửi yêu cầu. Mọi dấu hiệu nhìn thấy đều nói mạng ổn, và chính vì thế trường hợp này gây bối rối: khung sẽ đánh thức máy không bao giờ tới được phân đoạn nơi nó nằm.

Triệu chứng chỉ vào mạng con, không phải đường hầm

Ping tới máy chủ đang ngủ thất bại, và phần đó là bình thường. Máy ở trạng thái chờ không có ngăn xếp IP đang chạy, nên không thể trả lời ARP hay ICMP, và không cấu hình đường hầm nào thay đổi điều đó. Phép thử hữu ích là một máy thứ hai trong cùng LAN có thức dậy không, và trang đánh thức của chính router có hoạt động với máy chủ cắm vào nó không.

Khi phép thử trong cùng phân đoạn đạt, lỗi nằm ở phạm vi. Bộ gửi bạn đang dùng sống trên giao diện VPN, và gói nó dựng là quảng bá cho liên kết cục bộ, nên nó đi ra giao diện sai hoặc không đi đâu cả. Đường hầm không hỏng; nó đang chở sai loại lưu lượng. Hãy tìm xem bộ gửi chọn giao diện nào trước khi đổi dù chỉ một thiết lập của router.

Magic packet là một khung, không phải dịch vụ

Phần tải bắt đầu bằng tiêu đề cố định sáu byte 0xFF, rồi địa chỉ phần cứng của card đích lặp lại mười sáu lần, rồi mật khẩu SecureOn tùy chọn bốn byte. Bộ gửi thường bọc nó trong UDP tới cổng 7 hoặc cổng 9, nhưng số cổng là quy ước giữa bộ gửi và card, không phải trình lắng nghe có thể kết nối vào. Không có gì lắng nghe, và không có gì trả lời.

Thứ đánh thức máy là giao diện mạng, vốn giữ một phần nhỏ mạch được cấp điện từ ray chờ trong khi phần còn lại của hệ thống tắt. Vì vậy thiết lập phải sống sót qua cả mất điện hoàn toàn và giấc ngủ: bo mạch cắt điện chờ khi tắt sẽ không còn card nào để nhận bất cứ thứ gì.

Vì sao đường hầm định tuyến không thể chuyển nó

Giao diện VPN định tuyến là một liên kết IP điểm-điểm giữa hai địa chỉ đường hầm. Nó tồn tại để chở các gói gửi tới đối tác, nên ping, SSH và chia sẻ tệp hoạt động bình thường qua nó. Khung quảng bá không gửi tới đối tác đó, và địa chỉ quảng bá giới hạn không bao giờ được router chuyển tiếp một cách mặc nhiên.

Chuyển tiếp quảng bá hướng tới mạng con là khả năng có chủ đích của router mà hầu hết cấu hình mặc định tắt đi, và ngay cả khi bật nó cũng chỉ giao tới mạng con đó chứ không tới một card đang ngủ cụ thể. Máy chủ đang ngủ cũng không trả lời ARP, nên router muốn phân giải địa chỉ đích trước khi chuyển tiếp sẽ bỏ khung trong lúc chờ một câu trả lời không bao giờ tới. Một mục liên kết tĩnh sửa phần đó và để nguyên vấn đề phạm vi quảng bá. Vậy là hai hạn chế riêng biệt, và gỡ một cái không giúp gì cho cái kia.

Ba vị trí thực sự tới được card

Mọi cách bố trí khả thi đều đặt khung vào phân đoạn của mục tiêu, và chúng khác nhau ở mức độ quấy rầy mạng:

1. Đặt một thiết bị luôn bật trong phân đoạn đích. Router, NAS hoặc hộp Linux nhỏ còn được cấp điện có thể phát khung tại chỗ ngay khi bạn tới được nó qua đường hầm, và không gì trong VPN thay đổi.
2. Để router tự phát khung. Nhiều firmware có trang đánh thức gửi từ cầu LAN, cách này chạy miễn là mục tiêu nằm trên cầu đó chứ không nằm sau router thứ hai.
3. Bắc cầu hai site bằng đường hầm kiểu TAP khi quảng bá thực sự phải đi qua. Cách này gộp hai miền quảng bá, kéo theo bão quảng bá, một kế hoạch địa chỉ duy nhất và mọi giao thức khám phá nhìn thấy cả hai site cùng lúc.

Lựa chọn đầu là thứ nên ưu tiên cho một máy. Lựa chọn thứ ba là quyết định thiết kế mạng có chi phí thường trực, nên hãy coi nó như vậy chứ không phải bản vá nhanh cho một máy để bàn.

Ghi lại trợ giúp nào phát khung và nó nằm trên cầu hay VLAN nào. Một trợ giúp phát ra từ giao diện sai cho bản bắt gói hoàn hảo và một máy không bao giờ thức, và tổ hợp đó tốn cả một buổi chiều.

Kiểm chứng việc gửi trước khi đổ lỗi cho máy khách

Hãy kiểm tra card đích trước, vì không bộ gửi nào đánh thức được card chưa được trang bị. Lệnh dưới đây đọc các chế độ đánh thức được hỗ trợ và hiện hành, trong đó giá trị hiện hành g nghĩa là magic packet đang bật:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

Chạy bản bắt gói trên trợ giúp trong lúc gửi, và đọc nó thay vì cho rằng đã thành công. Một khung rời đúng cầu với MAC đích quảng bá là bằng chứng duy nhất rằng việc gửi đã chạy; nếu bản bắt trống thì bộ gửi đã chọn giao diện khác và phần còn lại của phép thử vô nghĩa. Bộ gửi dựng khung thô thay vì datagram UDP sẽ không khớp bộ lọc đó, nên hãy xem công cụ của bạn dùng dạng nào trước khi kết luận là chưa gửi gì.

Trên Windows, phép kiểm tra card tương đương là powercfg /devicequery wake_armed, liệt kê các thiết bị được phép đánh thức hệ thống. Một card mạng vắng mặt trong danh sách đó sẽ bỏ qua mọi gói gửi tới nó, dù khung trông đúng đến đâu trên dây.

Sau đó xác nhận chính việc thức dậy và phần tiếp theo. Máy bật lên nhưng vẫn không tới được bằng tên cần địa chỉ tĩnh và bản ghi DNS, vì phân giải tên bằng quảng bá vẫn không qua được đường hầm. Đánh thức không dây là khả năng riêng và kém tin cậy hơn nhiều so với bản có dây, nên hãy thử nó trong cùng phân đoạn trước khi kéo VPN vào. Ghi tên giao diện và máy chủ của trợ giúp vào phiếu, vì sự cố tiếp theo thường liên quan đúng hai dữ kiện đó.