route-gateway არ არის redirect-gateway: რა იცვლება სინამდვილეში
ეს პარამეტრი მხოლოდ შემდეგ ნახტომს აძლევს იმ მარშრუტებს, რომლებსაც OpenVPN აყენებს. მისი წაშლა არ თიშავს გაგზავნილ სრულ გვირაბს და შესწორება გადამისამართებაშია.
თქვენი გვირაბი ამოდის, პირადი ქვექსელი პასუხობს და ჩვეულებრივი დათვალიერება მაინც ქრება VPN-ში, მიუხედავად იმისა, რომ ვინმემ პროფილიდან კარიბჭის ხაზი წაშალა. ეს კომბინაცია არასწორი დირექტივის რედაქტირების ანაბეჭდია. წაშლილი აძლევდა კლიენტს შემდეგ ნახტომს იმ მარშრუტებისთვის, რომლებსაც ის აყენებს; რაც ტრაფიკის დაჭერას აგრძელებდა, სხვა ადგილიდან მოვიდა და სერვერმა გაგზავნა. დაფარვა და შემდეგი ნახტომი ცალკე საქმეებია და მათგან მხოლოდ ერთი წყვეტს, იყენებენ თუ არა საჯარო დანიშნულებები გვირაბს.
წაშლილი სტრიქონი შემდეგი ნახტომი იყო, არა პოლიტიკის გადამრთველი
ყოველ მარშრუტს, რომელსაც კლიენტი აყენებს, სჭირდება კარიბჭის მისამართი მისათითებლად, და კარიბჭის დირექტივა არის ამ მისამართის წყარო, როცა მარშრუტი თავად არ ასახელებს არცერთს. წაშალეთ ის და ამ მარშრუტებს ჩამოკიდების ადგილი არ ექნებათ, ამიტომ ისინი ან არ დამონტაჟდებიან, ან გზაზე დაეშვებიან, რომელიც არსად მიდის. პირადი ქვექსელი ზუსტად ის არის, რასაც ასეთი მარშრუტი გადაჰქონდა.
ამასობაში გადარჩენილ ქცევას სხვა ავტორი ჰყავს: გადამისამართების პარამეტრი გაგზავნილ ბლოკში, რომელიც ჩვეულებრივ გამავალ ტრაფიკს გვირაბში გადააქვს თავისი დროშების მიხედვით. კარიბჭის წაშლა არც თიშავს და არც ასუსტებს მას. შედეგი ორივე მდგომარეობიდან ყველაზე ცუდია: საჯარო ტრაფიკი კვლავ იჭერთ და გვირაბის გამართლებული პირადი დანიშნულება ახლა მიუწვდომელია. ამიტომ იმავე სულისკვეთებით გაკეთებული მეორე რედაქტირებაც არაფერს ცვლის.
ოთხი ბერკეტი, ოთხი განსხვავებული საქმე
ამ განხილვაში ოთხი დირექტივა მონაცვლეობით ციტირდება და მათგან მხოლოდ ერთი მართავს დაფარვას, ანუ იმას, თუ რომელი დანიშნულებები გადიან გვირაბში. მეორე ადგენს შემდეგ ნახტომს, რომელსაც მარშრუტები იყენებენ, მესამე აყენებს ერთ პრეფიქსს, ხოლო მეოთხე აგდებს ყველაფერს, რაც სერვერმა გაგზავნა, მათ შორის განლაგებისთვის საჭირო პირად მარშრუტებს. ცხრილი ალაგებს მათ იმის მიხედვით, თუ რისი შეცვლა სურს ადმინისტრატორს და არა სახელის მიხედვით, რადგან სწორედ სახელები იწვევს დაბნეულობას. მოექეცით მათ როგორც ოთხ ცალკეულ გადაწყვეტილებას და აირჩიეთ ის, რომლის უკუქცევაც ნამდვილად გსურთ.
პრაქტიკაში ოთხივე ხშირად ერთ გაგზავნილ ბლოკში მოდის, სტრიქონი სტრიქონის შემდეგ, რაც მათ ერთი პარამეტრის ნაწილებად აჩენს. ასე არ არის და OpenVPN-ის ცნობარი სწორედ ამიტომ აღწერს მათ როგორც განსხვავებულ მექანიზმებს. იმის გარკვევა, თუ რომელ გადაწყვეტილებას აბრუნებთ, საქმეა; რედაქტირება ერთი სტრიქონია.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
გაფილტრეთ გაგზავნილი სტრიქონი, შეინარჩუნეთ შემდეგი ნახტომი
თუ დაფარვა, რომლის წინააღმდეგაც მიდიხართ, გაგზავნილი პარამეტრის სახით მოდის, ვიწრო პასუხია ამ პარამეტრის სახელით უგულებელყოფა და გაგზავნილი ბლოკის დანარჩენის ხელუხლებლად დატოვება. ფილტრად დაწერილი ის ქვემოთ მოცემულ სტრიქონს ჰგავს და მისი ადგილი დაზარალებული კლიენტის პროფილშია, არა სერვერის კონფიგურაციაში.
pull-filter ignore "redirect-gateway"სივიწროვეა არსი. რადგან ფილტრი ტექსტურ პრეფიქსს ადარებს, უფრო მოკლე ნიმუში შემდეგი ნახტომის დირექტივასაც ემთხვევა, რაც ზუსტად იმ ინფორმაციას აცლის, რაზეც პირადი მარშრუტებია დამოკიდებული და ორიგინალურ შეცდომას ახალ სამოსში იმეორებს. ფილტრი ასევე მხოლოდ გაგზავნილ პარამეტრებზე მოქმედებს, ამიტომ არასოდეს ეხება ადგილობრივად დაწერილ ან ქსელის მენეჯერის მიერ დაკისრებულ ეკვივალენტურ სტრიქონს. ამის შემდეგ ხელახლა დაუკავშირდით, რადგან ცოცხალი სესია ხელახლა არ აფასებს იმას, რაც სერვერმა გაგზავნა.
წაიკითხეთ ძიება და არა ცხრილი
პროფილის ხელახლა ჩატვირთვის შემდეგ ჰკითხეთ ბირთვს, სინამდვილეში სად წავა ორი დანიშნულება: ერთი პირადი პრეფიქსის შიგნით და ერთი საჯარო ინტერნეტში. ძირითადი ცხრილის სრული გამონაბეჭდი უფრო ძნელად იკითხება და უფრო ადვილად იკითხება არასწორად, რადგან მარშრუტი შეიძლება არსებობდეს და მაინც წააგოს უფრო კონკრეტულ დამთხვევასთან. პოლიტიკაზე დაფუძნებულ მარშრუტიზაციაში წესი, ცხრილი და წყაროს მისამართიც შემოწმების ნაწილია.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 ვარიანტი გაცნობას იმსახურებს, რადგან ძველ ნაგულისხმევ ჩანაწერს ხილულს ტოვებს, სანამ ნახევრად ნაგულისხმევთა წყვილი იგებს ძიებას. ამიტომ გამოსავალში 0.0.0.0/0 სტრიქონი თავისთავად არაფერს ამტკიცებს. ძიება პასუხობს კითხვას, რომელზეც სია მხოლოდ თითქოს პასუხობს.
DNS, IPv6 და პირადი მარშრუტი კვლავ უნდა მუშაობდეს
IPv4-ის ერთი გადამისამართების უარყოფა არაფერს ამბობს გადამწყვეტზე, ამიტომ გაგზავნილ DNS პარამეტრს შეუძლია გააგრძელოს მოთხოვნების გვირაბში გაგზავნა, სანამ მარშრუტები სწორად გამოიყურება. IPv6-ის ნაგულისხმევი იგივეს გააკეთებს იმ მისამართების ოჯახისთვის, რომელსაც IPv4-ის შემოწმება არასოდეს შეხებია. ორივეს ცხადი გადაწყვეტილება სჭირდება და არა ვარაუდი. შემდეგ დაადასტურეთ, რომ პირადი სერვისი კვლავ პასუხობს, რადგან პირადი მარშრუტი დაკარგული გაყოფილი გვირაბი არ არის გაყოფილი გვირაბი, ის გატეხილია.
ერთი უფრო ფართო ინსტრუმენტი გაფრთხილებას იმსახურებს: route-nopull აგდებს ყველა გაგზავნილ მარშრუტს და ყველა გაგზავნილ DNS პარამეტრს, რაც დანამდვილებით აჩერებს სრულ გვირაბს და ისევე დანამდვილებით ამტვრევს პირად მარშრუტებს, რომლებზეც განლაგებაა დამოკიდებული, ამიტომ ეს გაცილებით დიდი ჩაქუჩია, ვიდრე ერთ პარამეტრზე დამიზნებული სახელის ფილტრი. ნებისმიერი ცვლილების შემდეგ შეამოწმეთ პირადი დანიშნულება, საჯარო დანიშნულება და გადამწყვეტი, და დასრულებული ხელის ჩამორთმევა ჩათვალეთ მტკიცებულებად მხოლოდ ხელის ჩამორთმევისა.