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

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

სახელი, რომელსაც კლიენტები უკავშირდებიან, ჰოსტის ერთ ველში ცხოვრობს

Pritunl ბოლო წერტილს ამჟღავნებს ჰოსტის საჯარო მისამართის პარამეტრით, რომელიც იღებს საჯარო IP მისამართს ან DNS სახელს. იქ ჩასვით vpn.example.net, და წარმოებული პროფილები და ავთენტიფიცირებული სინქრონიზაცია ამ სახელს კლიენტებს გადასცემს. ჩანაწერი უკვე უნდა არსებობდეს და გადაწყდეს იმ მსმენელზე, რომელიც VPN ტრანსპორტს იღებს; ეს ველი მიმართულების შესახებ აცხადებს, მას არ აქვეყნებს. სერვერის ობიექტის ჩვენებითი სახელი ადმინისტრაციული მეტამონაცემია და არასოდეს აღწევს კლიენტის კავშირის მცდელობამდე.

ამიტომ პირველი ნაბიჯი რაღაცის გადარქმევა არ არის. გახსენით ჰოსტის პარამეტრები, შეცვალეთ საჯარო მისამართი და შეინახეთ მხარდაჭერილი ინტერფეისით.

სამი ველი, რომლებიც მსგავსად გამოიყურება და ასე არ არის

ლოკალური მისამართი ემსახურება რეპლიკაციასა და მარშრუტიზაციას Pritunl ჰოსტებს შორის. კავშირის მისამართი აღწერს, როგორ აღწევენ დაკავშირებული სერვერები ერთმანეთს. არც ერთი მათგანი არ არის ის მისამართი, რომელსაც კლიენტი უკავშირდება, და საჯარო სახელის მათში კოპირება ანგრევს იმ ტოპოლოგიას, რომელსაც ისინი აღწერენ. საჯარო IPv6 მისამართი ცალკე ველია საკუთარი ჩანაწერითა და გზით; A ჩანაწერი IPv4-ისთვის IPv6-ის ხელმისაწვდომობას არ ამყარებს.

DNS სახელი ასევე არ ატარებს პორტის რუკას და არც მსმენელს. თუ სერვისი 1194 UDP-ზე უსმენს, სახელი მაინც გადაწყდება ჰოსტზე, რომელმაც 1194 UDP უნდა მიიღოს. HTTP უკუპროქსი 443 პორტზე, რომელიც ვებ კონსოლს ემსახურება, არ არის VPN ტრანსპორტის ბოლო წერტილი, მაშინაც კი, როცა ორივე ერთსა და იმავე სახელს იზიარებს.

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

გაუგზავნეთ ახალი სახელი არსებულ კლიენტებს

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

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

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

მიიღეთ ცვლილება რეალური კავშირით

გადაწყვეტა ყველაზე სუსტი შესაძლო შემოწმებაა. dig +short vpn.example.net, რომელიც მისამართს აბრუნებს, მხოლოდ იმას ამტკიცებს, რომ ჩანაწერი არსებობს.

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

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