როგორ დავგეგმოთ VPN კლიენტების მისამართების აუზი, რომელიც მოერგება

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

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

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

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

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

წაიკითხეთ მისამართი, რომელიც კლიენტმა რეალურად მიიღო

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

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

მიჰყევით პასუხს უკან სერვისიდან

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

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

ორი კლიენტი, შემდეგ ერთი გაუქმება

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

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

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

ჩაწერეთ ოთხი მნიშვნელობა იქ, სადაც შემდეგი ცვლილება იპოვის მათ

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

შეინახეთ მასთან მფლობელობის შენიშვნა: გვირაბის დიაპაზონი VPN სერვერს ეკუთვნის და LAN-ის DHCP მოცულობაში გაკეთებული დაჯავშნა გვირაბის შიგნით მყოფ კლიენტს არაფერს უჯავშნის. ეს ერთი ხაზი თავიდან იცილებს ყველაზე გავრცელებულ გადაკეთებას, როცა ვიღაც დაჯავშნას ამატებს და ელის, რომ გვირაბის მისამართი მას გაჰყვება.