რატომ ერთი და იმავე როუტერის უკან მხოლოდ ერთი VPN კლიენტი უერთდება

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

წაიკითხეთ კარიბჭის ჟურნალი, სანამ კლიენტს შეეხებით

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

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

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

რას აკეთებს როუტერი GRE-სა და NAT-T-თან

PPTP კლასიკური დამნაშავეა: მართვის არხი TCP 1723-ია, ხოლო მონაცემთა გზა GRE, ანუ IP პროტოკოლი 47. ბევრი სამომხმარებლო როუტერი მოყვება PPTP დამხმარეს, რომელიც ერთ მართვის კავშირს ადევნებს, ამიტომ იმავე NAT-ის უკან მეორე კლიენტი თავის მართვის არხს ხსნის და შემდეგ საერთოდ არ იღებს მონაცემთა გზას. 47 ნომრის TCP პორტის გადამისამართება GRE-სთვის არაფერს აკეთებს, რადგან GRE პროტოკოლის ნომერია და არა პორტი.

L2TP IPsec-ზე დიზაინით სხვაგვარად იქცევა: IKE იყენებს UDP 500-ს, NAT-ის გავლა დაცულ დატვირთვას UDP 4500-ზე გადააქვს, და ინკაფსულაცია სწორედ იმისთვის არსებობს, რომ ერთი მისამართის უკან რამდენიმე კლიენტმა ერთსა და იმავე კარიბჭეს მიაღწიოს. ეს დიზაინი ხელს არ უშლის კარიბჭეს ან შუალედურ ყუთს თითო მისამართზე სესიების ზღვარი დააწესოს, და დივანიდან ორივე წარუმატებლობა ერთნაირად გამოიყურება. SoftEther-ის საკუთარ პროტოკოლს იგივე კლასის პრობლემა აქვს: მომუშავე გატარების გარეშე როუტერი ლოკალური ქსელიდან პირველ კლიენტს შეუშვებს და მეორეს ჩამოაგდებს. გამოსცადეთ როუტერის ALG ან გატარების ჩამრთველი ორივე მდგომარეობაში, რადგან ძველი კლიენტისთვის დაწერილმა დამხმარემ შეიძლება დააზიანოს ის პაკეტები, რომლებსაც დღევანდელი აგზავნის.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

იდენტობის ზღვრები, რომლებიც ტრანსპორტის ზღვრებს ჰგავს

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

შეუსაბამეთ შეკეთება ჟურნალის ჩანაწერს

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

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

ორი ცოცხალი სესიის შემოწმება

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

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