OpenVPN TAP macOS-ზე: გამართვამდე შეამოწმეთ კლიენტი

ძველი პროფილი თანამედროვე Mac-ზე მოხვდება, კლიენტი მას უჩივლებლად იმპორტავს, და კავშირი წყდება ან ტრაფიკი საერთოდ არ გადის. სერტიფიკატებზე მთელი შუადღის დახარჯვამდე წაიკითხეთ მოწყობილობის სტრიქონი პროფილში. თუ იქ dev tap წერია, თქვენ კლიენტს Ethernet-ის ტიპის ინტერფეისს სთხოვთ, და macOS-ზე ასეთი სესიების უმეტესობა სწორედ ამ მოთხოვნაზე მთავრდება.

ნაბიჯი 1: დაადასტურეთ, რომ პროფილი ნამდვილად ითხოვს TAP-ს

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

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

თუ ფაილი შეიცავს dev tap ან dev tap0, კლიენტმა უნდა განახორციელოს TAP ინტერფეისი. თუ შეიცავს dev tun, ამ სტატიის დარჩენილი ნაწილი არ ვრცელდება და ხარვეზი სხვაგანაა.

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

ნაბიჯი 2: იცოდეთ, რას ცვლის სინამდვილეში მოწყობილობის რეჟიმი

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

TAP ინტერფეისი Ethernet კადრებს გადასცემს, მათ შორის broadcast-სა და ARP-ს. სწორედ ეს აძლევს ხიდიან სერვერს საშუალებას DHCP-ით გაანაწილოს მისამართები, ხოლო კლიენტს — ხმამაღალი ძახილით აღმოაჩინოს მოწყობილობები, და ამიტომ ზოგიერთი ძველი დიზაინი ამაზეა დამოკიდებული.

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

ნაბიჯი 3: აირჩიეთ თავსებად კლიენტსა და მიგრაციას შორის

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

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

რაც არ მუშაობს, არის ლოკალურ ასლში tap-ის tun-ად შეცვლა და იმედი. სერვერი კვლავ ხიდავს, კლიენტი ახლა IP-ზე ლაპარაკობს, და არაფერი ემთხვევა.

ნაბიჯი 4: შეაგროვეთ ფაქტები მუშა სერვისის შეცვლამდე

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

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

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

ნაბიჯი 5: გადაამოწმეთ მიგრაცია ორივე მხრიდან

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

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

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

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

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

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