სამი გზა გაძლევთ OpenConnect-ის კლიენტს Mac-ზე და ისინი დისკზე სხვადასხვა რამეს ტოვებენ. Homebrew-ის ფორმულა აყენებს კომპილირებულ ბინარულ ფაილს და ქსელის სკრიპტს, რომელიც მარშრუტებსა და DNS-ს აყენებს. გამოშვების არქივი გაძლევთ წყაროს კოდს გენერირებული აგების სისტემით. git-ის ასლი გაძლევთ წყაროს კოდს მის გარეშე. არასწორის არჩევა არის მიზეზი, რის გამოც ადამიანები სახელმძღვანელოს დაწყებიდან რამდენიმე წუთში აწყდებიან დაკარგულ configure-ს.

ორი განსხვავებული მანქანა ერთი და იმავე სახელით

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

brew install openconnect

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

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

რას აკეთებს სინამდვილეში წყაროს გზა

გამოშვების არქივი მოდის გენერირებული აგების სისტემით, ამიტომ ნაცნობი ./configure თავიდანვე არსებობს. git-ის ასლში არა, რადგან გენერირებული ფაილები აგების პროდუქტებია და არა ის, რასაც პროექტი ინახავს. ეს არის მთელი მიზეზი, რის გამოც ./autogen.sh ჩნდება ასლების ინსტრუქციებში და არა გამოშვების არქივების.

./autogen.sh
./configure
make
make install

თითოეული ხაზი კონკრეტულ რამეს აკეთებს და იმის ცოდნა, რომელი ჩავარდა, ბევრ ვარაუდს ზოგავს. autogen საფეხური ატრიალებს autotools-ს configure-ის შესაქმნელად. configure საფეხური ამოწმებს კლიენტისთვის საჭირო კომპილატორს, ბიბლიოთეკებსა და სათაურებს, შემდეგ წერს makefile-ებს, რომლებიც ნაპოვნს ასახავს. make საფეხური აკომპილირებს. install საფეხური შედეგებს თქვენი გზის სადღაც კოპირებს.

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

სესია და ქსელური კონფიგურაცია ცალ-ცალკეა

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

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

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

იცოდეთ, რომელ ბინარულ ფაილს ატრიალებთ

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

which -a openconnect
openconnect --version
brew list --versions openconnect

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

კლიენტის დაყენება არ არის კარიბჭის დამტკიცება

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

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

დაკავშირებული სტატიები