საიტებს შორის VPN მხოლოდ ერთი მიმართულებით მუშაობს: ორი განსხვავებული ხარვეზი
პასუხი, რომელიც არასოდეს ბრუნდება, და კავშირი, რომელიც უარყვეს, ორი განსხვავებული ხარვეზია. შეადარეთ პოლიტიკა, მარშრუტიზაცია და წყაროს მისამართი, რომელსაც სერვერი რეალურად ხედავს.
საიტი A აღწევს B-ს, B ვერ აღწევს A-ს, და გვირაბი ორივე მიმართულებით წესრიგში ჩანს. გვირაბზე ხელის დადებამდე გადაწყვიტეთ, რომელი ხარვეზი გაქვთ სინამდვილეში. B-ზე დაწყებული და უარყოფილი ახალი კავშირი და A-ზე დაწყებული კავშირის ის პასუხი, რომელიც არასოდეს მოდის, მსგავს საჩივრებს და სრულიად განსხვავებულ დიაგნოზებს წარმოქმნის. ერთი გზაზე პოლიტიკის ან მარშრუტის პრობლემაა; მეორე უკვე დაშვებული ტრაფიკის დაბრუნების გზის ან მდგომარეობის პრობლემაა.
ეს განსხვავება განსაზღვრავს, რომელი ბრძანებების გაშვებას აქვს აზრი.
ორი ხარვეზი, რომლებიც ერთნაირად გამოიყურება
პირველ შემთხვევაში B-ის ჰოსტი A-ს უგზავნის SYN-ს და არაფერი ბრუნდება. მეორეში A-ის ჰოსტი წარმატებით ხსნის სესიას და პასუხი უკანა გზაზე ქრება. ორივე მომხმარებელი ამბობს, რომ კავშირი ცალმხრივია, და ორივე გაქრობილ პაკეტს აღწერს, ამიტომ მხოლოდ აღწერა მათ ვერ გაყოფს.
იკითხეთ, რომელმა მხარემ დაიწყო წარუმატებელი მცდელობა. ეს ერთი ფაქტი შესაძლო მიზეზების ნახევარს აცილებს.
შემდეგ შეამოწმეთ, რომ ტესტი მთელი დროის განმავლობაში ერთსა და იმავე ჰოსტებსა და სერვისს იყენებდა. ping ერთი მხრიდან და ფაილების საზიარო საქაღალდესთან კავშირი მეორე მხრიდან ორ სხვადასხვა რამეს ამოწმებს, და ჩამრთველიდან ჩატარებულმა დიაგნოსტიკამ შეიძლება აირჩიოს გვირაბის ისეთი მისამართი, რომელსაც არც ერთი მომხმარებლის ტრაფიკი არ იყენებს.
პირველი შემთხვევა: დაბრუნების გზა აკლია
დისტანციურ სერვერს, რომელიც სხვა ნაგულისხმევი ჩამრთველის გავლით პასუხობს, შეუძლია მიიღოს მოთხოვნა და პასუხი სხვაგან გადაამისამართოს. შემდეგ მდგომარეობის მიმდევარი ფაირვოლები ასიმეტრულ პასუხს ყრიან, რადგან ის დამყარებულ ნაკადს არ ემთხვევა, რაც ზუსტად ისეთი მიმართულებაა, რომელსაც არასოდეს უმუშავია. თარგმანი კიდევ ერთ ვარიანტს ამატებს: დანიშნულება ხედავს თარგმნილ წყაროს და პასუხობს მას, ამიტომ საწყისი მისამართისთვის დაწერილი წესი არასოდეს ემთხვევა.
შეამოწმეთ მისამართი, რომელსაც დანიშნულება თარგმანის შემდეგ რეალურად ხედავს, და დაბრუნების მარშრუტი სწორედ ამ მისამართისთვის, და არა საწყისი ქვექსელისთვის.
მეორე შემთხვევა: პოლიტიკამ არასოდეს დაუშვა
საპირისპირო შემთხვევა უფრო მარტივია და უფრო ხშირი, ვიდრე ჩანს: ერთი ოფისი ცენტრალურ სერვისს უნდა მოიხმაროს და არასოდეს დაიწყოს კავშირები ცენტრისკენ. ეს ასიმეტრია განზრახ მიღებული წვდომის გადაწყვეტილებაა, და გვირაბი ისე მუშაობს, როგორც დაპროექტდა. წაიკითხეთ წვდომის პოლიტიკა, სანამ გვირაბის რომელიმე პარამეტრს შეცვლით. რომელი მიმართულება იყო გათვალისწინებული, დოკუმენტი ამბობს და არა პაკეტების ჩაწერა. ჩაწერა მხოლოდ იმას გვიჩვენებს, რაც მოხდა, და არა იმას, რაც ნებადართული იყო.
თუ ორმხრივი დაწყება ნამდვილად საჭიროა, დაამატეთ კონკრეტული სერვისის ნებართვა პლატფორმის მხარდაჭერილი წესების ნაკრებით. ყველა ქვექსელის ურთიერთსანდოდ გახდომა ერთი აპლიკაციის გასწორებისთვის ვიწრო მოთხოვნას ფართო ნებართვად აქცევს, და ეს გაცვლა იშვიათად გადაიხედება შემდეგ.
შეადარეთ ადრე და შემდეგ იმავე ჰოსტებზე
დააკვირდით ერთი და იმავე მცდელობის ორივე ბოლოს და არა ორ ცალკე მცდელობას. ჩაწერეთ დამწყები ჰოსტის ჩამრთველზე და დანიშნულებაზე, შემდეგ შეადარეთ რა შემოვიდა, რა გავიდა და რომელი მისამართი ნახა შორეულმა მხარემ.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
თუ დანიშნულების ჩაწერა მოთხოვნას მოულოდნელი წყაროს მისამართით აჩვენებს, პასუხი თარგმანში ან მარშრუტიზაციაშია და არა გვირაბის უსაფრთხოების პოლიტიკაში. თუ დანიშნულება საერთოდ არ აჩვენებს მოთხოვნას, პაკეტმა დაცულ გზას არასოდეს გადაკვეთა.
შესწორების შემდეგ გაიმეორეთ იგივე ტესტი იმავე ჰოსტიდან და დაადასტურეთ, რომ დაუკავშირებელი წვდომა კვლავ უარყოფილია. გვირაბის “established” სტატუსი თავისთავად არც ერთ დასკვნას არ ადასტურებს.