ორი OpenVPN გვირაბი ერთ Linux ჰოსტზე: ვის ეკუთვნის მარშრუტი?

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

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

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

გადამფარავი პულები მარშრუტიზაციამდე ტყდება

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

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

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

მიეცით თითოეულ პროფილს საკუთარი ერთეული და თითოეულ პრეფიქსს მფლობელი

თითოეული პროფილი იღებს საკუთარ ინსტანციის სახელს და საკუთარ კონფიგურაციის ფაილს, ამიტომ office-ის სახელის მქონე ინსტანცია ტვირთავს office.conf-ს, ხოლო lab-ის სახელის მქონე ტვირთავს lab.conf-ს. დაადასტურეთ ეს დაკავშირება სერვისების მენეჯერის მეშვეობით და არ დაეყრდნოთ დირექტორიის სიას, რადგან drop-in-მა შეიძლება შეცვალოს, რომელი ფაილი იტვირთება. დაკავშირების შეცდომა ნიშნავს, რომ აწყობთ იმ პროფილს, რომელიც არ მუშაობს.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

ნიშნები პასუხებს ინახავს იმ ინტერფეისზე, საიდანაც მოვიდნენ

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

დაამტკიცეთ იზოლაცია ერთი კავშირის გაჩერებით

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

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

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