VPN მარშრუტი თუ firewall-ის წესი: რომელი აგდებს პაკეტს?

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

ორი გადაწყვეტილება, ერთი პაკეტი, ორი მფლობელი

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

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

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

წაიკითხეთ, რა აირჩია ძიებამ სინამდვილეში

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

ფილტრაცია ძალაშია კაუჭზე, არა მარშრუტზე

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

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

გაგზავნეთ პრობა იმ გზით, რომელსაც კლიენტი იყენებს

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

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

ip route add-ით დამატებული მარშრუტი ცოცხლობს მანამ, სანამ ინტერფეისი ჩამოვარდება. შეინახეთ ის კავშირის პროფილში: NetworkManager კავშირზე დამატებით მარშრუტებს იღებს, ხოლო netplan ინახავს მათ გადატვირთვებს შორის. იგივე წესი ეხება კლიენტის მხარეს firewall-ის გამონაკლისს, რომელიც შემდეგი გადატვირთვის შემდეგ ქრება.

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

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