რატომ არ შეიძლება ველური ბარათის მუშაობა OpenVPN-ის მარშრუტის ინსტრუქციაში

განზრახვა გონივრულია: ერთი კომპანიის დომენის ყველაფერი გვირაბში გაატაროთ და დანარჩენი მარტო დატოვოთ. ინსტრუქცია, რომელსაც არედაქტირებენ, მარშრუტებს აყენებს, ხოლო მარშრუტს ჰოსტის სახელის არავითარი ცნება არ აქვს, რასთანაც შეადარებს. მასში wildcard-ის ჩაწერის ყველა მცდელობა იძლევა ან ანალიზის შეცდომას, ან, რაც უარესია, მარშრუტს, რომელიც დღეს შემთხვევით მუშაობს, რადგან სახელი ერთ მისამართად გადაწყდა. ორ სხვადასხვა მექანიზმს ერთმანეთის საქმის კეთებას სთხოვენ.

რას აყენებს მარშრუტი და რას ის არასოდეს არ კითხულობს

მარშრუტის ჩანაწერი ამბობს, რომ დანიშნულების პრეფიქსი ხელმისაწვდომია ინტერფეისის მეშვეობით. ბირთვი პაკეტებს ამ პრეფიქსებს ადარებს, ამიტომ ჩართული ერთადერთი იდენტიფიკატორები მისამართები და ნიღბებია. ჰოსტის სახელი არასოდეს ჩნდება გადაგზავნის გადაწყვეტილებაში, და სწორედ ამიტომ იქ ნიმუშის შედარება შეუძლებელია.

OpenVPN-ს ზოგიერთი მარშრუტის პარამეტრში შეუძლია გახსნადი სახელის მიღება, და ეს შემწყნარებლობა დაბნეულობის წყაროა. სახელი იხსნება კონფიგურაციის გამოყენებისას და წარმოქმნის ერთ ან რამდენიმე მისამართს, რომლებიც ჩვეულებრივ მარშრუტებად იქცევიან. ამის შემდეგ სახელი სრულიად ქრება სურათიდან.

ასე რომ, სახელიდან აგებული მარშრუტი კადრია და არა წესი. ის ფარავს იმას, რაშიც ეს სახელი გადაწყდა გვირაბის გაშვების მომენტში, და ეს ზუსტად ის ქცევაა, რომელიც არ გსურთ ცვალებადი ჰოსტების ოჯახისთვის. ჩანაწერი, რომელიც ხვალ გადაადგილდება, მარშრუტს გუშინზე მიმთითებელი დატოვებს.

როცა დანიშნულება ნამდვილად პრეფიქსია

თუ სამიზნე ცნობილი კერძო ქსელია, დაწერეთ პრეფიქსი. დოკუმენტაციის სივრციდან მაგალითისთვის, ერთი ჰოსტი და ერთი ქვექსელი ასე გამოიყურება:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

ორივე ჩანაწერი ასახელებს მისამართებსა და ნიღბებს, და ორივე უძლებს DNS-ის ცვლილებებს, რადგან მათში არაფერია დამოკიდებული სახელზე. ეს არის მთელი უპირატესობა: მარშრუტი განაცხადია ტოპოლოგიაზე და არა ერთხელ მომხდარ ძიებაზე.

ნუ გამოიტანთ დიდ პრეფიქსს ერთი DNS პასუხიდან. ერთ მისამართად გახსნადი ერთი ჰოსტის სახელი არაფერს გეუბნებათ მის უკან არსებული ქსელის ზომაზე, და გამოცნობილი პრეფიქსი ის გზაა, რომლითაც გვირაბი საბოლოოდ იჭერს ტრაფიკს, რომლის გავლით გაშვებას არავინ აპირებდა. ძიებიდან დასკვნის გამოტანის ნაცვლად ჰკითხეთ ქსელის მფლობელს ფაქტობრივი პრეფიქსი.

როცა სამუშაო ერთეული ჰოსტის სახელია

დომენით შერჩევა მოითხოვს იმას, რაც კითხულობს დომენს, ანუ აპლიკაციის დონის კომპონენტს. ჩვეულებრივი პასუხია HTTP პროქსი, რომელიც გვირაბის მეორე მხარეს ცხოვრობს, და კლიენტი ირჩევს, რომელი მოთხოვნები გაუგზავნოს მას.

