Wake on LAN có thể hoạt động trên kết nối VPN không?


14

Có đúng là chúng tôi không thể cho phép bất kỳ máy nào ngủ mà có thể cần phải truy cập vào kết nối VPN không?

(Tôi đang hỏi điều này về lỗi máy chủ cũng như các máy chủ VPN cũng như về máy tính người dùng cuối đang ngủ)

Câu trả lời:


9

Chủ đề cũ nhưng tôi muốn hòa nhập vì nó vẫn là kết quả tìm kiếm được xếp hạng hàng đầu cho "wol over vpn".

Có, gói ma thuật WOL được xác định trong các ràng buộc của lớp 2 nhưng điều này không có nghĩa là nó không thể được chứa trong một thực thể giao thức mạng và giao thức mà sau đó có thể được sử dụng để định tuyến nó qua VPN. Lý do cho điều này là chuỗi "ma thuật" có thể ở bất cứ đâu trong tải trọng. Vì vậy, về cơ bản, nó trở thành vấn đề nhận được một gói có thể định tuyến thông thường đến máy chủ đích với chuỗi "ma thuật" bên trong trọng tải của nó.

Hầu hết các triển khai gói ma thuật đều sử dụng cổng UDP 9 mặc dù điều này thực sự không quan trọng miễn là nó được định tuyến chính xác và được truyền trên cùng một miền quảng bá với máy tính đích. Miễn là máy khách VPN có các tuyến chính xác, nó có thể gửi gói tin quảng bá như 192.168.1.255 (địa chỉ quảng bá) chính xác đến cổng VPN trên internet.

Vì vậy, việc định tuyến nó thực sự đơn giản, vấn đề có thể nằm ở việc truyền phát chính xác từ cổng VPN đích. Điều này có nghĩa là định cấu hình cổng VPN / tìm tùy chọn, để chuyển tiếp lưu lượng phát từ máy khách VPN từ xa sang mạng cục bộ.


4

Thông thường là không vì "MagicPacket" thực sự ở lớp 2. Nó thậm chí không thể định tuyến được nếu không có sự hỗ trợ của các nhà giao nhận (ví dụ: trình trợ giúp IP).


Tôi đã hy vọng các máy chủ VPN sẽ có một số loại xây dựng trong việc thay thế cho điều này ...
Ian Ringrose

Thông thường, đó không phải là "chuẩn mực" với các máy khách VPN. Từ phiên VPN, bạn có thể thiết lập một hệ thống / thiết bị trung gian để hỗ trợ khởi chạy "MagicPacket" chống lại hệ thống / thiết bị được nhắm mục tiêu.
dùng48838

1

Có một cách thú vị để xây dựng đường hầm Lớp 2 bằng SSH và với WOL này sẽ hoạt động tốt. Vì vậy, tôi thấy không có lý do để làm mà không gửi máy đi ngủ.

Trên cơ sở đề cập đến @slm, tôi đã bao gồm các phần quan trọng của nguồn dưới đây.

Điều kiện tiên quyết:

1) cả hai máy tính phải kích hoạt đăng nhập root. (xin lỗi - thông tin đăng nhập của bạn trên cả hai máy tính phải cho phép bạn tạo thiết bị TAP). Điều này có nghĩa là: ở cấp độ hệ thống, root có mật khẩu;

2) trong tệp sshd_config của máy chủ đang chạy ssh daemon, các tùy chọn PermitTunnel yes và PermitRootLogin yes được đặt;

3) chuyển tiếp ip được kích hoạt trong kernel. Sử dụng lệnh sysctl để đặt tùy chọn này: sysctl -w net.ipv4.ip_forwarding = 1; đồng thời, thêm dòng net.ipv4.ip_forwarding = 1 vào tệp /etc/sysctl.conf của bạn để cài đặt được gắn sau khi bạn khởi động lại. Làm điều này trên cả hai máy tính;

4) Bạn đã cài đặt gói cầu nối, hoặc nếu không có lệnh brctl có sẵn cho bạn, trên cả hai máy tính.

Tạo đường hầm:

ssh -w 1: 1 -o Đường hầm = tên máy chủ ethernet

tùy chọn -w đặt tên của thiết bị TAP trên một trong hai máy chủ (ở đây, tap1 sẽ được tạo ở cả hai đầu).

