ორი OpenVPN კლიენტი ერთ Linux კარიბჭეზე: გაყავით პოლიტიკა

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

ბირთვი წყვეტს, და არა დემონი

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

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

მიეცით თითოეულ ეგზემპლარს საკუთარი რესურსების ნაკრები

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

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

დაწერეთ მატრიცა: წყარო, ცხრილი, მოწყობილობა

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

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

თავად გვირაბის ტრანსპორტი კლიენტის ჯგუფში არ არის

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

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

გზის არჩევა მას არ უშვებს

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

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

რა ხდება, როცა ერთი გვირაბი ვარდება

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

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