OPNsense-ის უკან OpenVPN კლიენტების სტატიკური მისამართები
pool ფაილი მისამართს წებოვანს ხდის, არა მუდმივს. დაამაგრეთ კლიენტების მისამართები override-ებით, გააფართოეთ გვირაბის დიაპაზონი /30-ის არითმეტიკისთვის, შემდეგ გამოაქვეყნეთ ისინი.
სახელებს სჭირდებათ მისამართები, რომლებიც არ მოძრაობენ, და OpenVPN-ის pool ფაილი მისამართს მხოლოდ წებოვანს ხდის. დაკარგეთ ეს ფაილი, ან ხელახლა გამოსცეთ სერტიფიკატი სხვა საერთო სახელით, და დაბრუნებული კლიენტი pool-ში სხვაგან ხვდება, მაშინ როცა მისი DNS ჩანაწერი ჯერ კიდევ ძველ მისამართზე მიუთითებს. გამძლე პასუხია კლიენტისთვის სპეციფიკური override, რომელიც ამაგრებს მისამართს, პლუს უფრო ფართო გვირაბის ქსელი, რათა დამაგრებული მისამართები დინამიკური დიაპაზონის გარეთ იყოს. ამ გაფართოების მიღმა მდგარი არითმეტიკაა ის ადგილი, სადაც დაბნეულობის უმეტესობა ცხოვრობს.
OPNsense ინახავს ამ override-ებს სერვერის კლიენტისთვის სპეციფიკურ პარამეტრებში, გასაღებად სერტიფიკატის საერთო სახელი, რაც საერთო სახელს მისამართების გეგმის ნაწილად აქცევს.
წებოვანი იჯარა სტატიკური მისამართი არ არის
pool ფაილი წერს მისამართ-კლიენტის შესაბამისობებს და აბრუნებს მათ, როცა ცნობილი კლიენტი ხელახლა უკავშირდება. ეს მოხერხებულობაა და არა ხელშეკრულება: ფაილი შეიძლება ხელახლა შეიქმნას, შესაბამისობა ქრება, როცა კლიენტის იდენტობა იცვლება, და ერთ pool-ს გამზიარებელი ორი სერვერი მასზე არ შეთანხმდება. კლიენტისთვის სპეციფიკური override სხვაგვარად მუშაობს, რადგან მისამართი კონფიგურაციიდან მოდის და არა ისტორიიდან. ის ასევე უძლებს მოწყობილობის გადატვირთვას და ხელახლა დაყენებას, იმ პირობით, რომ override დარეზერვებულია დანარჩენ კონფიგურაციასთან ერთად.
დინამიკური ალტერნატივა, ანუ VPN-ის DNS-თან დაკავშირება client-connect სკრიპტით და დინამიკური განახლებებით, მუშაობს და მოითხოვს resolver-ს, რომელიც განახლებებს იღებს, პლუს სკრიპტი ყოველ კავშირზე. მოწყობილობაზე შეზღუდული ხართ მომწოდებლის მიერ მოწოდებული პაკეტებით, და ჩვეულებრივ სწორედ იქ ჩერდება ეს გეგმა.
ის /30 არითმეტიკა, რომლითაც არავინ ტკბება
ნაგულისხმევ net30 ტოპოლოგიაში ყოველი კლიენტი თავის /30-ს იღებს: პირველი გამოსაყენებელი მისამართი სერვერის მხარეს მიდის, მეორე კლიენტს. ამიტომ override-ები სერვერის დინამიკური გვირაბის ქსელის გარეთ უნდა იყოს, რაც ნიშნავს, რომ ჯერ ეს ქსელი უნდა გავაფართოვოთ. სერვერს 10.8.0.0/24-ზე შეუძლია გადავიდეს 10.8.0.0/23-ზე, ძველი დიაპაზონის ნახევარი დინამიკურ კლიენტებს დაუტოვოს, ხოლო მეორე ნახევარი override-ებს. დაამატეთ საწყისი /24 დამატებით IPv4 ლოკალურ ქსელად, რათა ორივე ნახევრის ტრაფიკი გვირაბში მარშრუტირდეს.
ყოველი override მისამართი /30-ის საზღვარზე უნდა მოხვდეს, ამიტომ ბოლო ოქტეტი ოთხის ჯერადია. /30 10.8.1.0-ზე კლიენტს აძლევს 10.8.1.2-ს, და სწორედ ამ მისამართს ატარებს DNS ჩანაწერი. 10.8.1.3-ის არჩევა ამის ნაცვლად ქმნის კლიენტს, რომელიც უკავშირდება და ვერ ატარებს ტრაფიკს, რადგან მისამართი ეკუთვნის ქვექსელს, რომელიც ტოპოლოგიამ მას არასოდეს მიუნიჭებია.
გეგმის დაცვა უფრო ადვილია, თუ override-ები ნაწილდება გაფართოებული დიაპაზონის ზემოდან ქვემოთ, რათა დინამიკური pool გაიზარდოს თავისუფალ სივრცეში და არა ფიქსირებული კუნძულების გარშემო.
ლოკალური ქსელები და ზონა, რომელსაც კლიენტები იკითხავენ
კლიენტიდან კლიენტამდე ტრაფიკს საკუთარი ნებართვა სჭირდება. სერვერის IPv4 ლოკალური ქსელების სია უნდა მოიცავდეს დიაპაზონის ორივე ნახევარს, დინამიკურს და სტატიკურს; ამის გარეშე სერვერი ერთი კლიენტისგან პაკეტს იღებს და არ აქვს პოლიტიკა, რომელიც მის სხვასთან გატარებას უშვებს. სიმპტომი DNS-ის მარცხს ჰგავს, რადგან სახელი წყდება და კავშირი მაინც იშლება. ამავე დროს შეამოწმეთ კლიენტიდან კლიენტამდე პარამეტრი, რადგან მხოლოდ ლოკალური ქსელის ჩანაწერი თანასწორებს შორის გადაცემას არ რთავს.
გამოაქვეყნეთ ჩანაწერები იმ ზონაში, რომელსაც დისტანციური კლიენტები რეალურად იკითხავენ. ჩანაწერი ზონაში, რომელსაც მხოლოდ LAN-ის resolver ემსახურება, უხილავია იმ კლიენტისთვის, რომლის გაგზავნილი resolver სხვაგან მიუთითებს, და არასწორ ზონაში მეტი ჩანაწერის დამატება ამას არასოდეს ასწორებს. სანამ რამეს დაამატებთ, დაადასტურეთ გაგზავნილი DNS ოფცია და საძიებო დომენი.
რა უნდა შემოწმდეს ახალ კავშირზე
ხელახლა დაუკავშირეთ კლიენტი და დაადასტურეთ, რომ მინიჭებული მისამართი ემთხვევა მის override-ს, სანამ სხვა რამეს გამოსცდით. შემდეგ წყვეტეთ სახელი მეორე კლიენტიდან და დაუკავშირდით სერვისს სახელით, რაც ერთად ამოწმებს DNS ჩანაწერს, მარშრუტს და firewall-ს. დაადასტურეთ პასუხის გზა სერვერის მხარეს, რადგან სახელი, რომელიც იხსნება, სანამ სერვისი მიუწვდომელი რჩება, მარშრუტიზაციის ან პოლიტიკის პრობლემაა და არა სახელდების. შეინახეთ override-ების ცხრილი სერტიფიკატების სიის გვერდით, რათა ორივე ერთად გადაიხედოს.
სხვა საერთო სახელით ხელახლა გამოცემული სერტიფიკატი წყვეტს თავის override-სთან შესაბამისობას და კლიენტს დინამიკურ pool-ში აბრუნებს. ელოდეთ ამას ნებისმიერი იდენტობის ცვლილების შემდეგ.