შეზღუდეთ OpenVPN-ის SNAT წესი, სანამ ის nginx-ს გატეხავს

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

დარწმუნდით, რომ კონტეინერს შეუძლია tun მოწყობილობის შექმნა

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

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

გადაწყვიტეთ, რას აკეთებს MASQUERADE ამ ინტერფეისზე

ჩვეულებრივ ვირტუალურ მანქანაზე ჩვეულებრივი გასასვლელი წესი მთავარი ინტერფეისიდან POSTROUTING MASQUERADE არის. OpenVZ კონტეინერში ხილული მოწყობილობა ხშირად venet0-ია, ჰოსტის მიერ მართული ვირტუალური ინტერფეისი და არა მარშრუტიზებული ქსელური ბარათი, და MASQUERADE იქ ყოველთვის არ იქცევა ისე, როგორც გაკვეთილები ვარაუდობენ.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

შეზღუდეთ წესი ერთი pool-ით და ერთი ინტერფეისით

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

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

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

გახადეთ წესები მუდმივი და გაარკვიეთ, კიდევ ვის ეკუთვნის ისინი

ხელით დამატებული წესები გადატვირთვისას ქრება, ამიტომ შეინახეთ ისინი iptables-save-ით ან მართეთ netfilter-persistent-ის მეშვეობით იქ, სადაც ის დაყენებულია. დაადასტურეთ, რომ აღდგენა OpenVPN-ის გაშვებამდე მუშაობს. შემდეგ ერთხელ განზრახ გადატვირთეთ, ნაცვლად იმისა, რომ ხარვეზი ინციდენტის დროს აღმოაჩინოთ.

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

გადაამოწმეთ მთვლელებით და ერთი დაჭერილი ნაკადით

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

სერვერზე წაიკითხეთ პაკეტების მთვლელები NAT და FORWARD წესებზე iptables -t nat -L -v -n-ით და დააკვირდით ერთ ნაკადს ჩანაწერში. თუ კლიენტის მისამართი ჩანაწერში ჩანს და პასუხი არ მოჰყვება, ხარვეზი დაბრუნების გზაზეა ან პროვაიდერის ფილტრაციაში, და არა კლიენტის პროფილში. შეადარეთ დაჭერილი წყარო იმ მისამართს, რომელზეც წესი თარგმნის, რადგან შეუსაბამობა ნიშნავს, რომ ჯერ სხვა წესი დაემთხვა. ერთი დაკვირვებული ნაკადი მეტს წყვეტს, ვიდრე კონფიგურაციის კითხვის ერთი გვერდი.

შეინახეთ pool, თარგმნილი მისამართი და ინტერფეისის სახელი ერთად ცვლილებების ჩანაწერში. ერთი pool-ისთვის სწორი წესი შემდეგს არასწორად თარგმნის.