OpenVPN-ის მომსახურება TCP და UDP-ზე ერთი ჰოსტიდან
2.7-მდე ერთი პროცესი ერთ ტრანსპორტს აბამს. შეადარეთ ხიდით დაკავშირებული TAP წყვილი, ორი TUN ქვექსელი და საერთო პული, შემდეგ თითოეული პროფილი თავის მსმენელს მიუსადაგეთ.
ქსელები, რომლებიც მხოლოდ TCP 443-ს უშვებენ, თანაარსებობენ იმ ქსელებთან, რომლებიც UDP-ს უპრობლემოდ ატარებენ, და ერთმა სერვერმა ორივეს უნდა მოემსახუროს. პროფილი proto udp-ით პასუხობს მეორე ჯგუფს და მარცხდება პირველზე, ხოლო იმავე კონფიგურაციის შეცვლა proto tcp-ის სათქმელად მეორე მსმენელს არ ქმნის. დირექტივა ერთ პროცესს ერთ ტრანსპორტს ურჩევს. დანარჩენი ყველაფერი ამ შეზღუდვიდან გამომდინარეობს.
ან ერთზე მეტ პროცესს ატარებთ, ან ისეთ ვერსიას ატარებთ, რომელსაც ერთდროულად რამდენიმე სოკეტის დაბმა შეუძლია.
2.7-მდე ერთი პროცესი ერთ ტრანსპორტს აბამს
საზოგადოებრივი OpenVPN აბამს იმ სოკეტს, რომელსაც proto აღწერს, და ეს დირექტივა ინსტანსისთვის ერთ ტრანსპორტს ურჩევს. TCP და UDP ცალკე სტეკებია, ამიტომ ერთი და იმავე პორტის ნომერი ორივეს შეუძლია ერთდროულად დაიკავოს, მაგრამ არა ერთ პროცესს. ამიტომ 2.6 ხაზი გაძლევთ ერთ ტრანსპორტს თითო დემონზე. OpenVPN 2.7-მა მოხსნა ეს შეზღუდვა სერვერებისთვის, რომლებსაც შეუძლიათ რამდენიმე სოკეტის დაბმა ერთ პროცესში რამდენიმე --local განაცხადის მეშვეობით.
შეამოწმეთ ვერსია, სანამ რომელიმე პასუხის გარშემო დააპროექტებთ, რადგან 2.7-ის განლაგება სხვა ოპერაციული მოდელია საკუთარი კონფიგურაციის სინტაქსით. 2.6-ისთვის დაწერილი სახელმძღვანელო ორ პროცესს აღწერს, თუნდაც ეს არ თქვას.
ორი ინსტანსის გაშვების სამი გზა
TAP ინტერფეისებით გაუშვით თითო ინსტანსი თითო ტრანსპორტზე და დააკავშირეთ ორი tap მოწყობილობა ჰოსტზე. კლიენტების ორივე ჯგუფი ერთსა და იმავე მაუწყებლობის დომენში აღმოჩნდება, რაც საშუალებას აძლევს ერთ მისამართების პულს დაფაროს ისინი და ინარჩუნებს მაუწყებლობაზე დამოკიდებული პროტოკოლების მუშაობას. TUN-ის შემთხვევაში ხიდი მიუწვდომელია, ამიტომ უმარტივესი გაყოფა თითოეულ ინსტანსს საკუთარ ქვექსელს აძლევს და მარშრუტიზაცია ცალ-ცალკე ინახავს კლიენტების ორ ჯგუფს. მესამე ვარიანტი ინარჩუნებს ერთ პულს იმით, რომ თითოეული ინსტანსი იძახებს learn-address სკრიპტს, რომელიც /32 მარშრუტს აყენებს კლიენტისთვის ამ ინსტანსის მოწყობილობის მეშვეობით.
ეს მესამე განლაგება არის ის, რასაც ხალხი ითხოვს და რაც ყველაზე მეტ ყურადღებას მოითხოვს, რადგან სკრიპტი ხდება მონაცემთა გზის ნაწილი და სწორად უნდა დაამუშაოს დამატების, განახლებისა და წაშლის მოვლენები.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
გამოყავით ორი ინსტანსი
თითოეულ ინსტანსს ასევე სჭირდება ცალკე პორტი ან მისამართი, ცალკე სტატუსის ფაილი და ცალკე ლოგის დანიშნულება. ორი დემონი, რომლებიც ერთ სტატუსის ფაილს ამატებენ, ქმნიან გამონატანს, რომლის წაკითხვაც ინციდენტის დროს შეუძლებელია, და სწორედ მაშინ გჭირდებათ ის. თუ მეორე ინსტანსი კონკრეტულ მისამართს აბამს, ეს მისამართი ჰოსტზე უნდა არსებობდეს პროცესის გაშვებისას; წინააღმდეგ შემთხვევაში ის გამოდის დაბმის შეცდომით, სანამ გასაღებებზე რამეს იტყვის.
დაასახელეთ ერთეულები და პროფილები ისე, რომ ტრანსპორტი ფაილის სახელიდანვე ცხადი იყოს. მომდევნო ოპერატორს არ უნდა მოუწიოს კონფიგურაციის გახსნა იმის გასაგებად, რომელია TCP.
შეუსადაგეთ პროფილი მსმენელს
proto tcp-ს გაშვებული სერვერი ელოდება კლიენტის პროფილს proto tcp-client-ით, და პროფილი, რომელსაც ჯერ კიდევ proto udp აქვს, ამ მსმენელის წინააღმდეგ ვადის გასვლისას წყდება ისე, რომ მომხმარებელს სამოქმედო შეცდომა არ ეძლევა. შეინახეთ ორი პროფილი, თუ განლაგება ორივე ტრანსპორტს გთავაზობთ, და მონიშნეთ ისინი ისე, რომ მხარდაჭერამ იცოდეს რომელი სცადეს. მხოლოდ პორტის ნომერი ტრანსპორტს არ აღწერს.
ფაირვოლის წესები იმავე დაყოფას მიჰყვება: UDP 1194-ის წესი არაფერს ამბობს TCP 1194-ზე, და ერთი მისამართის წესი მეორე მსმენელს არ ფარავს.
ჯერ წაიკითხეთ სერვერის ხედი
დაიწყეთ ss -lntup-ით სერვერზე და დაადასტურეთ, რომ ჩნდება როგორც TCP, ისე UDP მსმენელი. შემდეგ შეაერთეთ თითო კლიენტი თითოეული ტიპიდან და შეამოწმეთ სტატუსის გამონატანი ორი ჩანაწერისთვის სხვადასხვა მისამართებით. თუ სოკეტები არსებობს და კლიენტი არ მოდის, გზა ან ფაირვოლი უარყოფს პაკეტებს მანამ, სანამ დემონი დაინახავს მათ.
სოკეტი, რომელიც არასოდეს ჩნდება, კონფიგურაციის ან დაბმის პრობლემაა, ხოლო სოკეტი, რომელიც ჩნდება, მაგრამ კავშირს არასოდეს იწერს, ფილტრაციის პრობლემაა. კლიენტის მხრიდან ორივე ერთნაირად გამოიყურება, ამიტომაც სერვერის საკუთარი ხედი პირველია. გაითვალისწინეთ, რომ TCP-ს თან ახლავს რიგის თავის ბლოკირება, ამიტომ მისი შეთავაზება ხელმისაწვდომობის ღონისძიებაა და არა გაუმჯობესება სუფთა UDP გზის მქონე კლიენტებისთვის.