დომენზე დაფუძნებული VPN მარშრუტიზაცია IP მარშრუტების წინააღმდეგ: რომელია შესაფერისი?
ჰოსტის სახელი გაყოფილი გვირაბის ველში მარშრუტი არ არის. შეადარეთ დომენის წესები და ცხადი პრეფიქსები განახლების, ქვედომენების ფარგლებისა და DNS-ის შეცვლისას მომხდარის მიხედვით.
IP მარშრუტი ემთხვევა მისამართის პრეფიქსს და ბირთვი მას დამატებითი კითხვების გარეშე იყენებს. დომენზე დაფუძნებული VPN წესი ემთხვევა სახელს, რაც ნიშნავს, რომ სტეკში რაღაცამ უნდა გადაწყვიტოს, რომელ მისამართებს ნიშნავს ეს სახელი ახლა და ეს გადაწყვეტილება აქტუალურად შეინარჩუნოს. ეს სხვადასხვა მექანიზმია სხვადასხვა წარუმატებლობის რეჟიმით და გამყიდველები ორივესთვის ერთსა და იმავე სიტყვას იყენებენ. მათი შედარება ფუნქციების სიებში არსს გამოტოვებს; შეადარეთ ისინი იმის მიხედვით, რა ხდება, როცა პასუხი იცვლება.
სასარგებლო დაყოფა არის წესს შორის, რომელიც წყვეტს, და წესს შორის, რომელიც არ წყვეტს.
რას ემთხვევა სინამდვილეში თითოეული წესი
პრეფიქსის წესი ემთხვევა მარშრუტიზაციის ცხრილში დანიშნულების მისამართებს. არაფერი წყდება, არაფერი იწურება და დამთხვევა ზუსტია ყოველი პაკეტისთვის. დომენის წესი ემთხვევა აპლიკაციის მოთხოვნას სახელზე, რომელსაც RFC 1034 განსაზღვრავს როგორც ლეიბლების ხეს და არა მისამართს. ზოგი პროდუქტი სახელს ერთხელ წყვეტს და მიღებულ მისამართებს მარშრუტებად აყენებს, რაც წესს აქცევს IP წესად დამატებული განახლების ტაიმერით.
სანამ გამართავთ, გაარკვიეთ, რომელი გაქვთ ამ ორიდან, რადგან წარუმატებლობა ყოველ შემთხვევაში სრულიად განსხვავებულად გამოიყურება.
სად ცხოვრობს დომენის წესი სტეკში
თუ პროდუქტი დომენის წესებს ახორციელებს ლოკალური პროქსის მეშვეობით, ტრაფიკმა უნდა მიაღწიოს ამ პროქსის, და აპლიკაციები, რომლებიც სისტემურ პროქსის უგულებელყოფენ, მთლიანად გვერდს უვლიან წესს. თუ ისინი ხორციელდება სახელების წყვეტით და მარშრუტების დამატებით, მისამართები ისეთივე ახალია, როგორც ბოლო განახლება. თუ ის ჩამოკიდებულია გამხსნელზე, DNS-ის ქცევა მარშრუტიზაციის პოლიტიკის ნაწილი ხდება და სარეზერვო გამხსნელს შეუძლია ჩუმად გააუქმოს იგი.
წაიკითხეთ გამყიდველის მოდელი და არა პარამეტრის იარლიყი. ორ კლიენტს Split Tunnel-ის სახელწოდების ველით შეიძლება სამი სხვადასხვა რამ აკეთებდეს.
შეადარეთ რა ფუჭდება
სამი რამ სხვადასხვანაირად ფუჭდება. მისამართების ცვლა: CDN-ის ჰოსტის სახელი შეიძლება წუთებში გადაიჭრას მისამართების სხვა ნაკრებში, ამიტომ კოპირებული სია სწრაფად ძველდება. ქვედომენების ფარგლები: example.com-ის წესი შეიძლება მოიცავდეს api.example.com-ს ან არა, და დოკუმენტაცია ჩვეულებრივ ცხადად ამბობს, რომელია. წყვეტის წარუმატებლობა: როცა გამხსნელი ფუჭდება, წყვეტი კლიენტი შეიძლება დაბრუნდეს ტრაფიკის გვირაბირებაზე ან მის პირდაპირ გაგზავნაზე.
მხოლოდ მეორეა კონფიგურაციის კითხვა. დანარჩენი ორი დიზაინის კითხვაა იმაზე, რამდენად მზადაა პროდუქტი გამოიცნოს.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
როცა პრეფიქსი უკეთესი პასუხია
სტაბილური კერძო ქვექსელისთვის ცხადი პრეფიქსი უფრო მკაფიო, სწრაფი და აუდიტისთვის მარტივია. ის ასევე უძლებს გამხსნელის შეფერხებას, რადგან არაფერი საჭიროებს წყვეტას. მიმართეთ დომენის წესს, როცა სერვისი ჰოსტინგზეა, როცა მისამართები ბრუნავს, ან როცა ნამდვილად ვერ ჩამოთვლით დანიშნულების ნაკრებს. ნუ მიმართავთ მას მხოლოდ იმიტომ, რომ ჰოსტის სახელი ის არის, რაც შემთხვევით იცით.
გამოცნობილი სტატიკური სია ორივედან უარესია: ის მოვლილი ჩანს და ჩუმად ტოვებს ტრაფიკს იმ დღეს, როცა პროვაიდერი ჰოსტს დაამატებს.
გადაამოწმეთ ახალი მოთხოვნით
სცადეთ ცივი მოთხოვნით ჩვეულებრივი ხელახალი დაკავშირების შემდეგ, რადგან ქეშირებულმა გვერდმა შეიძლება არასდროს შეეხოს წესს. წყვიტეთ სახელი, შემდეგ შეამოწმეთ, სად წავიდა კავშირი სინამდვილეში. dig +short app.example.com გაძლევთ მიმდინარე მისამართების ნაკრებს და კლიენტის კავშირების სია გეუბნებათ, რომელმა ინტერფეისმა გადაიტანა ნაკადი.
გაიმეორეთ პროდუქტის მიერ დოკუმენტირებული განახლების ინტერვალის შემდეგ. თუ მისამართების ნაკრები იძვრება და წესი არ მიჰყვება, თქვენ იპოვეთ ნამდვილი ქცევა.
გამხსნელის პოლიტიკაც ცალკე შეინახეთ. დომენის წესს სჭირდება სწორი სახელის მონაცემები, მაგრამ ის თავისთავად არ წყვეტს, რომელი გამხსნელი პასუხობს მოთხოვნას.