VPN კლიენტები უკავშირდებიან, მაგრამ ინტერნეტი არ აქვთ: სამი დაკარგული ნაწილი

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

რატომ არ აქვს მუშა გვირაბს ჯერ გასასვლელი გზა

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

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

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

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

შეცვლამდე შეამოწმეთ მიმდინარე მნიშვნელობა, შემდეგ დააყენეთ და დაადასტურეთ, რომ ცვლილება ძალაში შევიდა.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

გახადეთ ის მუდმივი /etc/sysctl.d/-ის ქვეშ ფაილში, შემდეგ გამოიყენეთ ეს ფაილი გადატვირთვის ნაცვლად, რომ გაიგოთ. FreeBSD-ში ეკვივალენტია net.inet.ip.forwarding, ხოლო მუდმივობისთვის gateway_enable=YES rc.conf-ში. მოწყობილობა, რომელიც აცნობებს გადაცემის გამორთვას, ხსნის მთელ კლასს ანგარიშებისა „პაკეტები მოდიან და არაფერი ბრუნდება“. შეამოწმეთ პარამეტრი ყოველი განახლების შემდეგაც, რადგან ხელახლა აშენებულმა ბირთვმა ან შეცვლილმა მოწყობილობის იმიჯმა შეიძლება აღადგინოს ის ვინმესთვის თქმის გარეშე.

აირჩიეთ masquerade ან ერთი ფიქსირებული თარგმნის მისამართი

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

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

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

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

ფილტრის ცხრილი მესამე კარიბჭეა

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

სად უნდა შეხედოთ, როცა გვერდი არასოდეს იტვირთება

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

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

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

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