Wake-on-LAN VPN-ის გავლით არ მუშაობს? გადაცემა არასდროს გადის

ოფისის მანქანას აძინებთ, სახლიდან VPN-ს უკავშირდებით და ის გამორთული რჩება. გვირაბი აწეულია, ფაილების გაზიარებები პასუხობს, ხოლო მარშრუტიზატორის wake-on-LAN გვერდი იტყობინება, რომ მოთხოვნა გაგზავნა. ყველა ხილვადი სიგნალი ამბობს, რომ ქსელი რიგზეა, და სწორედ ამიტომ არის ეს შემთხვევა დამაბნეველი: კადრი, რომელიც მანქანას გააღვიძებდა, ვერასდროს აღწევს იმ სეგმენტამდე, სადაც ის არის.

სიმპტომები ქვექსელზე მიუთითებს და არა გვირაბზე

Ping მძინარე ჰოსტამდე არ გადის და ეს ნაწილი ნორმალურია. მოლოდინის რეჟიმში მყოფ მანქანას მუშა IP სტეკი არ აქვს, ამიტომ ARP-ს ან ICMP-ს ვერ უპასუხებს, და ვერცერთი გვირაბის კონფიგურაცია ვერ შეცვლის ამას. სასარგებლო შემოწმებაა, გაიღვიძებს თუ არა მეორე მანქანა იმავე LAN-ში და მუშაობს თუ არა თავად მარშრუტიზატორის გაღვიძების გვერდი მასზე მიერთებული ჰოსტისთვის.

როგორც კი იმავე სეგმენტში შემოწმება გაივლის, ხარვეზი მოცულობაშია. თქვენ მიერ გამოყენებული გამომგზავნი ცხოვრობს VPN-ის ინტერფეისზე, და ის პაკეტი, რომელსაც ის აშენებს, ლოკალური ბმისთვის გადაცემაა, ამიტომ ის არასწორი ინტერფეისიდან გადის ან საერთოდ არ გადის. გვირაბი არ არის გატეხილი; ის არასწორი ტიპის ტრაფიკს გადააქვს. გაარკვიეთ, რომელ ინტერფეისს ირჩევს გამომგზავნი, სანამ ერთ მარშრუტიზატორის პარამეტრსაც კი შეცვლით.

Magic packet კადრია და არა სერვისი

ტვირთი იწყება ექვსბაიტიანი ფიქსირებული სათაურით, 0xFF, შემდეგ სამიზნე ბარათის ტექნიკური მისამართი თექვსმეტჯერ მეორდება, შემდეგ მოდის არასავალდებულო ოთხბაიტიანი SecureOn პაროლი. გამომგზავნები ჩვეულებრივ ამას UDP-ში ახვევენ და 7 ან 9 პორტზე აგზავნიან, მაგრამ პორტის ნომერი გამომგზავნსა და ბარათს შორის შეთანხმებაა და არა მოსმენადი სერვისი, რომელზეც შეიძლება დაკავშირება. არაფერი ისმენს და არაფერი პასუხობს.

მანქანას აღვიძებს ქსელის ინტერფეისი, რომელიც მცირე ნაწილს სქემებისა კვებავს მოლოდინის ავტობუსიდან, სანამ სისტემის დანარჩენი ნაწილი გამორთულია. ამიტომ პარამეტრმა უნდა გადაიტანოს როგორც სრული ენერგიის დაკარგვა, ისე ძილი: დედაპლატა, რომელიც გამორთვისას წყვეტს მოლოდინის კვებას, აღარ ფლობს ბარათს, რომელიც რაიმეს მიიღებდა.

რატომ ვერ აწვდის ამას მარშრუტიზებული გვირაბი

მარშრუტიზებული VPN-ის ინტერფეისი წერტილიდან წერტილამდე IP კავშირია ორ გვირაბის მისამართს შორის. ის არსებობს იმისთვის, რომ გადაიტანოს პარტნიორისთვის მისამართებული პაკეტები, და ამიტომ ping, SSH და ფაილების გაზიარებები მის გავლით ნორმალურად იქცევა. გადაცემის კადრი ამ პარტნიორისთვის არ არის მისამართებული, და შეზღუდული გადაცემის მისამართი მარშრუტიზატორის მიერ არასდროს გადაეცემა უბრალოდ ასე.

ქვექსელზე მიმართული გადაცემის გატარება არის მარშრუტიზატორის განზრახ შესაძლებლობა, რომელსაც უმეტესი ნაგულისხმევი კონფიგურაცია თიშავს, და მაშინაც კი ის ამ ქვექსელს აწვდის და არა კონკრეტულ მძინარე ბარათს. მძინარე ჰოსტს ARP-ზე პასუხიც არ შეუძლია, ამიტომ მარშრუტიზატორი, რომელიც გადაცემამდე ცდილობს სამიზნე მისამართის ამოხსნას, კადრს ყრის, სანამ დაელოდება პასუხს, რომელიც არასდროს მოვა. სტატიკური მიბმის ჩანაწერი ასწორებს ამ ნაწილს და გადაცემის მოცულობის პრობლემას ხელუხლებლად ტოვებს. ასე რომ, ორი ცალკე შეზღუდვა, და ერთის მოხსნა მეორისთვის არაფერს აკეთებს.

