Split-tunnel დოკუმენტაციას ყოველი მარშრუტის გვერდით DNS წესი სჭირდება
მარშრუტი მისამართით წყვეტს, რეზოლვერი სახელით წყვეტს. დააფიქსირეთ ორივე ამომრჩევი თითოეული ნაკადისთვის, თითოეული ერთი ტესტით, თორემ ჩანაწერი ჩავარდება, როცა DNS შეიცვლება.
Split-tunnel-ის შენიშვნამ, რომელიც ამბობს "საოფისე ტრაფიკი VPN-ით გადის", ერთი გადაწყვეტილება დააფიქსირა და კიდევ სამი მიანიშნა. პაკეტის დონეზე მარშრუტიზაციის ცხრილი ინტერფეისს დანიშნულების მისამართით ირჩევს; სახელების დონეზე რეზოლვერი სერვერს მოთხოვნით ირჩევს, და ეს ორი არჩევანი დამოუკიდებლად კეთდება. ამიტომ სწორად დაფიქსირებულ პრეფიქსს მაინც შეუძლია შექმნას მანქანა, რომელიც შიდა სახელს საჯარო მისამართად წყვეტს, ან საერთოდ არაფერს წყვეტს, სანამ მარშრუტი სრულყოფილად გამოიყურება.
ორი ამომრჩევი, ერთი კავშირის მცდელობა
როცა აპლიკაცია უკავშირდება files.corp.example-ს, პაკეტის არსებობამდე ორი ძიება ხდება. რეზოლვერი წყვეტს, რომელი სერვერი მიიღებს მოთხოვნას, ძიების დომენების, თითოეული კავშირის მარშრუტიზაციის დომენების ან პროფილის მკაფიო წესის გამოყენებით. შემდეგ მარშრუტიზაციის ცხრილი წყვეტს, სად წავა მიღებული მისამართი, დანიშნულებასთან ყველაზე გრძელი პრეფიქსის დამთხვევის გამოყენებით.
ვერაფერი აკავშირებს ამ ორ გადაწყვეტილებას. კერძო ზონას შეუძლია უპასუხოს 10.20.4.11 მისამართით, სანამ მარშრუტიზაციის ცხრილი 10.20.0.0/16-ს გვირაბში აგზავნის, და კავშირი მუშაობს. გადაატრიალეთ რომელიმე და ის ჩავარდება ისე, როგორც მეორე: სწორი DNS პოლიტიკა პლუს დაკარგული მარშრუტი იძლევა ამოხსნილ სახელსა და დროის ამოწურვას, ხოლო სწორი მარშრუტი პლუს საჯარო რეზოლვერი იძლევა მისამართს, რომელიც სუფთად არასწორ ადგილას მარშრუტიზდება.
გაყოფილი ჰორიზონტის DNS ამას უფრო ამკვეთრებს. ერთსა და იმავე სახელს შეუძლია შიდა რეზოლვერიდან კერძო მისამართი და ინტერნეტისკენ მიმართული რეზოლვერიდან საჯარო მისამართი დააბრუნოს, ამიტომ მხოლოდ პრეფიქსის ჩამწერი შენიშვნა ვერ იწინასწარმეტყველებს, რომელ მისამართს გამოიყენებს კლიენტი რეალურად. ჩაწერეთ რეზოლვერის გზა, თორემ მისამართი ვარაუდია.
რას გამოტოვებს მხოლოდ-მარშრუტის შენიშვნა
მხოლოდ მარშრუტის ჩანაწერი უსარგებლოა split-tunnel-ის ყველაზე გავრცელებული ჩავარდნისთვის: სახელების. მომხმარებელი იტყობინება, რომ შიდა ქსელი არ იტვირთება, გვირაბი აწეულია და პრეფიქსი არსებობს. ვინც ბილეთს აიღებს, არ აქვს ჩანაწერი იმისა, რომელ რეზოლვერს უნდა ეპასუხა, არ აქვს გზა განასხვავოს არასწორი ძიების სუფიქსი დაბლოკილი სერვერისგან, და არ აქვს შედარების საწყისი ხაზი.
მეორე გამოტოვება გამონაკლისების სიაა. Split-tunnel-ის დიზაინს იმდენადვე განსაზღვრავს ის, რაც გვირაბს გარეთ რჩება, რამდენადაც ის, რაც მასში შედის, და გამორიცხული დიაპაზონები ჩვეულებრივ პირველები ტყდება, რადგან უფრო კონკრეტულ ლოკალურ მარშრუტს ან კლიენტის მხარეს ფილტრს შეუძლია განზრახვა გადაფაროს პროფილზე ხელის შეუხებლად.
მესამე გვირაბის შორეული მხარეა. კლიენტის მარშრუტი მხოლოდ პაკეტს დებს მავთულზე; კარიბჭეს მაინც უნდა გადააგზავნოს ის და ჰქონდეს დაბრუნების გზა. strongSwan-ის გადაგზავნის სახელმძღვანელო გვახსენებს, რომ კარიბჭეზე გადაგზავნისა და ფაიერვოლის წესები ფუნქციის ნაწილია, და არა სანტექნიკის, რომლის ვარაუდიც შეიძლება.
ველები, რომლებიც შენიშვნას შესრულებადს ხდის
ერთი სტრიქონი თითო ნაკადზე, ნაკადი კი არის დანიშნულება პლუს სახელი პლუს მფლობელი. ეს არის ველები, რომლებიც უძლებს რეალურ ინციდენტთან შეხებას:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"სად ცხოვრობს" სტრიქონი არის ის, რომელსაც ხალხი გამოტოვებს. სერვერის მიერ მიწოლილი პრეფიქსი, კლიენტის პროფილის მიერ დამატებული მარშრუტი და shell-ში აკრეფილი მარშრუტი ერთმანეთისგან იმით განსხვავდება, თუ ვის შეუძლია მათი შეცვლა და გადაურჩებიან თუ არა ისინი ხელახალ დაკავშირებას. ამ ველის გარეშე შემდეგი ინჟინერი ვერ იტყვის, რომელს უყურებს სამიდან.
ერთი ტესტი წესზე, და არა ერთი გვირაბზე
თითოეულ სტრიქონს ორი უვნებელი შემოწმება სჭირდება: ერთი, რომელიც მარშრუტს ცდის, და ერთი, რომელიც სახელს. მარშრუტისთვის მოითხოვეთ რაღაც, რაც გვირაბს უნდა გადასცდეს, და დაადასტურეთ გზა და არა ხელმისაწვდომობა, მაგალითად tracert -d 10.20.4.11 Windows-ზე ან ip route get 10.20.4.11 Linux-ზე. სახელისთვის ჰკითხეთ კერძო სახელს და ჩაწერეთ, რომელმა სერვერმა უპასუხა, შენიშვნაში დასახელებული რეზოლვერის წინააღმდეგ resolvectl query files.corp.example ან dig files.corp.example გამოყენებით.
დაამატეთ უარყოფითი მოლოდინიც: რა უნდა მოხდეს, როცა გვირაბი გამორთულია. VPN-ის გარეშე ბლოკირების ჩართული Android ან iOS მოწყობილობაზე გამორიცხულ აპლიკაციას შეიძლება საერთოდ არ ჰქონდეს კავშირი, ხოლო სამუშაო მაგიდის კლიენტს შეუძლია იგივე აპლიკაცია მუშაობაში დატოვოს, სანამ გვირაბი ხელახლა უკავშირდება. განზრახული პასუხის ჩაწერა "VPN-მა ჩემი აპლიკაცია დაამტვრია" გადააქცევს შესამოწმებელ განცხადებად.
შეინახეთ ჩანაწერი კონფიგურაციასთან ერთად
შეინახეთ შენიშვნა იმ პროფილის გვერდით, რომელსაც აღწერს, და მიეცით ვერსია იმავე პროფილთან. ვიკიში არსებული დოკუმენტი, რომელსაც არავინ აახლებს, ჭორია; ცხრილი იმავე საცავში, სადაც მიწოლილი მარშრუტები და რეზოლვერის პოლიტიკაა, შეიძლება განიხილოს იმავე ცვლილებაში.
როცა რაღაც ტყდება, შეადარეთ გამოყენებული მარშრუტი და ეფექტური რეზოლვერი ჩანაწერს, სანამ კიდევ ერთ გამონაკლისს დაამატებთ. სამი გავრცელებული მიზეზიდან ორი — ძველი სახელთა სივრცის წესი და აპლიკაციის პოლიტიკის გარეთ არსებული დამხმარე პროცესი — ზუსტად VPN-ის ხარვეზს ჰგავს და უხილავია, თუ შენიშვნა მხოლოდ პრეფიქსებს ჩამოთვლის.
სანამ შენიშვნას დასრულებულს უწოდებთ, დაადასტურეთ, რომ ის წერილობით პასუხობს ამათ: რომელი პრეფიქსი, რომელი მისამართების ოჯახისთვის; რომელი კერძო სახელთა სივრცე, რომელი რეზოლვერით ნაპასუხები; რომელი სახელები რჩება განზრახ საჯაროდ; სად არის თითოეული წესი კონფიგურირებული და ვის ეკუთვნის ის; და ის ერთი ბრძანება, რომელიც მარშრუტს ამტკიცებს, და ის, რომელიც სახელს ამტკიცებს. თუ რომელიმე მათგანი აკლია, შემდეგი ინციდენტი ნულიდან იქნება დიაგნოსტირებული.