OpenVPN-ის ძრავა თუ Tunnelblick: ვის ეკუთვნის Mac-ის VPN სესია?

Homebrew აყენებს OpenVPN-ის პროგრამას; Tunnelblick აყენებს მენეჯერს, რომელიც ერთ ან რამდენიმე ძრავას უშვებს. ეს სხვადასხვა ფენაა და სასარგებლო კითხვა არ არის, მოგწონთ თუ არა ტერმინალის გამოყენება. კითხვა ისაა, ვის ეკუთვნის კონფიგურაცია, DNS-ის ცვლილებები, სერტიფიკატების მოთხოვნა და წმენდა სესიის დასრულებისას. ამ ფენების ერთი მფლობელი ხდის კონფიგურაციას პროგნოზირებადს.

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

შემოწმება პირველი: რომელი OpenVPN-ის ბინარული ფაილი მუშაობს რეალურად

დაკავშირებულ მდგომარეობაში გაუშვით pgrep -fl openvpn და წაიკითხეთ მთელი ბრძანების სტრიქონი. პირველი გზა არის ძრავა, რომელიც რეალურად მუშაობს. Apple Silicon-ზე Homebrew-ის ინსტალაცია ჩვეულებრივ /opt/homebrew-ის ქვეშაა, Intel Mac-ები კი /usr/local-ს იყენებენ, და Tunnelblick ძრავას საკუთარი აპლიკაციის პაკეტის შიგნიდან უშვებს.

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

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

შემოწმება მეორე: ვინ ცვლის DNS-სა და მარშრუტებს

ძრავას შეუძლია OpenVPN-ის საკუთარი up და down დირექტივების გაშვება, მაგრამ მენეჯერს შეიძლება იგივე სასიცოცხლო ციკლი ეკუთვნოდეს. Tunnelblick-ის სახელების სერვერის პარამეტრები მართავს მის სტანდარტულ დაკავშირებისა და გათიშვის სკრიპტებს, და როცა ეს ინტეგრაცია ჩართულია, პროფილში კონკურენტული დირექტივები შეიძლება უგულებელყოფილ იქნას.

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

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

შემოწმება მესამე: საიდან მოდის სერტიფიკატები

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

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

შემოწმება მეოთხე: ვინ იწყებს, აკონტროლებს და აჩერებს პროცესს

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

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

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

შემოწმება მეხუთე: როგორ მოწმდება გადაცემა

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

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

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

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