შეინარჩუნეთ კერძო მარშრუტები და მოიშორეთ გადამისამართება: OpenVPN-ის გაყოფილი გვირაბი
მხოლოდ კერძო ქსელებისთვის განკუთვნილ გვირაბს ორი წესი სჭირდება: კერძო პრეფიქსები მასში გადის, ჩვეულებრივი დათვალიერება თავის ლოკალურ გზას ინარჩუნებს. ნაგულისხმევი მარშრუტის წაშლა პოლიტიკა არ არის.
გვირაბი ადის, აპლიკაცია იტვირთება და შემდეგ ლეპტოპზე ყველაფერი დანარჩენი უცნაურად იწყებს ქცევას. ეს არის ერთი ხაზის წაშლით განხორციელებული მხოლოდ კერძო პოლიტიკის ჩვეულებრივი სახე. გაგზავნილი ნაგულისხმევი მარშრუტის მოცილება ნამდვილად ცვლის, სად მიდის ტრაფიკი, მაგრამ არ ამბობს, სად უნდა წავიდეს ტრაფიკი სამაგიეროდ, და სახელების გარჩევას საერთოდ არ ეხება. პოლიტიკას ორი დადებითი ნახევარი სჭირდება, სანამ მისი შემოწმება იქნება შესაძლებელი.
გადამისამართების წაშლა ცვლილების მხოლოდ ნახევარია
სრული გვირაბის გადამისამართება და მხოლოდ კერძო პოლიტიკა იმით განსხვავდება, თუ რას აცხადებენ ისინი სამყაროზე. გადამისამართება ყველა დანიშნულებას ითხოვს, ხოლო კერძო პოლიტიკა სიას ითხოვს და დანარჩენს მარტო ტოვებს. სიის დაუწერად მოთხოვნის წაშლა ქმნის კლიენტს, რომელიც ლოკალური ქსელის გარეთ არსად აღწევს, რაც მარშრუტიზაციის ჩავარდნას ჰგავს და არა პოლიტიკის ხარვეზს. დაწერეთ სია მოთხოვნის მოხსნამდე, და მაშინ ამ ორი ნაბიჯის რიგითობას აღარ ექნება მნიშვნელობა.
ორივე ნახევარი მოთხოვნაა და არა ნაგულისხმევი. კერძო პრეფიქსები გვირაბში უნდა შევიდეს, ხოლო ჩვეულებრივმა დანიშნულებებმა ის გზა უნდა შეინარჩუნოს, რაც მათ კავშირამდე ჰქონდათ.
თუ ორგანიზაცია სრულ გვირაბს ავალდებულებს, აქედან არაფერი ვრცელდება. მხოლოდ კერძო კონსტრუქცია ეკუთვნის იმ განლაგებებს, სადაც გაყოფილი მარშრუტიზაცია დამტკიცებულია.
pull-filter შესაბამისობაა და არა გადამრთველი
pull-filter ინსტრუქცია შლის გაგზავნილ პარამეტრებს, რომელთა სახელებიც პრეფიქსს ემთხვევა, და ეს არის ყველაფერი, რასაც აკეთებს. გადამისამართების უგულებელყოფა ყველა სხვა გაგზავნილ პარამეტრს ადგილზე ტოვებს, რაც ჩვეულებრივ სწორედ ის არის, რაც გსურთ: მარშრუტები, DNS-ის პარამეტრები და მარშრუტის კარიბჭის მნიშვნელობა მაინც აღწევს. მას ასევე არ შეუძლია ლოკალურ პროფილში დაწერილი ინსტრუქციის მოხსნა, რადგან ფილტრაცია ეხება იმას, რასაც სერვერი აგზავნის.
წინააღმდეგობა გაუწიეთ ცდუნებას, უგულებელყოთ route-ით დაწყებული ყველა პარამეტრი. ეს ნიმუში ასევე აგდებს კავშირისთვის საჭირო კერძო მარშრუტებს და შეიძლება დაკარგოს კარიბჭის ინფორმაცია, რაზეც გვირაბია დამოკიდებული.
route-nopull უფრო ფართო გადაწყვეტილებაა, ვიდრე ჩანს. ის ხელს უშლის კლიენტს მიიღოს გაგზავნილი მარშრუტები და DHCP-ის სტილის პარამეტრები ჯგუფურად, რაც განსხვავდება ერთი პარამეტრის გაფილტვრისგან.
მარშრუტების სია დაწერეთ აპლიკაციიდან გარეთ
დაიწყეთ იმით, რასაც მომხმარებელი ნამდვილად ხსნის, შემდეგ დაამატეთ დამხმარე ნაწილები. აპლიკაცია 10.60.20.15 მისამართზე გულისხმობს თავის ქვექსელს 10.60.0.0/16, ხოლო კერძო სახელი გულისხმობს გამხსნელს, რომელიც მას პასუხობს. ამიტომ ერთი აპლიკაციის მომთხოვნ მომხმარებელს ორი დანიშნულება და ერთი DNS გადაწყვეტილება სჭირდება. ამ სიის მიღმა ყველაფერი კონსტრუქციით სცილდება ფარგლებს, და სწორედ ეს ინარჩუნებს პოლიტიკას გადასამოწმებლად.
თანამშრომლობით სერვერზე ეს ორ გაგზავნილ მარშრუტად იქცევა და არც ერთი მათგანი გადამისამართება არ არის. შეინარჩუნეთ გვირაბის ტოპოლოგია და მარშრუტის კარიბჭის მნიშვნელობები, რომლებსაც არსებული სერვისი გვაძლევს.
როცა ეს პოლიტიკა მხოლოდ ზოგიერთ მომხმარებელს სჭირდება, გამოიყენეთ ის კლიენტის ან ჯგუფის მიხედვით. ყველას მარშრუტიზაციის შეცვლა ერთი გუნდის მოთხოვნის გამოსასწორებლად ის გზაა, რომლითაც გაყოფილი გვირაბი შეფერხებად იქცევა.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
მიეცით DNS-ს იგივე გზა
გამხსნელამდე მიმავალი მარშრუტი გამხსნელის პოლიტიკა არ არის. systemd-resolved კლიენტზე სემანტიკური შედეგია კერძო სახელთა სივრცის მარშრუტიზაციის დომენი, რომელიც შიდა გამხსნელზე მიუთითებს, და სწორედ ეს იწვევს იმას, რომ მხოლოდ ის სახელები იყენებენ მას. Windows-ის კლიენტს სამაგიეროდ საკუთარი სახელთა სივრცის პოლიტიკის მექანიზმი სჭირდება. პროფილში DNS სერვერის ხაზი თავისით არც ერთს არ აყენებს.
შეამოწმეთ, რა აირჩია ოპერაციულმა სისტემამ და არა რა მოითხოვა პროფილმა. Linux-ზე resolvectl status აჩვენებს დომენს და სერვერს თითოეული კავშირისთვის, Windows-ზე სახელთა სივრცის პოლიტიკის ცხრილი ეკვივალენტური მტკიცებულებაა.
შეინარჩუნეთ გამხსნელი მისაწვდომი გვირაბის გავლით, თორემ პოლიტიკა მიუთითებს მისამართზე, რომლის გამოკითხვაც შეუძლებელია. გამხსნელის მისამართი, რომელსაც გვირაბი ვერ აღწევს, მუშა პოლიტიკას დროის ამოწურვად აქცევს.
გადაამოწმეთ ორივე ნახევარი ხელახალი დაკავშირებისას
ცვლილების შემდეგ ხელახლა დააკავშირეთ კლიენტი და შეამოწმეთ ეფექტური მარშრუტი კერძო და საჯარო მისამართამდე. შემდეგ გადაწყვიტეთ კერძო სახელი და საჯარო სახელი და დარწმუნდით, რომ თითოეულმა გამოიყენა განკუთვნილი გამხსნელი. საჯარო ვებსაიტის ჩატვირთვა მხოლოდ მეორე ნახევარს ამტკიცებს, და სწორედ ეს ნახევარი მუშაობს ჩვეულებრივ შემთხვევით.
ჩაწერეთ დასრულებული პოლიტიკა ერთი წინადადებით: ეს პრეფიქსები და სახელები იყენებენ ამ კავშირს, დანარჩენი ყველაფერი მიჰყვება ლოკალურ გზას. შემდეგ შეინახეთ ის პროფილში, ნაცვლად იმისა, რომ ყოველი შესვლის შემდეგ ადაპტერის პარამეტრები შეაკეთოთ.