OpenVPN AF_INET გაფრთხილება: უვნებელი დაბრუნება თუ წარუმატებელი socket?
გამოყავით AF_INET-ის დაბრუნება socket-ის შექმნის შემდგომი ჩავარდნისგან: წაიკითხეთ ზუსტი ხაზი, შემდეგ შეამოწმეთ მსმენელი და შემდეგი შეცდომა.
OpenVPN-ის ორი ჟურნალის ხაზი ერთი და იმავე სიტყვებით იწყება და მხოლოდ ერთი მათგანი აცხადებს პრობლემას. Could not determine IPv4/IPv6 protocol. Using AF_INET დაბრუნების შეტყობინებაა: პროფილმა მისამართების ოჯახი ღიად დატოვა, ამიტომ დემონმა ერთი აირჩია და განაგრძო. ჩავარდნის ტოტი აცხადებს, რომ socket არ შექმნილა და გადატვირთვას ითხოვს. საერთო პრეფიქსის შემდეგ ყველაფერი გამოყოფს მათ, ამიტომ წაიკითხეთ მის შემდეგ, სანამ რამეს შეცვლით.
რას აცხადებს დაბრუნების შეტყობინება
OpenVPN ღია ოჯახს იღებს proto udp4-ით ან proto udp6-ით, და იღებს proto udp-ს, როცა ოჯახი გაშვებისას უნდა გამოიყვანოს. მეორე შემთხვევაში დემონი ადგილობრივ bind ინფორმაციას ამოწმებს და ირჩევს.
როცა ეს გამოყვანა მუშაობს, გაფრთხილება ამბობს, რომელი მიმართულებით წავიდა და პროცესი socket-ის შექმნას აგრძელებს. ორმაგი სტეკის ჰოსტზე proto udp-ის მქონე სერვერი ხშირად ასე ხვდება IPv4-ზე. ამ გზაზე არაფერია შეცდომა და არაფერი მიუთითებს თავდასხმაზე, დაკარგულ ვებსერვერზე ან უარყოფილ ანგარიშზე. ხაზი მხოლოდ იმიტომაა სასარგებლო, რომ შემდგომი შემოწმებები მის მიერ დასახელებულ ოჯახს უნდა შეედაროს.
მიიღეთ ის როგორც პასუხი ერთ კითხვაზე, არა როგორც დიაგნოზი. ის ამბობს, რომელი ოჯახი აირჩია ამ პროცესმა და არაფერს იმის შესახებ, თუ რატომ ვერ უერთდება კლიენტი.
როგორ გამოიყურება ჩავარდნის ტოტი
მოგვიანებით იმავე socket-ის კოდში არის ტოტი, სადაც socket საერთოდ არ არსებობს. ის ჩაწერს მოკლე მისამართების ოჯახის შეტყობინებას და გადატვირთვას ითხოვს, რადგან გასაგრძელებელი არაფერი დარჩა. საწყისი სიტყვები ემთხვევა დაბრუნებას; შედეგი არა.
გამოარჩიეთ ისინი იმით, რაც მოჰყვება. თუ დემონი აგრძელებს მუშაობას და აცხადებს თავის მსმენელს, ხაზი ინფორმაცია იყო. თუ ის გადის ან ციკლში გადაიტვირთება, საუბარი ახლა bind-ზეა.
grep-ში ნაპოვნი ხაზი არც ტოტის იდენტიფიკაციაა. ფრაზა ჩნდება დატრიალებულ შეჯამებებში, გადახვეულ ხაზებში და ჟურნალის ამონაწერებში, რომლებსაც ადამიანები მეორე ხელიდან აკრავენ, ამიტომ წაიკითხეთ მეზობელი ხაზები და დროის ნიშნების თანმიმდევრობა და არა ერთადერთი დამთხვევა.
შეამოწმეთ მსმენელი და არა გაფრთხილება
მომუშავე სერვერი ოჯახის კითხვას პირდაპირ პასუხობს, ჟურნალის ტექსტიდან დასკვნის გარეშე.
ss -lunp | grep openvpn
ss -ltnp | grep openvpnშეადარეთ ოჯახი, მისამართი და პორტი პროფილს. 0.0.0.0:1194 ხაზი მხოლოდ IPv4-ია, ხოლო [::]:1194 ხაზი ორმაგი სტეკის ჰოსტზე შესაძლოა ორივე ოჯახი მიიღოს bindv6only პარამეტრიდან გამომდინარე. თუ პროფილი ამბობს udp-ს და socket IPv4-ია, კლიენტები, რომელთა გამხსნელი მხოლოდ AAAA ჩანაწერს აბრუნებს, ჩავარდებიან სანამ გვირაბზე მოლაპარაკება მოხდება.
შემდეგ გამოსცადეთ კლიენტიდან, რომელიც თქვენს მომხმარებლებს ჰგავს: იგივე გამხსნელის გზა, იგივე ტიპის ქსელი. სერვერიდან ლოკალური კავშირი ძალიან ცოტას ამტკიცებს იმ ტრაფიკზე, რომელიც NAT მოწყობილობას ან მეორე ოჯახისთვის დაწერილ firewall წესს გადის.
როდის არის ოჯახის იძულება სწორი
proto udp4-ის მიმაგრება შეეფერება მხოლოდ-IPv4 განლაგებას: მხოლოდ A ტიპის DNS სახელი, firewall წესები ერთი v4 მისამართისთვის, კლიენტები ოპერატორების უკან, რომლებიც მხოლოდ v4 მისამართებს გასცემენ. ეს აშორებს გაურკვევლობას და შემდეგ ჟურნალის ხაზებს პროგნოზირებადს ხდის.
იგივე არგუმენტი საპირისპიროდ მუშაობს IPv6-პირველ გარემოში, და მხოლოდ A კლიენტური ბაზის წინ udp6 თვითშექმნილი შეფერხებაა. ოჯახის იძულება მხოლოდ უვნებელი გაფრთხილების ჩასახშობად ამ შეცდომის კლასიკური ვერსიაა, რადგან შეცვალეთ, ვის შეუძლია დაკავშირება, უფრო მშვიდი ჟურნალის სანაცვლოდ.
აირჩიეთ საბოლოო წერტილებიდან და იმ კლიენტებიდან, რომლებმაც უნდა მიაღწიონ მათ. OpenVPN 2.6 სახელმძღვანელო აღწერს ტრანსპორტის ფორმებს, და შეტყობინება ამ არჩევანის გამომავალია, არა მისი შემავალი.
შეინარჩუნეთ ჩანაწერი ვიწრო
ჩაწერეთ ზუსტი ხაზი მისი დროის ნიშნით, მომუშავე პროფილის ეფექტური ტრანსპორტის პარამეტრი, socket ისე, როგორც ბირთვი აცხადებს, და შემდეგი ეტაპი, რომელიც ჩავარდა. ეს ოთხი პუნქტი აგვარებს შეტყობინების მიერ დაყენებულ თითქმის ყველა კითხვას და არც ერთი მათგანი არ საჭიროებს დაუკავშირებელ სერვისებზე ვარაუდს. ისინი ასევე გადაურჩება გადაცემას, რასაც grep-ის ეკრანის სურათი არ აკეთებს.
ამ გაფრთხილებასთან ერთად მოსული პაკეტის შემოთავაზებები დაუკავშირებელია, სანამ შეცდომა არ დაასახელებს დაკარგულ შესრულებად ფაილს.
თუ ifconfig ნამდვილად აკლია, დემონი ამას სახელით ამბობს, როცა სკრიპტი მას იძახებს, და ეს ცალკე გამოძიებას იმსახურებს. AF_INET ხაზი და დაკარგული უტილიტა განსხვავებული ჩავარდნებია, და რაღაცეების დაყენება იმის სანახავად, იცვლება თუ არა გაფრთხილება, ის გზაა, რომლითაც სუფთა ჰოსტი არეულ ჰოსტად იქცევა.