OpenVPN-ზე დაკავშირებული ხართ, მაგრამ არაფერი იტვირთება: გზა კლიენტიდან გარეთ

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

დაიწყეთ კლიენტიდან და იარეთ გარეთ

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

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

ორი ჩანაწერი აჩვენებს, სად ჩერდება პაკეტები

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

ამ გამოსავალში dev ველი არის სახელი, რომელიც NAT წესს მოგვიანებით დასჭირდება, ამიტომ შეინახეთ იგი.

გადამისამართება ბირთვის გადამრთველი და ფაიერვოლის პოლიტიკაა

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

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

გადამისამართება მხოლოდ ნახევარია. UFW-ის მქონე ჰოსტზე გადამისამართების პოლიტიკა ისმება /etc/default/ufw-ში და უნდა იყოს ACCEPT, სანამ გადატვირთვა ძალაში შევა. ნაგულისხმევი ჩამოგდება გადამისამართების გზაზე ხელის ჩამორთმევას სრულიად ჯანმრთელს ტოვებს, მაგრამ ჩუმად აგდებს ყოველ პაკეტს, რომელიც გვირაბიდან გასვლას ცდილობს, და ეს ზუსტად ის სიმპტომია, რომლითაც დაიწყეთ.

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

დაასახელეთ რეალური გასასვლელი ინტერფეისი NAT წესში

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

კლასიკური მარცხი არის სახელმძღვანელოდან კოპირებული წესი, რომელიც ამბობს -o eth0 იმ მანქანაზე, რომლის ადაპტერს სხვა სახელი აქვს. წესი დგინდება გაფრთხილების გარეშე, არ ემთხვევა არაფერს, და კლიენტს კვლავ არ აქვს ინტერნეტი. პული იმავე შეცდომის მეორე ნახევარია: თუ სერვერი იძლევა 10.44.0.0/24-ს და წესი ფარავს 10.8.0.0/24-ს, არაფერი არასოდეს დაემთხვევა.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS მეორე მარცხია პირველის უკან

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows კლიენტები შეიძლება მერე მაინც დაბრუნდნენ ლოკალურ გადამწყვეტზე, და სწორედ ამის თავიდან ასაცილებლად არსებობს block-outside-dns, იმ ფასად, რომ დაიკარგოს სახელები, რომელთა გადაწყვეტაც მხოლოდ ლოკალურ ქსელს შეუძლია. systemd-resolved-ის მქონე Linux კლიენტები ხშირად უგულებელყოფენ გაგზავნილ გადამწყვეტს, თუ სკრიპტი არ დააყენებს მას, ამიტომ სანამ დაასკვნით, რომ გაგზავნა უგულებელყოფილია, შეამოწმეთ resolvectl status გვირაბის მოწყობილობისთვის.

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