ამტვრევს თუ არა თქვენს ვებ სერვერზე VPN კლიენტი მის პასუხებს?

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

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

სიმპტომი: პასუხობს ლოკალურად და არა გარედან

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

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

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

რას ემთხვევა სინამდვილეში წყაროს სელექტორი

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

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

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

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

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

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

შემდეგ მიიღეთ ახალი გარე კავშირი და ცალკე მოთხოვნა, რომელიც ჯერ კიდევ VPN-ით უნდა გავიდეს. თუ მეორე ახლა პირდაპირ გადის, გამონაკლისი უფრო ფართოა, ვიდრე მოგვარებული პრობლემა, და მთავარი გამოცდა ის არის, რომლის შეცვლასაც არ აპირებდით.

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

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

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

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

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