VPN მარშრუტის შემოწმება macOS-ზე: route get ყოველგვარი ცვლილების გარეშე

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

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

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

ფორმაა route -n get და შემდეგ მისამართი: route -n get 203.0.113.10, სადაც დოკუმენტაციის მისამართი თქვენს სამიზნეს წარმოადგენს. გამოიყენეთ ავტორიზებული დანიშნულება და შესაბამისი მისამართების ოჯახი, რადგან IPv4 პასუხი არაფერს ამბობს მხოლოდ IPv6 რესურსზე. route უტილიტის დოკუმენტაცია აღწერს get ოპერაციას და მის მიერ დაბეჭდილ ველებს.

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

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

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

სწორი მარშრუტი არ ნიშნავს მომუშავე მოთხოვნას

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

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

გამოყავით საბოლოო წერტილი და რესურსი

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

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

ჯერ წაიკითხეთ, მერე შეცვალეთ

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

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