სამი განლაგება, რომლებიც ნამდვილად აღწევს ბარათამდე

ნებისმიერი სამუშაო განლაგება კადრს მიზნის სეგმენტზე ათავსებს, და ისინი იმით განსხვავდებიან, რამდენად აშფოთებენ ქსელს:

1. მიზნობრივ სეგმენტზე დადგით მოწყობილობა, რომელიც ყოველთვის ჩართულია. მარშრუტიზატორი, NAS ან პატარა Linux-ის ყუთი, რომელიც კვებაზე რჩება, შეუძლია კადრი ლოკალურად გაგზავნოს, როგორც კი გვირაბით მას მიაღწევთ, და VPN-ში არაფერი იცვლება.
2. მიეცით მარშრუტიზატორს თავად გაგზავნოს კადრი. ბევრი firmware გვთავაზობს გაღვიძების გვერდს, რომელიც LAN ხიდიდან აგზავნის, და ეს მუშაობს მანამ, სანამ მიზანი ამ ხიდზე ზის და არა მეორე მარშრუტიზატორის უკან.
3. დააკავშირეთ ობიექტები ხიდით TAP ტიპის გვირაბით, როცა გადაცემებმა ნამდვილად უნდა გადაიაროს. ეს ორ გადაცემის დომენს აერთიანებს, თან მოაქვს გადაცემის ქარიშხლები, ერთიანი მისამართების გეგმა და ყოველი აღმოჩენის პროტოკოლი, რომელიც ორივე ობიექტს ერთდროულად ხედავს.

პირველი ვარიანტია ის, რომელიც ერთი მანქანისთვის უნდა ავირჩიოთ. მესამე ქსელის დიზაინის გადაწყვეტილებაა მუდმივი ხარჯით, ამიტომ მას ისე მოეპყარით და არა როგორც სწრაფ შესწორებას ერთი სამუშაო მაგიდისთვის.

ჩაწერეთ, რომელი დამხმარე აგზავნის კადრს და რომელ ხიდზე ან VLAN-ში ზის. არასწორ ინტერფეისზე გამგზავნი დამხმარე იძლევა სრულყოფილ ჩანაწერს და მანქანას, რომელიც არასდროს იღვიძებს, და ეს კომბინაცია შუადღეს ხარჯავს.

შეამოწმეთ გაგზავნა, სანამ კლიენტს დაადანაშაულებთ

ჯერ სამიზნე ბარათი შეამოწმეთ, რადგან ვერცერთი გამომგზავნი ვერ გააღვიძებს ბარათს, რომელიც მზად არ არის. ქვემოთ მოცემული ბრძანება კითხულობს მხარდაჭერილ და მიმდინარე გაღვიძების რეჟიმებს, სადაც მიმდინარე g მნიშვნელობა ნიშნავს, რომ magic packet ჩართულია:

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

გაგზავნის დროს გაუშვით ჩანაწერი დამხმარეზე და წაიკითხეთ ის, ნაცვლად იმისა რომ წარმატება ჩათვალოთ. კადრი, რომელიც სწორ ხიდს ტოვებს გადაცემის სამიზნე MAC-ით, ერთადერთი მტკიცებულებაა, რომ გაგზავნა მუშაობდა; თუ ჩანაწერი ცარიელია, გამომგზავნმა სხვა ინტერფეისი აირჩია და ტესტის დანარჩენი ნაწილი უაზროა. გამომგზავნი, რომელიც ნედლ კადრს აშენებს UDP დატაგრამის ნაცვლად, არ ერგება ამ ფილტრს, ამიტომ შეამოწმეთ, რომელ ფორმას იყენებს თქვენი ხელსაწყო, სანამ დაასკვნით, რომ არაფერი გაგზავნილა.

Windows-ში ბარათის ექვივალენტური შემოწმებაა powercfg /devicequery wake_armed, რომელიც ჩამოთვლის მოწყობილობებს, რომლებსაც სისტემის გაღვიძების ნება აქვთ. ქსელის ადაპტერი, რომელიც ამ სიაში არ არის, უგულებელყოფს მასზე გაგზავნილ ყოველ პაკეტს, რამდენად სწორადაც არ უნდა გამოიყურებოდეს კადრი სადენზე.

შემდეგ დაადასტურეთ თავად გაღვიძება და გაგრძელება. მანქანას, რომელიც ირთვება, მაგრამ სახელით მიუწვდომელი რჩება, სჭირდება სტატიკური მისამართი და DNS ჩანაწერი, რადგან სახელების ამოხსნა გადაცემით ჯერ კიდევ არ გადის გვირაბს. უსადენო გაღვიძება ცალკე და გაცილებით ნაკლებად საიმედო შესაძლებლობაა, ვიდრე სადენიანი ვერსია, ამიტომ გამოსცადეთ ის იმავე სეგმენტში, სანამ საერთოდ ჩართავთ VPN-ს. ჩაწერეთ ბილეთში ინტერფეისის სახელი და დამხმარის ჰოსტი, რადგან შემდეგი ხარვეზი ჩვეულებრივ იგივე ორ ფაქტს ეხება.