OpenVPN-ის სერვერი და კლიენტი ერთ ჰოსტზე: რატომ ცვივა კლიენტები

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

ერთი მანქანა, ორი როლი და ორი შეუთავსებელი პასუხი იმაზე, სად უნდა წავიდეს პასუხები.

იგივე აუზი, ორი სერვერი: რომელი იმარჯვებს

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

ჩამოთვალეთ რა არის აქტიური რედაქტირებამდე: ip -4 addr show გვირაბის მოწყობილობებს ჩამოთვლის, ss -lunp მსმენელებს ჩამოთვლის, ხოლო systemctl list-units ერთეულებს ასახელებს. გვირაბის მისამართებზე ერთი შეხედვა წყვეტს, ეჯახება თუ არა აუზები.

რას უმატებს კლიენტის პროფილი ცხრილს

კლიენტის ნახევარი მარშრუტებს დაუყოვნებლივ წერს, როგორც კი უკავშირდება. redirect-gateway def1 ნაგულისხმევ მარშრუტს ყოფს 0.0.0.0/1-ად პლუს 128.0.0.0/1-ად, ორივე ახალი მოწყობილობის გავლით იმარშრუტება, ერთად ჰოსტის მარშრუტით შორეული სერვერისკენ, რომელიც განზრახ არის მიმაგრებული ფიზიკურ ინტერფეისზე. ეს მიმაგრება იმიტომ არსებობს, რომ გვირაბმა საკუთარი ტრანსპორტისთვის გზა შეინარჩუნოს. ყველა დანარჩენი, მათ შორის პასუხები, რომლებიც ლოკალურ სერვერს საკუთარი კლიენტების წინაშე აქვს, ახლა ახალ ნაგულისხმევს მიჰყვება და შორეული კავშირით გადის.

ასე რომ, მეორე შეჯახება გატეხილი გვირაბი არ არის. ეს არის მომუშავე გვირაბი ცხრილში არასწორ ადგილას.

როლების განცალკევების სამი გზა

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

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

ორი ეგზემპლარიდან რომელია დამნაშავე

გააჩერეთ კლიენტის ეგზემპლარი და ხელახლა შეამოწმეთ თავდაპირველი კლიენტები. მყისიერი აღდგენა ნიშნავს მარშრუტიზაციას და არა სერვერს. დააბრუნეთ კლიენტი და თვალყური ადევნეთ ერთ პასუხს ip route get-ით, რომელსაც მიეცა როგორც წყაროს, ისე დანიშნულების მისამართი, რაც აჩვენებს გზას, რომელსაც ბირთვი აირჩევდა, შემდეგ დააკვირდით ინტერფეისს, რომელსაც პაკეტები რეალურად იყენებენ, tcpdump -ni any port 1194-ით. სერვერის სტატუსის ფაილი, რომელიც ყოველ რამდენიმე წამში იწერება status დირექტივით, შეიცავს დაკავშირებული კლიენტების სიას და ბაიტების მთვლელებს ორივე მიმართულებით.

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