ცარიელი LAN თამაშების სია OpenVPN-ით? შეამოწმეთ აღმოჩენის გზა

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

გამოყავით სესიაში შეერთება მის პოვნისგან

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

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

სცადეთ პირდაპირი შეერთება, სანამ გვირაბს შეეხებით

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

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

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

გაიგეთ, სად ჩერდება broadcast

მარშრუტიზებული TUN გვირაბი IP პაკეტებს გადააქვს თანასწორებს შორის და არ ამრავლებს ლოკალურ broadcast-ს თითოეული თანასწორის ქსელში. შეზღუდული broadcast მისამართი 255.255.255.255 რჩება იმ ინტერფეისის შიგნით, რომელიც მას უშვებს, ხოლო ქვექსელზე მიმართული broadcast ცალკე შემთხვევაა და არა ზოგადი ლიცენზია როუტერებისთვის განცხადებებით დატბორვისა.

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

Multicast აღმოჩენას იგივე პრობლემა აქვს სხვა მისამართების კლასთან და მას სჭირდება multicast მარშრუტიზაცია ან რელე და არა broadcast-ის გამონაკლისი.

როცა რელე გამართლებულია, შეინარჩუნეთ ის ვიწრო

თუ ავტომატური აღმოჩენა მოთხოვნაა, ჯერ გამოავლინეთ ფაქტობრივი გაცვლა: broadcast თუ multicast, დანიშნულების მისამართი, UDP პორტი, ის ინტერფეისი, რომელიც აგზავნის, და პასუხის შიგნით არსებული მისამართი. ამ ხუთ ფაქტზე შემოფარგლული და პროტოკოლის შესაბამისი რელე გაცილებით ვიწროა, ვიდრე მთელი Ethernet სეგმენტის გაფართოება.

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

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

ხიდი მხოლოდ მაშინ, როცა პროექტს Ethernet სჭირდება

Ethernet კადრები TAP-ის შიგნით მოძრაობს, ამიტომ TAP გვირაბი შეიძლება განზრახ ხიდგადაბმულ broadcast დომენს ეკუთვნოდეს. მხოლოდ dev tun-ის dev tap-ით შეცვლა არ აშენებს ამ ხიდს, არ ხდის სერვერის კონფიგურაციას თავსებადს და არ აიძულებს აპლიკაციას აირჩიოს ახალი ინტერფეისი. OpenVPN-ის ხიდგადაბმის სახელმძღვანელო აღწერს უფრო ფართო მოწყობას და არა ერთი ცარიელი ლობის განკურნებას.

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

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