სტატიკური OpenVPN IP თითოეული კლიენტისთვის: ifconfig-push, არა ipp.txt

ipp.txt-ში ხაზის რედაქტირება მისამართის დაჯავშნას ჰგავს, მაგრამ ასე არ არის. ეს ფაილი, რომელსაც ifconfig-pool-persist ასახელებს, აღრიცხავს, რა მისამართი ჰქონდა საერთო სახელს ბოლო დროს, რათა აუზმა იგივე დააბრუნოს, როცა ეს მოსახერხებელია. მასში არაფერი აბამს შემდეგ კავშირს ამ ნომერზე.

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

რისთვისაა მუდმივობის ფაილი

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

თუ კონკრეტული კლიენტისთვის კონკრეტული მისამართი გჭირდებათ, დოკუმენტირებული მექანიზმია ifconfig-push და ის ეკუთვნის იმ კონფიგურაციას, რომელიც ფლობს ამ კლიენტს.

შეამოწმეთ, რომ სწორი კლიენტია არჩეული

აშკარა მინიჭება იძებნება კლიენტის საერთო სახელით, ამიტომ არასწორი იდენტობის სახელზე შექმნილი ფაილი არასოდეს იკითხება. დაადასტურეთ, რას მიიჩნევს სერვერი ამ კლიენტის სახელად, განსაკუთრებით იქ, სადაც username-as-common-name მას ავთენტიფიკაციის შემდეგ ცვლის. შემდეგ დაადასტურეთ, რომ ფაილის სახელი ზუსტად ემთხვევა ამ მნიშვნელობას, ასოების დიდი და პატარა ფორმის ჩათვლით.

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

შეამოწმეთ, რომ რიცხვები ტოპოლოგიას ემთხვევა

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

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

შეამოწმეთ შედეგი ახალ კავშირზე

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

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

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