VPN დაკავშირებულია, მაგრამ firewall მაინც ბლოკავს: როგორ გავიგოთ რომელი

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

გამოყავით გზა პოლიტიკისგან

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

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

წაიკითხეთ გზა ერთი გავლით

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

წაიკითხეთ პოლიტიკა იმ ფენაზე, რომელიც პასუხობს

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

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

წაიკითხეთ კარიბჭის გადაწყვეტილება, როცა გვირაბი იქ მთავრდება

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

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

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

შეცვალეთ ყველაზე ვიწრო ფენა, შემდეგ შეამოწმეთ

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

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

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

სანამ დახურავთ:

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