tùy chọn -o là để chỉ định tùy chọn tệp cấu hình trên dòng lệnh. Chúng tôi sử dụng Đường hầm = ethernet để thiết lập đường hầm lớp 2.

Biểu mẫu này sẽ giữ phiên ssh mở ở phía trước. Nếu bạn muốn nó từ bỏ lớp vỏ sau khi đường hầm được thiết lập, bạn có thể sử dụng tùy chọn -f để bảo nó rẽ vào nền. Tuy nhiên, nó cần một lệnh để rẽ nhánh, vì vậy bạn chỉ cần sử dụng một lệnh giả như true để làm cho nó hoạt động. Bạn cũng có thể sử dụng chức năng này để thiết lập cầu nối ở đầu xa, nhưng hiện tại tôi không tham gia vào đó. Vì vậy, nó sẽ trông như thế này:

ssh -f -w 1: 1 -o Đường hầm = tên máy chủ ethernet đúng

Thêm thiết bị TAP vào một cây cầu:

brctl addbr br0; brctl addif tap1; ifconfig tap1 lên; ifconfig br0 lên

bạn chạy cái này trên cả hai máy chủ (Lưu ý rằng tôi đã không gán IP). brctl là lệnh sử dụng để thao tác các thiết bị cầu. brctl addbr thêm cầu br0 và lệnh addif kết hợp với thiết bị tap1 với nó.

Tiếp theo sẽ là thêm giao diện ethernet vật lý vào thiết bị cầu. Cách bạn muốn làm điều đó sẽ khác nhau, vì vậy tôi sẽ xem xét một vài tình huống. Kịch bản đầu tiên là nơi các đồng nghiệp VPN của bạn nằm trên cùng một mạng con (nghĩa là không có định tuyến giữa chúng) và kịch bản thứ hai sẽ qua Internet.

Bị đánh cắp không biết xấu hổ từ: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-USE-ssh/


Chào mừng bạn đến với Lỗi Máy chủ! Nói chung, chúng tôi thích câu trả lời trên trang web để có thể tự đứng vững - Liên kết rất tuyệt, nhưng nếu liên kết đó bị hỏng, câu trả lời sẽ có đủ thông tin để vẫn hữu ích. Vui lòng xem xét chỉnh sửa câu trả lời của bạn để bao gồm chi tiết hơn. Xem FAQ để biết thêm.
slm

Tôi tìm sshd_config ở đâu trên hệ thống windows 7?
Ian Ringrose

@IanRingrose Tôi không biết vì tôi chỉ làm việc với Linux
Thưa ông,


0

Tôi đồng ý với user48838 - theo định nghĩa, gói ma thuật chỉ được gửi qua mạng con cục bộ. Tuy nhiên, trước đây tôi đã sử dụng một tập lệnh được viết bởi jpo hoạt động từ một mạng con khác thông qua một bộ định tuyến bình thường. Hãy thử điều này - YMMV

http://gsd.di.uminho.pt/jpo/software/wakeonlan/



0

Tôi đã thử nghiệm điều này và câu trả lời là CÓ :)

Tôi tìm thấy một công cụ trên internet gửi gói WOL dưới dạng uni-cast đến máy chủ dự định, qua đó tránh truyền gói tin phát qua vấn đề bộ định tuyến.

Một điểm bạn cần để ý với giải pháp này, bạn cần đặt mục nhập Tĩnh arp trên bộ định tuyến vì máy chủ sẽ tắt và sẽ không đáp ứng yêu cầu ARP của bộ định tuyến. Chúc mừng!


Âm thanh như thế sẽ hoạt động, nó cũng có vẻ như những gói đó sẽ được phát sóng một cách hiệu quả. Mục ARP chỉ dịch từ IP sang MAC. Nó không cho biết công tắc cổng MAC đang bật. Và nếu máy chủ ngoại tuyến, công tắc có thể không biết MAC đó ở đâu, vì vậy nó sẽ được phát sóng. Nhưng ít nhất không ai trong số các máy chủ sẽ gửi thư trả lời, vì vậy nó sẽ ổn.
kasperd

Một số thông tin về cách tìm công cụ bạn sử dụng có thể cải thiện câu trả lời này.
kasperd
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.