რატომ route-nopull მარტო ტოვებს ფაილურ სერვერს მიუწვდომელს
მიყოლებული მარშრუტების იგნორირება გაყოფილი გვირაბის მხოლოდ ნახევარია. აირჩიეთ მარშრუტის მფლობელი, ხელით დაამატეთ ოფისის პრეფიქსი და სამი ნაკადი შეამოწმეთ, სანამ გამოსწორებულს უწოდებთ.
ფაილური სერვერი კარგად იხსნება და მეზობელ ფანჯარაში ვიდეოზარი ჭედვას იწყებს. არაფერი არ არის ნელი და არც ერთი MTU არ არის არასწორი: თქვენმა კლიენტმა მიიღო სერვერის მიერ მოცემული მარშრუტების სია, ამიტომ ყოველი პაკეტი ახლა ოფისის firewall-იდან გადის. გამოსწორება არ არის კიდევ ერთი მოწყობის დროშა, არამედ გადაწყვეტილება იმაზე, ვის ეკუთვნის კლიენტის მარშრუტების ცხრილი. ეს გადაწყვეტილება ერთ ადგილს ეკუთვნის და ქვემოთ მოცემული მარცხის რეჟიმები გეუბნებიან, რომელი ადგილი აირჩიეთ სინამდვილეში.
გადაწყვიტეთ, ვის ეკუთვნის მარშრუტების ცხრილი
სამი მფლობელი შესაძლებელია. სერვერს შეუძლია მარშრუტებისა და ნაგულისხმევი კარიბჭის გაგზავნა, ამ შემთხვევაში კლიენტი აყენებს ყველაფერს, რასაც ეუბნებიან, და სრული გვირაბი ხდება. კლიენტის პროფილს შეუძლია მფლობელობა აიღოს გაგზავნილი მნიშვნელობების უარყოფით და საკუთარი მარშრუტის სტრიქონების ტარებით. სამუშაო მაგიდის კავშირის მენეჯერსაც შეუძლია გადაწყვეტილების ფლობა საკუთარი მარშრუტისა და ნაგულისხმევი მარშრუტის თვისებებით.
ყოველი არჩევანი განსხვავებულად მარცხდება, ამიტომ ღირს ცხრილის წაკითხვა პროფილის რედაქტირებამდე. სტრიქონი, რომელიც თქვენს სიმპტომს ემთხვევა, არის მფლობელი, რომელიც რეალურად გაქვთ.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
აირჩიეთ ერთი და ჩაწერეთ. ორის შერევა ტოვებს ჰოსტს, რომლის ნაგულისხმევი გზა ეწინააღმდეგება მისსავე დოკუმენტაციას, და შემდეგი ინჟინერი ვერ გაიგებს, რომელმა დონემ მოიგო. წაშალეთ წაგებული ცალსახად.
route-nopull ფილტრავს გაგზავნილებს, ის არ ამატებს მარშრუტებს
route-nopull კლიენტის პროფილს ეკუთვნის და მისი რიგი ამ ფაილში მნიშვნელობას არ იძენს, რადგან ის მხოლოდ სერვერიდან მომავალ მნიშვნელობებს უგდებს. ის უგდებს გაგზავნილ მარშრუტებს, მათ შორის გაგზავნილ ნაგულისხმევ მარშრუტს, მაშინ როცა გვირაბი მაინც ჩვეულებრივად ადის.
შედეგი, რომელსაც ხალხი გამოტოვებს, არის ის, რომ გაგზავნილი DHCP პარამეტრები მათთან ერთად მიდიან. სერვერის მიერ გაგზავნილი DNS პარამეტრებიც უგდება, ამიტომ შიდა სახელები წყვეტენ გადაწყვეტას, თუმცა გვირაბი ჯანსაღია და სერვერი მისამართით ხელმისაწვდომია.
ეს ტოვებს გვირაბს ოფისის პრეფიქსამდე გზის გარეშე, თუ თქვენ თვითონ არ დაამატებთ ერთს: route-nopull და შემდეგ route 10.30.0.0 255.255.0.0 იმავე პროფილში. ეს სტრიქონი ატარებს მისამართსა და ნიღაბს; ის არ ასახელებს შემდეგ ნახტომს.
ალტერნატიული ფორმა ამატებს კარიბჭის ტოკენს, route 10.30.0.0 255.255.0.0 vpn_gateway, რომელიც ჩანაწერს სახელით გვირაბისკენ მიმართავს. იმპორტიორები განსხვავდებიან იმაში, თარგმნიან თუ არა ამ ვარიანტს, ამიტომ შეამოწმეთ შენახული კავშირი, თუ ჩანაწერი ბირთვის ცხრილში აკლია.
შეამოწმეთ მარშრუტის ძიებით, არა ping-ით
ping გეუბნებათ, რომ რაღაცამ უპასუხა. მარშრუტის ძიება გეუბნებათ, რომელ ინტერფეისს აირჩევდა ბირთვი, და ეს არის ის კითხვა, რომელიც რეალურად დასვით. ოთხი მოკლე ბრძანება გამოყოფს დაკარგულ მარშრუტს არასწორ მოწყობილობაზე მიმთითებელი მარშრუტისგან.
წაიკითხეთ, რა დააყენა გვირაბმა ip route show dev tun0-ით. გამოსავლის სრული არარსებობა ნიშნავს ნულ მარშრუტს, რაც მუშა გაყოფილი გვირაბი არ არის, და ეს არის ფილტრის ცალსახა სტრიქონის გარეშე დამატების ჩვეულებრივი შედეგი.
შემდეგ შეამოწმეთ ერთი ოფისის მისამართი ip route get 10.30.5.7-ით და ერთი ჩვეულებრივი ინტერნეტის მისამართი ip route get 1.1.1.1-ით. მეორემ უნდა დაასახელოს ფიზიკური ინტერფეისი; თუ გვირაბს ასახელებს, გაგზავნა საერთოდ არ გაფილტრულა.
ბოლოს წაიკითხეთ ip rule, რადგან წინა ცდის მიერ დატოვებულმა პოლიტიკის წესმა შეიძლება გადაფაროს ცხრილი, რომელიც ახლახან გაასწორეთ. სწორი პროფილი ზემოდან მოძველებული წესით ზუსტად გატეხილ პროფილს ჰგავს. წაშალეთ ბოლო ჯერზე დამატებული წესი, სანამ სხვას დაამატებთ.
გადამფარავი ქვექსელები გატეხილ გვირაბს ჰგავს
ორი კერძო დიაპაზონი შეიძლება იდენტური იყოს კლიენტის თვალსაზრისით, და სწორედ იქ ადანაშაულებენ გაყოფილ გვირაბს იმაში, რაც მან არ გამოიწვია. თუ ოფისი იძლევა იმავე პრეფიქსს, რომელსაც თქვენი სახლის როუტერი იყენებს, გვირაბის მარშრუტი ფარავს როუტერს და სახლის ქსელი თითქოს ქრება.
შეადარეთ თქვენს ინტერფეისზე არსებული მისამართი პროფილის მიერ დაყენებულ მარშრუტს, ჩვეულებრივი მისამართების სიის გამოყენებით, სანამ რამეს შეცვლით. გადაფარვა რეალურია და არც ერთი პროფილის პარამეტრი არ ხსნის მას. რაც შეგიძლიათ გაასწოროთ, სახელდებაა, რათა შემდეგმა ადამიანმა ორი დიაპაზონი დაინახოს და არა ერთი.
პატიოსანი გამოსწორებებია ერთი მხარის გადანომრვა ან ოფისში მისამართების თარგმნა. ერთი ჰოსტის მარშრუტის როუტერზე მიმაგრება მუშაობს მანამ, სანამ როუტერის მისამართი შეიცვლება, და შემდეგ ის პირველის ზემოთ მეორე საიდუმლო ხდება.
გახადეთ გადაწყვეტილება გადამძლევი ხელახალი დაკავშირების მიმართ
ხელით აკრეფილი ჩანაწერები ვერ გადაურჩება ხელახალ დაკავშირებას, და კავშირის მენეჯერი ცხრილს ყოველ ჯერზე თავიდან აშენებს, როცა პროფილი იწყება. მოათავსეთ გადაწყვეტილება იქ, სადაც კავშირი იქმნება, იქნება ეს პროფილი თუ მენეჯერის შენახული პარამეტრები. შემდეგ ერთხელ განზრახ გადატვირთეთ კავშირი, ნაცვლად იმისა, რომ ქცევა ზარის დროს აღმოაჩინოთ. პროფილი, რომელიც მუშაობს მხოლოდ შემდეგ ხელახალ დაკავშირებამდე, დაუმთავრებელია.
ივარჯიშეთ სამ გზაზე ერთდროულად: ოფისის ჰოსტი ლიტერალური მისამართით, იგივე ჰოსტი სახელით და ჩვეულებრივი საჯარო საიტი. შუა დამოკიდებულია იმ სახელების სერვისზე, რომელიც გაგზავნილი DNS პარამეტრების მოშორების შემდეგ დააყენეთ, და სწორედ ის მარცხდება ჩუმად.