ufw allow 443 VPN-ის უკან მდგარ სერვისს არაფერს არ უშველა

ping წარმატებით გადის VPN კლიენტიდან, TCP სერვისს დრო ეწურება და ufw allow 443/tcp საერთოდ არაფერს ცვლის. როცა აპლიკაცია მუშაობს კარიბჭის უკან მდგარ ჰოსტზე და არა თავად კარიბჭეზე, ეს ნებართვა არასწორი ტრაფიკის გზისთვის იყო დაწერილი. პაკეტი ფაირვოლზე არ არის მიმართული და ლოკალურ პროცესს არ გადაეცემა, ამიტომ შემავალი წესები მას ვერასოდეს ხედავს. გამოსავალია მარშრუტის წესი, რომელიც გადამისამართებულ ნაკადს მიემართება, და მისი მტკიცებულება უკვე ჟურნალშია.

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

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

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

წაიკითხეთ ბლოკი ნებისმიერი წესის დამატებამდე

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

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

ამ მაგალითში კლიენტები tun0-ზე მოდიან 172.20.8.0/24-დან, სერვისი უსმენს 10.30.0.15-ზე 8443 პორტზე, და კარიბჭე გადის ens5-ით. ეს მნიშვნელობები აირჩიეს იმისთვის, რომ საერთოდ არ ჰგავდეს ღრუბლოვანი VPC-ის ნაგულისხმევ 10.0.0.0/16-ს ან სახლის 192.168.0.0/16 ქსელს, და 8443 მაგალითს კარიბჭის საკუთარი 443 მსმენელისგან მოშორებით ინახავს.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

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

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

შეამოწმეთ, რისი უზრუნველყოფაც UFW-ს თქვენს ნაცვლად არ შეუძლია

სწორ წესს მაინც სჭირდება ბირთვის გადამისამართება და მარშრუტი, რომელიც სერვისამდე აღწევს. ორივე დაადასტურეთ, სანამ ფაირვოლს მეორედ დაადანაშაულებთ.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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