რატომ არ აღწევს route -interface ბმულის გარეთ მდებარე ჰოსტს

route იღებს Wi-Fi ინტერფეისის სახელს, გამოდის ჩივილის გარეშე და ჰოსტი მიუწვდომელი რჩება. არაფერი დაზიანებულა; კავშირი მარშრუტში უბრალოდ არასწორია: ინტერფეისის დროშა ამბობს, რომელ ბმულზეა დანიშნულება და არა რომელმა როუტერმა უნდა მიიღოს ტრაფიკი სხვაგან მდებარე დანიშნულებისთვის. ბრძანება წარმატდება, რადგან სინტაქსურად სწორია და არა იმიტომ, რომ მუშა გზას აღწერს.

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

ინტერფეისი გასასვლელია, შემდეგი ნაბიჯი გადაცემაა

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

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

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

რას ამტკიცებს ინტერფეისის დროშა სინამდვილეში

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

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

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

მარშრუტი, რომელიც ბმულის გარეთ დანიშნულებას სჭირდება

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

macOS-ში მხოლოდ-კითხვითი შემოწმება route -n get 198.51.100.25-ია. წაიკითხეთ კარიბჭის და ინტერფეისის სტრიქონები ერთად და შეამოწმეთ, რომ კარიბჭე ის მისამართია, რომელსაც Mac ნამდვილად აღწევს. კარიბჭე სხვა ქვექსელში, ან ის, რომელიც ბოლო ქსელური ცვლილების შემდეგ გაქრა, ქმნის მარშრუტს, რომელიც სწორად გამოიყურება და არაფერს გადასცემს.

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

წაიკითხეთ მიმდინარე არჩევანი სანამ შეცვლით

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

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

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

გვირაბები და პოლიტიკა ცვლის ფორმას

წერტილ-წერტილ ინტერფეისები საკუთარი შემთხვევაა. გვირაბს შეუძლია მარშრუტი ატაროს Ethernet სტილის კარიბჭის მისამართის გარეშე და ეს ავტომატურად არასწორი არ არის. გამოიყენეთ ინტერფეისის რეალური ბმულის მოდელი და ნუ გაავრცელებთ Wi-Fi მაგალითს ყველა ნანახ ცხრილის ჩანაწერზე.

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

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