რატომ გამოდის OpenVPN-ის UDP პასუხი არასწორი მისამართიდან

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

რას ხედავს კლიენტი, როცა წყარო იცვლება

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

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

რას აკეთებს სინამდვილეში multihome ოფცია

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

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

როდის არის ფიქსირებული ლოკალური მისამართი არასწორი ნაგულისხმევი

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

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

დაამტკიცეთ პასუხის წყარო გარედან

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

მარშრუტიზაცია, აღმოჩენა და ფილტრაცია ცალკე რჩება

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

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