TCP-ის გადატვირთვა არ ამტკიცებს, რომ თქვენი VPN დაიბლოკა

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

გადატვირთვა პაკეტია, არა განაჩენი

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

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

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

დაადასტურეთ, რომელი კავშირი გადაიტვირთა

ჯერ შეამოწმეთ, რომ აქტიური პროფილი ნამდვილად იყენებს TCP-ს. UDP გვირაბზე გადატვირთვას აზრი არ აქვს, და HTTP პროქსის ჟურნალი შეიძლება VPN-ისგან განსხვავებულ TCP ნაწილს ეხებოდეს.

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

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

შეადარეთ ბილიკის ორივე ბოლო

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

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

თვალი ადევნეთ RST სეგმენტებს ორივე მიმართულებით:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

შევიწროეთ კონტროლირებული შედარებით

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

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

შეინარჩუნეთ განსხვავება „ეს ბილიკი ვარდება“ და „ამ დასახელებულმა მოქმედმა გამოიწვია ეს“ შორის. პირველი შესამოწმებელია; მეორე ჩვეულებრივ არა ერთი კლიენტიდან.

შეამოწმეთ შესწორება ნდობის პარამეტრების შეცვლის გარეშე

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

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

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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