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

დაიწყეთ იმ ქსელიდან, საიდანაც მოხვედით

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

გვირაბზე ხელის დაჭერამდე შეხედეთ Wi-Fi კავშირს, როუტერს და ნებისმიერ პორტალ გვერდს, რომელიც შესვლას მოითხოვს. Kill switch-მა შეიძლება ტრაფიკი დაბლოკოს გათიშულ მდგომარეობაში დიზაინის მიხედვით, ამიტომ მიჰყევით მის დოკუმენტირებულ ტესტის პროცედურას და ნუ დაასკვნით, რომ ქსელი მკვდარია. სხვა სანდო ქსელი სასარგებლო შედარებაა, და ახალი VPN გასასვლელი ვერ დაასრულებს ვადაგასულ სასტუმრო შესვლას. თუ ღია ქსელი მუშაობს და გვირაბი არა, ქსელი გამართლებულია და შემდეგი ფენა თქვენია.

გადაწყვიტეთ, ხარვეზი სახელის გარჩევაა თუ არა

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

nslookup example.com

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

სრული გვირაბი თუ მხოლოდ კომპანიის ქვექსელები

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

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

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

როცა სერვერი არაფერს გადაამისამართებს

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

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

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

შეამოწმეთ ერთი ფენა ერთდროულად

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

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

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

დაკავშირებული სტატიები