სად ჯდება VPN-ის NAT UFW-ის before.rules-ში და როგორ შევამოწმოთ

NAT წესი, რომელიც shell-ში აკრეფისას მუშაობს, ვერ მუშაობს before.rules-ში ჩასმისას, რადგან ეს ფაილი სკრიპტი არ არის. ეს არის აღდგენის ფორმატის დოკუმენტი ცხრილის სექციებით, ჯაჭვების დეკლარაციებით და თითოეული ცხრილისთვის COMMIT ნიშნით. არასწორ ადგილას მყოფი სტრიქონი ან აჩერებს მთელ აღდგენას, ან ჩუმად აგდებს წესებს, რომლებიც გგონიათ, რომ არსებობს. ქვემოთ მოცემული სახელმძღვანელო ათავსებს ფრაგმენტს იქ, სადაც ჩარჩო ელოდება, და ადასტურებს შედეგს შემდეგ ჩატვირთვამდე.

Shell-ის ბრძანება აღდგენის ფაილი არ არის

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

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

მოათავსეთ ფრაგმენტი არსებულ ცხრილის სექციაში

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

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

ზემოთ მოცემული პული და ინტერფეისი თქვენი მნიშვნელობების ადგილმჭერებია; კოპირებადი ნაწილი სტრუქტურაა. თუ ფაილში უკვე არის *nat სექცია, დაამატეთ წესი ამ სექციის შიგნით და არ გახსნათ მეორე, რადგან ფორმატი თითო ცხრილზე ერთ COMMIT-ს ითვალისწინებს, და ერთი და იმავე ცხრილისთვის ორი სექცია შეკეთებაა, რომელიც დადგომას ელოდება. შეინარჩუნეთ დისტრიბუციის ჯაჭვების განსაზღვრებები ხელუხლებლად, მათ შორის ის, რაც მომწოდებელმა დაამატა საკუთარი ინტეგრაციისთვის. UFW ჩარჩოს სახელმძღვანელო აღწერს before, user და after ფაილებს შესაბამისი COMMIT-ის მოთხოვნასთან ერთად.

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

შეამოწმეთ კანდიდატი გამოყენების გარეშე

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

აირჩიეთ ხელსაწყო, რომელიც შეესაბამება დაყენებულ backend-ს და მისამართების ოჯახს. nft backend-ის თავსებადობის ფენით გაშვებულ ჰოსტს სჭირდება შესაბამისი ბრძანება, და IPv6 წესები ცხოვრობს სრულიად სხვა ფაილში.

გამოყავით გადაგზავნა, NAT და წვდომის პოლიტიკა

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

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

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

გადაამოწმეთ ჩატვირთვა, უარი და VPN-ის დაკარგვა

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

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