პროქსის კონფიგურაციის ფაილს შეუძლია გამოხატოს ეს არჩევანი. ქვემოთ მოცემული საილუსტრაციო წესები ერთ დომენსა და მის ქვედომენებს პროქსიზე აგზავნის, ხოლო დანარჩენს — პირდაპირ:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

ზუსტი სახელის შედარება ფარავს თავად დომენს, ხოლო სუფიქსის შედარება ფარავს მის შვილებს ისე, რომ არ დაემთხვეს სახელს, რომელიც უბრალოდ მსგავს სიმბოლოებზე მთავრდება. ორივე საჭიროა, და ერთის გამოტოვება ქმნის წესს, რომელიც სწორად გამოიყურება და გამოტოვებს მწვერვალს ან თაღლითს.

ეს წესები პროქსის ირჩევენ; ისინი არ ქმნიან მას და არ ცვლიან ოპერაციული სისტემის არც ერთ მარშრუტს. პროქსის მისამართს კვლავ სჭირდება საკუთარი გზა გვირაბში, და პირდაპირად მონიშნული მოთხოვნები კვლავ მიჰყვებიან იმ მარშრუტიზაციის პოლიტიკას, რომელიც მანქანას უკვე აქვს.

რას არ ფარავს პროქსის ვარიანტი

პროგრამებზე, რომლებიც ბრაუზერის პროქსის კონფიგურაციას უგულებელყოფენ, ამ ყველაფრისგან ვერაფერი იმოქმედებს. ბრძანების ხაზის ხელსაწყოები, განახლების პროგრამები და საკუთარი ქსელური სტეკის მქონე აპლიკაციები იღებენ მარშრუტების ცხრილს და არა PAC ფაილს, ამიტომ ამ შემთხვევებს სჭირდება მხარდაჭერილი მექანიზმი თითოეული აპლიკაციისთვის ან სხვა დიზაინი. სანამ დაპირდებით, რომ ბრაუზერის წესი ფარავს სამუშაო პროცესს, ჩამოთვალეთ მნიშვნელოვანი კლიენტები.

პირდაპირ დაბრუნება არც გამოსავალია. თუ მანქანის მარშრუტიზაციის პოლიტიკა უკვე ყველაფერს გვირაბში აგზავნის, პირდაპირად მონიშნული მოთხოვნა მის შიგნით რჩება, რადგან პროქსის არჩევანი და მარშრუტების ცხრილი სხვადასხვა ფენაზე მიღებული სხვადასხვა გადაწყვეტილებაა.

სახელების გახსნა მესამე ცალკე კითხვაა. იმის არჩევა, რომელი მოთხოვნები მიდის პროქსიზე, არაფერს ამბობს იმაზე, რომელი გამხსნელი პასუხობს მათ, და ორივეს ერთ პარამეტრად მოპყრობა ქმნის გაჟონვებს, რომლებიც უხილავია მანამ, სანამ ვინმე გარედან არ გამოსცდის. გადაწყვიტეთ, სად პასუხობენ თითოეულ მოთხოვნას, და ეს გადაწყვეტილება ჩაწერეთ პროქსის წესის გვერდით. გამხსნელი, რომელიც იცვლება იმიტომ, რომ გვირაბი ამოვიდა, ჩუმად გადააადგილებს პასუხს.

ორივე გზის გამოცდა და არა მხოლოდ ბედნიერის

გამოსცადეთ ჰოსტის სახელი, რომელიც უნდა დაემთხვეს, ჰოსტის სახელი, რომელიც არ უნდა დაემთხვეს, და დომენის მწვერვალი, რადგან მწვერვალი ის შემთხვევაა, რომელსაც მხოლოდ სუფიქსის წესი ყველაზე ხშირად გამოტოვებს. შემდეგ დაადასტურეთ, რომელ გზას გაიარა თითოეულმა მოთხოვნამ სინამდვილეში, ნაცვლად იმისა, რომ გვერდის ჩატვირთვიდან დასკვნა გამოიტანოთ.

ბოლოს, გამოსცადეთ წარუმატებლობის ტოტი. მიუწვდომელი პროქსი უნდა ჩავარდეს იმ გზით, რომელიც წინასწარ გადაწყვიტეთ, და არა ჩუმად დაუბრუნდეს პირდაპირ კავშირს. ქსელური პარამეტრების ცნობარი ზუსტად აღწერს მარშრუტის პარამეტრებს; ამ დიზაინის დომენური ნახევარი მთლიანად მის გარეთ ცხოვრობს.