გვირაბის /32-ის კოპირება ოფისის ქვექსელს არ დაამარშრუტებს
მისამართი, რომელსაც VPN თქვენს ადაპტერს აძლევს, აღწერს კავშირს და არა დანიშნულებას. დაამატეთ რესურსის პრეფიქსი პროფილს და ნაგულისხმევი მარშრუტი არ შეაწუხოთ.
VPN უკავშირდება, ინტერფეისი აჩვენებს მისამართს ოცდათორმეტბიტიანი ნიღბით, და ოფისის სერვერი მიუწვდომელი რჩება. შემდეგი ნაბიჯი ხშირად იმავე ნიღბის მარშრუტში ხელახლა გამოყენებაა, იმ თეორიით, რომ ინტერფეისი აღწერს, სადამდე შეიძლება მიაღწიოს გვირაბმა. არ აღწერს. ეს მისამართი აღწერს წერტილიდან წერტილამდე კავშირის ლოკალურ ბოლოს, და თქვენთვის საინტერესო დანიშნულება მის მეორე მხარეს სხვა პრეფიქსშია.
ორი განსხვავებული რამ აირია: მისამართი, რომელიც გვირაბმა მოგცათ, და ქსელი, რომელსაც მისი საშუალებით გსურთ მიაღწიოთ.
ორი მისამართი, ორი საქმე
წერტილიდან წერტილამდე გვირაბში კლიენტის მისამართი ხშირად ერთი ჰოსტის მისამართია, რადგან კავშირის მეორე ბოლოში ზუსტად ერთი პარტნიორია. არ არის საერთო სეგმენტი და არ არის ARP, ამიტომ ნიღაბი, რომელიც Ethernet-ზე აბსურდულად გამოიყურებოდა, აქ სრულიად ნორმალურია.
დანიშნულების პრეფიქსი ოფისის ქსელის ფაქტია და არა გვირაბის. თუ ერთი სერვერი გჭირდებათ, მარშრუტი ამ სერვერის ჰოსტმარშრუტია. თუ მთელი ოფისის ქვექსელი გჭირდებათ, მარშრუტი ქვექსელია. არც ერთი პასუხი ინტერფეისიდან არ იკითხება, და ერთის არჩევა იმიტომ, რომ ის გვირაბის მისამართის გვერდით გამოჩნდა, სწორედ ის გზაა, რომლითაც მომუშავე კონფიგურაცია ფუჭდება.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
ეს მესამე სტრიქონია ადგილი, სადაც ოპტიმიზმი შეწყვეტად იქცევა. მთელი კერძო დიაპაზონის გვირაბში გატარება, რომელიც მხოლოდ ერთ საიტს ემსახურება, უკავშირო ტრაფიკს უბიძგებს გზაზე, რომელსაც მისი მიწოდება არ შეუძლია, და შედეგად წარმოქმნილი ხარვეზები გატეხილ VPN-ს ჰგავს და არა ზედმეტად ფართო მარშრუტს.
აირჩიეთ პრეფიქსი მოთხოვნიდან
სანამ პროფილს შეეხებით, მოთხოვნა წინადადებად ჩაწერეთ: რომელი ჰოსტები უნდა იყოს ხელმისაწვდომი და რომელია მათ დამფარველი ყველაზე ვიწრო პრეფიქსი? ერთი სერვერი ჰოსტმარშრუტია. ქვექსელი ქვექსელის მარშრუტია. ქვექსელების დიაპაზონი შეჯამებაა, და შეჯამება არის დაპირება, რომ მის შიგნით ყველა მისამართი ხელმისაწვდომია, რაც იშვიათადაა მართალი.
შემდეგ შეამოწმეთ რიცხვი იმასთან, რასაც ოფისი რეალურად იყენებს. პრეფიქსის ჩეთის შეტყობინებიდან კოპირება საიტის მისამართების გეგმასთან დაუდასტურებლად სწორედ ის გზაა, რომლითაც მარშრუტი ისეთ ქვექსელზე მიუთითებს, რომელიც არავის ეკუთვნის.
გაითვალისწინეთ ისიც, რომ მარშრუტი გზაა და არა ნებართვა. კარიბჭე კვლავ წყვეტს, შეიძლება თუ არა თქვენმა კლიენტმა დანიშნულების გამოყენება, და სერვისს კვლავ შეუძლია უარი გითხრათ. მარშრუტის სწორად დაყენება პაკეტს იქ ამიტანს და ავტორიზაციაზე არაფერს პასუხობს.
დაამატეთ პროფილს, არასდროს შეცვალოთ ის
მარშრუტები NetworkManager-ის პროფილში მრავალმნიშვნელობიანი თვისებაა, და დაყენებასა და დამატებას შორის განსხვავება ერთი სიმბოლოა. გამოიყენეთ პლუსის ფორმა ჩანაწერის დასამატებლად და უკვე შენახულის შესანარჩუნებლად.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"პლუსის გარეშე მინიჭება მთელ სიას ცვლის. პროფილზე, რომელსაც უკვე რამდენიმე პრეფიქსი აქვს, ეს ჩუმად შლის მომუშავეებს, და სიმპტომი მოგვიანებით მოდის როგორც სერვისი, რომელიც ადრე ამ ლეპტოპიდან ხელმისაწვდომი იყო.
გამოიყენეთ UUID სახელის ნაცვლად. აღდგენის შემდეგ სახელები მეორდება, და თქვენ მიერ რედაქტირებული კავშირი შეიძლება არ იყოს ის, რომელიც თქვენს ტრაფიკს ატარებს. ჯერ შეამოწმეთ, არსებობს თუ არა იდენტური ჩანაწერი, რადგან დუბლიკატის დამატება უწესრიგოა მაშინაც, როცა უვნებელია.
ეს მარშრუტის თვისებების ცნობარი დაამართლებს დანიშნულებას, არასავალდებულო შემდეგ ნახტომს, მეტრიკას და ატრიბუტების სინტაქსს დაყენებული ვერსიისთვის. წაიკითხეთ იგი შემდეგი ნახტომის დამატებამდე, რადგან საჭიროა თუ არა ის, დამოკიდებულია ინტეგრაციასა და ტოპოლოგიაზე, და ინტერფეისების სიის პირველი მისამართიდან ამის გამოცნობა მეთოდი არ არის.
ნაგულისხმევი მარშრუტი და DNS ცალკე გადაწყვეტილებებია
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
ავტომატური მარშრუტები არის სხვა რამ, რაც უყურადღებოდ არ უნდა შეაწუხოთ. მათი ჩახშობა ერთი დაკარგული ჩანაწერის გადასაჭრელად შეიძლება რამდენიმე მომუშავეს მოხსნას, და ვინც ეს შემოგვთავაზა, ჩვეულებრივ სხვა push-ებით სხვა პროფილს უყურებდა.
DNS-ს თავისი გზა და თავისი ხარვეზები აქვს. სახელი, რომელიც არასწორი გადამწყვეტის მეშვეობით სწორ მისამართზე გვარდება, ან გადამწყვეტი, რომელსაც კერძო ზონაზე პასუხი არ შეუძლია, მარშრუტიზაციის პრობლემად გამოჩნდება მაშინ, როცა მარშრუტი სრულყოფილია. გამოსცადეთ მისამართი და სახელი ცალ-ცალკე, შემდეგ გადაწყვიტეთ, რომელი ფენა რეალურად ჩავარდა.
შეამოწმეთ, რა იქნა გამოყენებული
შენახული ცვლილება გამოყენებული ცვლილება არ არის. ხელახლა დაუკავშირდით მენეჯერის მხარდაჭერილი სასიცოცხლო ციკლით, შემდეგ შეხედეთ მიზნობრივი დანიშნულების ფაქტობრივ მარშრუტს და იმ პოლიტიკის წესებს, რომლებიც წყვეტს, რომელი ცხრილი იკითხება.
თუ პრეფიქსი იქ არის და კავშირი მაინც ვერ მუშაობს, თქვენ სხვა პრობლემაზე გადახვედით: წყაროს მისამართის არჩევა, დაბრუნების მარშრუტი შორეულ ბოლოში, ან სერვისი, რომელიც თქვენს კლიენტს უარს ეუბნება. თითოეული მათგანი უკეთესი ადგილია საყურებლად, ვიდრე უკვე გასწორებული პროფილი.