რა უნდა დაუშვას VPS-მა, სანამ თქვენს VPN-ს უმასპინძლებს

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

დაადასტურეთ პროტოკოლისთვის საჭირო ინტერფეისი

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

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

უარი პირველ წყვილზე ნიშნავს, რომ TUN მიუწვდომელია და OpenVPN-ის ნაგულისხმევი რეჟიმი ვერ დაიწყება; უარი ბოლო ხაზზე ნიშნავს, რომ WireGuard-ის ბირთვის ინტერფეისი აკლია. ბირთვის TUN/TAP დოკუმენტაცია აღწერს მოწყობილობას, რომელსაც პირველი შემოწმება ამოწმებს. არც ერთი ეს წარუმატებლობა არ სწორდება VPN პაკეტის ხელახალი ინსტალაციით.

დაიმახსოვრეთ, რომ შემავალ გზას ორი მფლობელი აქვს

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

UDP ჩვეულებრივი მსხვერპლია: ბევრი პლატფორმა ნაგულისხმევად უშვებს TCP-ს და UDP წესებს ცალკე ჩანაწერად თვლის. თუ ინსტანსი პროვაიდერის NAT-ის უკანაა და არა საჯარო მისამართით, პროვაიდერის მხარეს პორტების გადამისამართება მესამე შესათანხმებელი კონფიგურაცია ხდება.

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

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

გადაწყვიტეთ IPv6-ის საკითხი ცალსახად

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

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

დაამტკიცეთ გარე კლიენტიდან

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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