Đánh thức PC ở nhà đang ngủ qua VPN: gói tin đến từ đâu

Bạn kết nối, router trả lời và máy để bàn vẫn tối. Đường hầm không sao; gói tin lẽ ra đã đánh thức máy thì chưa bao giờ tới được phân đoạn nơi máy lắng nghe. Đi ngược đường từ router sẽ thấy nó chết ở đâu.

Ba thiết bị có ba nhiệm vụ. Trộn lẫn chúng là lý do thường gặp khiến một lần đánh thức quay vòng mãi mãi.

Bắt đầu từ máy khách từ xa và đi theo đường đi

Từ mạng khách sạn, bạn kết nối tới router ở nhà, điểm cuối duy nhất luôn hoạt động trong bức tranh này. Một yêu cầu đánh thức gõ trên laptop trở thành lưu lượng đường hầm bình thường, gửi tới bất kỳ đích nào bạn đã nêu. Chính đích đó quyết định mọi thứ tiếp theo.

Nếu bạn gửi nó tới địa chỉ LAN của router ở nhà trên cổng magic packet, router có thể nhận datagram và không bao giờ phát ra một khung trên phân đoạn của nhà, vì ở đó không có gì lắng nghe cổng đó. Nếu bạn quảng bá nó bên trong đường hầm, nó dừng ở giao diện đường hầm. Một đường hầm có định tuyến không phải là phần mở rộng lớp 2 của hệ thống dây trong nhà. Đi theo đường từng chặng một và ngõ cụt trở nên rõ ràng.

Phép kiểm tra quyết định điều này cần một lệnh từ phía xa và một lệnh từ phía nhà. Gửi yêu cầu, rồi quan sát phân đoạn của nhà để tìm khung.

Chuyển bên gửi vào phân đoạn của nhà

Router có thể tự đánh thức khi bạn đã xác thực qua đường hầm. OpenWrt tài liệu hóa một dịch vụ Wake-on-LAN chạy trên thiết bị và phát khung tại chỗ, và đó chính xác là hình dạng cần có: xác thực từ xa ở ngoài, quảng bá cục bộ ở trong.

Cách bố trí đó cũng giữ chức năng đánh thức tránh xa internet công cộng. Không có gì mới bị lộ ra internet, vì bộ kích hoạt đi qua VPN mà bạn đã tin cậy. Lựa chọn thay thế, một dịch vụ đánh thức có chuyển tiếp cổng, đổi chút tiện lợi lấy một điểm cuối hướng ra internet mà bất kỳ ai cũng có thể dò.

Sự phụ thuộc vòng tròn đáng được gọi tên thẳng thắn. Một máy khách VPN cài trên máy để bàn không thể đánh thức chính máy đó, vì tiến trình máy khách cần máy đang chạy. Giữ điểm vào từ xa trên router hoặc một hộp luôn hoạt động khác, và để máy để bàn chỉ là mục tiêu.

Xác nhận mục tiêu trước khi đổ lỗi cho đường hầm

Phần này do phần cứng quyết định, không phải VPN, và trạng thái nguồn quyết định trước. Bộ điều hợp phải hỗ trợ đánh thức, firmware phải để bộ điều hợp có nguồn khi ngủ, và hệ điều hành phải được cấu hình để cho phép điều đó. Máy bị tạm treo là trường hợp khác với máy đã tắt, và cả hai đều khác với máy bị cắt nguồn ở tường. Làm rõ trạng thái đó trước khi đi qua phần còn lại của danh sách.

Đọc địa chỉ phần cứng từ bộ điều hợp thực sự sẽ nhận khung. Máy để bàn có cả Ethernet và Wi-Fi thường có hai địa chỉ, và chỉ một trong số đó có thể đánh thức được. Đánh thức không dây là một khả năng riêng với yêu cầu firmware riêng, nên đánh thức qua Ethernet chạy được không nói gì về đánh thức qua Wi-Fi.

Trước hết hãy chứng minh đường đi cục bộ. Gửi magic packet từ một thiết bị khác trên cùng switch và xem máy khởi động. Nếu việc đó thất bại, mọi nỗ lực gỡ lỗi đường hầm đều vô ích, và lỗi nằm ở firmware, cài đặt bộ điều hợp hoặc trạng thái nguồn.

Sau khi thức dậy, kết nối tới dịch vụ bạn muốn

Đánh thức không phải là truy cập từ xa. Khi máy tiếp tục chạy, nó vẫn phải khởi động các dịch vụ của mình, lấy địa chỉ và chấp nhận phiên mà bạn thực sự cần. Hãy cho nó thời gian đạt tới trạng thái đó trước khi kết luận rằng việc đánh thức đã thất bại.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

Dòng arp là dòng hữu ích. Một mục chuyển từ chưa đầy đủ sang địa chỉ phần cứng thật nghĩa là máy đã tiếp tục và trả lời; một yêu cầu không bao giờ được giải quyết sẽ chỉ ngược về bước đánh thức, chứ không phải dịch vụ mà bạn đang cố với tới.

Tách các giai đoạn trong ghi chú của bạn: đánh thức, khởi động, dịch vụ. Một lỗi ở giai đoạn hai trông giống hệt lỗi ở giai đoạn một từ cửa sổ trò chuyện, và chỉ bằng chứng cục bộ mới phân biệt được chúng.