Mac-ის L2TP გაყოფილი მარშრუტები: რატომ არ მუშაობს ჰოსტის მისამართი

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

დანიშნულება ქსელის მისამართია, ნიღაბი პრეფიქსს აღწერს

networksetup -setadditionalroutes იღებს დანიშნულების, ქვექსელის ნიღბისა და კარიბჭის სამეულებს. გამოძახება, რომელიც ერთ შიდა ქვექსელს გვირაბით აგზავნის, ასე გამოიყურება:

sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0

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

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

როცა ზუსტად ერთი ჰოსტი გსურთ, გამოიყენეთ ჰოსტის მისამართი 255.255.255.255 ნიღაბთან. შერეული წყვილებია ის ადგილი, სადაც ეს ფუჭდება და არა ჰოსტის მისამართის გამოყენება როგორც ასეთი. ერთი მისამართიდან აგებული /32 ლეგიტიმური მარშრუტია; ერთი მისამართიდან აგებული /24 შეცდომაა.

გამოძახება ცვლის სიას, და სახელი პირდაპირია

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

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

networksetup -listallnetworkservices

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

როცა პროფილი ნაგულისხმევ მარშრუტს ითხოვს

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

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

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

PPP გვირაბებს გასაღების ნაცვლად კაუჭი სჭირდება

PPP-ზე დაფუძნებული გვირაბებისთვის defaultroute არის პროფილის გასაღები, რომელიც ნაგულისხმევ მარშრუტს ქმნის; ამოიღეთ ის და კლიენტი შეწყვეტს ყოველი დანიშნულების მოთხოვნას. შემდეგ მარშრუტები ემატება ინტერფეისის გამოჩენის შემდეგ, ჩვეულებრივ /etc/ppp/ip-up-დან:

#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0

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

შეამოწმეთ გაყოფა სამი მოთხოვნით

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

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

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