PiVPN-ის ხელის ჩამორთმევა მუშაობს, გვერდები ჩერდება: შეამოწმეთ MASQUERADE

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

დაიწყეთ იმით, რისი მიღწევაც კლიენტს შეუძლია და რისი არა

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

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

შემდეგ ჰკითხეთ სერვერს, რომელი ინტერფეისით მიაღწევდა საჯარო მისამართს. ip route get 203.0.113.9 პირველ სტრიქონში ბეჭდავს არჩეულ მოწყობილობასა და წყაროს. ჩაწერეთ მოწყობილობის სახელი, რადგან სწორედ ეს მნიშვნელობა უნდა შეიცავდეს NAT წესს.

წაიკითხეთ წესი, რომელიც წყვეტს, გავლენ თუ არა პაკეტები

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

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

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

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

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

მხოლოდ ცოცხალი ცხრილის რედაქტირება გრძელდება შემდეგ გადატვირთვამდე, რაც ზუსტად საკმარისია იმის დასარწმუნებლად, რომ პრობლემა მოგვარებულია. ჩართვისას დაბრუნებული წესები ცხოვრობს ფაილში, რომელსაც ფაირვოლის მუდმივობის პაკეტი ხელახლა ტვირთავს. Debian-ზე დაფუძნებულ Pi გამოსახულებებში ეს ფაილი ჩვეულებრივ /etc/iptables/rules.v4.

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

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

ორი მეზობელი პარამეტრის დავიწყება ადვილია. sysctl net.ipv4.ip_forward უნდა აცნობოს 1, და ზედა როუტერმა თავად არ უნდა გაფილტროს კერძო წყაროს მისამართები.

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

მრიცხველები ერთადერთი პატიოსანი მტკიცებულებაა, რომ წესი დაემთხვა. გაუშვით დეტალური სია, კლიენტზე ჩამოტვირთვა დაიწყეთ და ისევ გაუშვით. თქვენი წესის გვერდით პაკეტებისა და ბაიტების სვეტები უნდა გაიზარდოს, და ნულზე დარჩენილი წესი ჯერ კიდევ არ ემთხვევა. თუ მრიცხველები მოძრაობს, მაგრამ გვერდები მაინც ფეილდება, შეადარეთ წყაროს დიაპაზონი ფაქტობრივ პულს ამით grep -n "^server " /etc/openvpn/server.conf. თუ ისინი მოძრაობს და გვერდები იტვირთება, მაგრამ გამტარუნარიანობა სუსტია, თარგმნა დასრულებულია და დარჩენილი პრობლემა სხვაგანაა.

შეადარეთ ორი გადაცემა ერთი და იმავე კლიენტიდან, ერთი ლოკალურ ქსელში მყოფ ჰოსტზე და მეორე გვირაბით იმავე ჰოსტზე. ორივე შემთხვევაში ნელი ნიშნავს Pi-ის ზედა არხს ან Wi-Fi კავშირს და არა VPN-ს. მხოლოდ გვირაბით ნელი ნიშნავს MTU-ს და ხელახალ გაგზავნებს, რომლებიც შეგიძლიათ შეამოწმოთ ამით ip -s link show tun0 ნებისმიერი კრიპტო პარამეტრის შეცვლამდე.

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