წინასწარ შექმნილი tun OpenVPN-ში: ორი მფლობელობის მოდელის შედარება
წინასწარ შექმნილი tun ინტერფეისი ხელახლა გამოიყენება, მაგრამ მისი მისამართები და მარშრუტები მხოლოდ ერთ კომპონენტს უნდა ეკუთვნოდეს. შეადარეთ ორივე მოდელი ifconfig-noexec-ის დამატებამდე.
ვიღაცამ წინასწარ შექმნა tun1, პროფილი ამბობს dev tun1, და კავშირი მაინც არ უერთდება. სახელის არსებობა ჰოსტზე თითქმის არაფერს ამბობს, რადგან მიერთება დამოკიდებულია სახელთა სივრცეზე, მოწყობილობის ტიპზე, იმაზე, თუ ვინ ფლობს ბმულს და რა არის დემონისთვის ნებადართული. მოწყობილობის ხელახალი გამოყენება ასევე ავალდებულებს გადაწყვეტილებას, რომელსაც ნაგულისხმევი კონფიგურაცია მალავს: რომელი კომპონენტი წერს მისამართებსა და მარშრუტებს. ორი წყობის მარცხის რეჟიმები გაცილებით მეტად განსხვავდება, ვიდრე კონფიგურაციის სტრიქონები, ამიტომ გადაწყვიტეთ პროფილის რედაქტირებამდე.
სახელი მიერთება არ არის
dev tun1 OpenVPN-ს სთხოვს სწორედ იმ დასახელებულ ინტერფეისს, და ტრადიციული მომხმარებლის სივრცის აწყობები შეეცდებიან მის გახსნას. თუ სახელი არ მიჰყვება ჩვეულებრივ tun ან tap ნიმუშს, პროფილს ასევე სჭირდება შესაბამისი dev-type, რადგან ტიპი არასოდეს გამოიტანება სტრიქონიდან. TAP მოწყობილობა არ არის სხვა ეტიკეტის მქონე TUN მოწყობილობა: არასწორის მიერთება ან დაუყოვნებლივ ვარდება, ან ქმნის ბმულს, რომელიც ატარებს კადრებს, რომლებსაც არავინ ელის. შეამოწმეთ ტიპი ყველაფერზე ადრე, რადგან ყოველი შემდგომი შემოწმება ვარაუდობს, რომ ორივე მხარე მასზე თანხმდება. ამის შემდეგ დაადასტურეთ, რომ პროცესს ნამდვილად შეუძლია მოწყობილობის გახსნა და არა მხოლოდ მისი დანახვა.
dev tun1
dev-type tun
ქსელური ინტერფეისი და /dev/net/tun სხვადასხვა ობიექტია: ერთი სახელთა სივრცის შიგნით ბმულია, მეორე კი სიმბოლური მოწყობილობა, რომელსაც მომხმარებლის სივრცის პროგრამა მიერთებისთვის იყენებს. Linux TUN/TAP-ის დოკუმენტაცია აღწერს ამ მიერთების გზას და მუდმივი მოწყობილობების მფლობელობის წესებს. root-შელი, რომელსაც შეუძლია ip link-ის გაშვება, მხოლოდ იმას ამტკიცებს, რომ შელს აქვს უფლებები და არა იმას, რომ დემონს აქვს. მოწყობილობის კვანძის მფლობელობა, სერვისის შესაძლებლობების ნაკრები და მომხმარებელი, რომლის სახელითაც ის მუშაობს — ყველა უნდა შეესაბამებოდეს ერთმანეთს, სანამ გახსნა წარმატდება.
მოწყობილობა, რომელიც არსებობს და არ იხსნება, მფლობელობის პრობლემაა და არა მარშრუტიზაციის. დიაგნოსტიკის დროს სწორედ ასე მოეპყარით, თორემ შუადღე წავა იმ მარშრუტების ცხრილების კითხვაზე, რომლებიც არასოდეს ყოფილა პრობლემა.
ვინ აკონფიგურებს ბმულს: ორი მფლობელობის მოდელი
პირველ მოდელში OpenVPN აკონფიგურებს მისამართებსა და მარშრუტებს კავშირის აწევის ნაწილად. ეს ნაგულისხმევი ქცევაა და ყველაზე იოლი გასააზრებელი, რადგან ერთი კომპონენტი ქმნის მდგომარეობას და შემდეგ ისევ შლის. მეორე მოდელში ინტერფეისს გარე მმართველი ფლობს, და ifconfig-noexec უშლის OpenVPN-ს მისამართების კონფიგურაციის ბრძანებების გაშვებაში და პარამეტრებს სკრიპტებს გადასცემს. მაშინ მმართველმა თავად უნდა გამოიყენოს სწორი ლოკალური და პარტნიორის კონფიგურაცია, რაც მეტი სამუშაოა, ვიდრე ოპციის სახელი გვაფიქრებინებს. ამ ორს შორის არჩევა კითხვაა იმაზე, თუ ვის შეუძლია ბმულის შეცვლა, სანამ ის აწეულია.
ifconfig-noexec მხოლოდ მისამართებს მოიცავს: მარშრუტიზაციის ცხრილი ხელუხლებელი რჩება, ხოლო მარშრუტების კონფიგურაცია route-noexec-ს ეკუთვნის. ორ დირექტივას მოეპყარით როგორც ცალკე მართვას ცალკე მფლობელებით, რადგან ერთის დაყენება და მეორის ვარაუდი ნახევრად კონფიგურირებული ბმულების ჩვეულებრივი წყაროა. აირჩიეთ ზუსტად ერთი მფლობელი თითოეული ფენისთვის: მისამართები ერთ ადგილას და მარშრუტები ერთ ადგილას. ქსელის მმართველი და VPN-ის დამხმარე, რომლებიც ორივე მისამართებს წერენ, სწორედ ის გზაა, რომლითაც გათიშვა შლის მდგომარეობას, რომელზეც მეორე მხარე ჯერ კიდევ არის დამოკიდებული.
შეისწავლეთ მოწყობილობა იმ სახელთა სივრციდან, რომელსაც მნიშვნელობა აქვს
შეისწავლეთ მოწყობილობა იმ სახელთა სივრციდან, სადაც VPN პროცესი მუშაობს და არა იქიდან, სადაც შემთხვევით თქვენი შელია. ქვემოთ მოცემული ორი ბრძანება სხვადასხვა კითხვას პასუხობს, და განსხვავება მაშინ ჩნდება, როცა ჰოსტი ხედავს ინტერფეისს, რომელსაც კონტეინერი ვერ ხედავს. გაუშვით ისინი მოცემული თანმიმდევრობით, რადგან მეორეს აზრი მხოლოდ მას შემდეგ აქვს, რაც გაიგებთ, საერთოდ არსებობს თუ არა ბმული.
ip -details link show dev tun1
ip tuntap show
პირველი ბრძანება ბეჭდავს ბმულს ისე, როგორც მას ბირთვი ხედავს, დროშებისა და ინტერფეისის ტიპის ჩათვლით, და სწორედ ასე ადასტურებთ, რომ ეს არის ის მოწყობილობა, რომელიც გულისხმობდით. მეორე ჩამოთვლის მუდმივ tun/tap ჩანაწერებს, რომლებიც არსებობს იმის გარეშე, რომ რომელიმე პროცესი უჭირავდეს. ინტერფეისი, რომელიც თავის დანიშნულ მფლობელს ელოდება, სხვა სიტუაციაა, ვიდრე სხვა VPN-ზე მიერთებული ცოცხალი გვირაბი, და მხოლოდ მეორე ხსნის, რატომ ვარდება თქვენივე მიერთება. იპოვეთ მოწყობილობის დამჭერი პროცესი, სანამ რამეს შეცვლით, რადგან მუდმივ ჩანაწერსა და დაკავებულ ინტერფეისს სხვადასხვა გადაწყვეტა აქვთ.
მრავალრიგიანი მხარდაჭერა დრაივერის კონკრეტული განლაგებაა საკუთარი მოთხოვნებით და არა დაუკავშირებელი პროცესებისთვის ერთი ინტერფეისის გაზიარების ნებართვა. სხვა მფლობელის ცოცხალი სესია კოორდინაციის პრობლემაა და არც ერთი პროფილის რედაქტირება არ ჭრის მას.
ორი სახის მდგრადობა
ბირთვის მდგრადობა და persist-tun აღწერენ სიცოცხლის ხანგრძლივობებს, რომელთა არევა იოლია და ძვირი. მუდმივი მოწყობილობა არსებობს ნებისმიერი პროცესისგან დამოუკიდებლად, ამიტომ გადაურჩება გაჩერებას და შემდეგი გაშვება ხელახლა გამოიყენებს. persist-tun ინახავს რესურსებს ერთი OpenVPN პროცესის შიგნით მხარდაჭერილ რბილ გადატვირთვებში, გაცილებით მოკლე ჰორიზონტი. არც ერთი არ გვპირდება, რომ სერვისის გაჩერება მარშრუტებსა და მისამართებს ადგილზე დატოვებს, და ხილული ინტერფეისი მუშა დაშიფრული სესიის მტკიცებულება არ არის.
დაადასტურეთ აგრეთვე backend, რადგან წინასწარ შექმნილი ინტერფეისი არაფერს ამბობს იმაზე, თუ რომელი იმპლემენტაცია გახსნის მას. საზოგადოების აწყობები, რომლებსაც პირდაპირი მონაცემთა გზა აქვთ, შეეცდებიან მის გამოყენებას, თუ დიზაინი სხვას არ ამბობს. სადაც ვერსია მხარს უჭერს გადამრთველს, disable-dco ნაცვლად ირჩევს მომხმარებლის სივრცის გზას; ძველ ძრავებსა და სხვა კლიენტებს ასეთი დირექტივა არ აქვთ, ამიტომ ვერსიის პირობა ოპციის გვერდით შეინახეთ და ნუ ჩათვლით, რომ ის ვრცელდება.
რა ტყდება, როცა მხოლოდ გაშვება მოწმდება
მფლობელობის შეთანხმებამ შეიძლება პირველი გამოცდა ჩააბაროს და ბოლოზე ჩავარდეს, რაც გაშვებას თავისთავად სუსტ შემოწმებად აქცევს. ნაცვლად ამისა დააკვირდით ორ გადასვლას: რბილ გადატვირთვას და სრულ გაჩერებას, რომელსაც გაშვება მოჰყვება.
systemctl status openvpn-client@lab
ip -details link show dev tun1
გაშვება იოლი შემთხვევაა: ერთეული ადის, ბმული ჩნდება და მდგომარეობის გამომავალი ასახელებს ჩატვირთულ პროფილს. მიერთება ის მომენტია, როცა დემონი ხსნის მოწყობილობას, ამიტომ ბმულის შემოწმება გაუშვით მას შემდეგ, რაც ერთეული შეატყობინებს აქტიურობას და არა მანამდე. თუ ბმული არსებობს, სანამ მდგომარეობა ჯერ კიდევ აქტიურდება, თქვენ უყურებთ მუდმივ მოწყობილობას, რომელზეც ჯერ არავინ მიურთდა და არა მუშა გვირაბს. გაატარეთ რეალური ტრაფიკი ბმულზე სანამ გააგრძელებთ, რადგან გამოსადეგი მარშრუტის გარეშე მიერთებული ინტერფეისი მაინც მარცხია.
kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1
რბილმა გადატვირთვამ სესია გამოსადეგი უნდა დატოვოს და რესურსები უვნებელი, და სწორედ ამ სამუშაოს ასრულებს persist-tun. სრული გაჩერება ის ადგილია, სადაც გარე მმართველი თავს ამჟღავნებს: თუ ბმული ან მისი მისამართები გაჩერებას გადაურჩა, მაშინ ისინი სხვას ეკუთვნის, და ეს ან თქვენ მიერ დოკუმენტირებული მდგომარეობაა ან ახლახან ნაპოვნი შეცდომა. ჩაწერეთ ორივე დაკვირვება პროფილის გვერდით, რათა შემდეგი ცვლილება მტკიცებულებიდან დაიწყოს და არა დიაგრამიდან.