გამოაქვეყნეთ VPN კლიენტის პორტი CGNAT-ის მიღმიდან: ჩამონათვალი

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

დაადასტურეთ, რომ სერვერი საერთოდ გადაამისამართებს

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

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

მისი დაყენება მოქმედ ბირთვში არ არის იგივე, რაც რესტარტის გავლით დაყენება. ჩაწერეთ net.ipv4.ip_forward=1 ფაილში /etc/sysctl.d/-ის ქვეშ, გაუშვით sysctl --system და შემდეგ წაიკითხეთ მნიშვნელობა უკან, იმის ნაცვლად რომ ირწმუნოთ ფაილის აღება. კონტეინერს, რომელიც მართავს საკუთარ ქსელურ სახელთა სივრცეს, იგივე მნიშვნელობა სჭირდება ამ სივრცის შიგნით, და არა მხოლოდ ჰოსტზე.

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

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

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

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

თარგმნეთ ორივე მიმართულებით

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

წაიკითხეთ ორივე წესი უკან iptables -t nat -S-ით და დაადასტურეთ, რომ ინტერფეისის სახელი სწორედ ის არის, რომელიც ატარებს საჯარო მისამართს. ჰოსტზე, რომელიც უკვე ფილტრავს nftables-ით, დაწერეთ თარგმანი შესაბამისი მისამართების ოჯახის nftables NAT ჯაჭვში ინსტრუმენტების შერევის ნაცვლად.

გაატარეთ ფილტრის ცხრილი

NAT ცხრილები თავსართებს გადაწერს; ისინი ნებართვას არ იძლევიან. ნაგულისხმევი DROP პოლიტიკით გადაცემულ ნაკადს სჭირდება საკუთარი დაშვება, პლუს დაბრუნების მიმართულება, რომელსაც პოლიტიკების უმეტესობა უკვე ფარავს established,related წესით.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

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

tcpdump -ni any port 29443
conntrack -L | grep 29443

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

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