ხიდური OpenVPN კლიენტებს ინტერნეტი არ აქვთ? შეამოწმეთ NAT წესი

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

მტკიცებულება მრიცხველია, და არა ცხრილის სტრიქონი

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

iptables -t nat -L POSTROUTING -v -n

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

იპოვეთ სახელი, რომელსაც ბირთვი რეალურად იწერს

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

ip -brief link

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

გადაწერეთ წესი გვირაბის მოწყობილობაზე

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

forward ჯაჭვის მრიცხველებით წაკითხვას ერთი ბრძანება სჭირდება და გამორიცხავს დარჩენილი შესაძლებლობების ნახევარს, სანამ სხვა წესს შეეხებით.

რატომ არასოდეს ემთხვევა ფიზიკური ბარათი

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

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

დაამტკიცეთ თავიდან ბოლომდე და შემდეგ გახადეთ მუდმივი

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

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

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