BIND VPN-ის გავლით: პირობითი გადამისამართება თუ stub ზონა?
VPN-ის გავლით ერთი კერძო ზონის ამოხსნის სამი გზა და როდის რომელია შესაფერისი: forward, stub ან secondary, დამატებით წყარო-მისამართის შემოწმება, რომელიც წყვეტს.
თქვენი ოფისის resolver პასუხობს ყველაფერს ერთი კორპორატიული სახელების სივრცის გარდა, და ის კორპორატიული DNS სერვერი, რომელმაც ის იცის, VPN-ის უკანაა. BIND-ს შეუძლია ეს ერთი ზონა upstream-ს სამი სხვადასხვა გზით გადასცეს და ისინი სხვადასხვანაირად ფარდება. პირობითი გადამისამართება ყველაზე მცირე ვალდებულებაა, stub ზონა ინახავს დელეგირების მონაცემებს, ხოლო secondary ინახავს სრულ ასლს. აირჩიეთ იმის მიხედვით, რას დაუშვებს upstream და რისი შენახვა გსურთ თქვენი resolver-ისგან, და არა იმის მიხედვით, რომელი ფრაგმენტი იპოვეთ პირველად.
სამი მოწყობა ერთი სახელების სივრცისთვის
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
პირობითი გადამისამართება: ყველაზე მცირე ვალდებულება
დავუშვათ, ოფისის resolver მისამართზე 192.168.10.53 და კორპორატიული სერვერი მისამართზე 10.40.0.53, რომელიც ხელმისაწვდომია დამტკიცებული გვირაბით. დეკლარაცია სამი ხაზია, და საინტერესო forward only-ია, რადგან ის ცვლის წარუმატებლობის ქცევას და არა გზას.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};forward only-ით მიუწვდომელი upstream ამ ზონისთვის აბრუნებს SERVFAIL-ს და არა დაბრუნებას განმეორებით გადაწყვეტაზე. კერძო სახელების სივრცისთვის ჩვეულებრივ სწორედ ეს გსურთ, რადგან დაბრუნება კერძო სახელებს გაუგზავნიდა საჯარო resolver-ს და ინტერნეტიდან უსარგებლო პასუხს დააბრუნებდა. BIND-ის ცნობარი ორივე პოლიტიკას აღწერს და განსხვავება უფრო მნიშვნელოვანია, ვიდრე ფრაგმენტი მიანიშნებს. შეურთეთ ზონა არსებულ კონფიგურაციას და ნუ ჩაანაცვლებთ ზონას, რომელიც უკვე არსებობს იმავე სახელისთვის.
stub თუ secondary: როცა დელეგირებას მნიშვნელობა აქვს
stub ზონა კორპორატიულ სერვერს ჰკითხავს ზონის NS ჩანაწერებს და შემდეგ პირდაპირ ჰკითხავს ავტორიტეტულ სერვერებს. აირჩიეთ ის, როცა upstream-ის რეგიონი დიდია ან დაყოფილია და გსურთ, რომ თქვენი resolver დელეგირებას მიჰყვეს და ყველაფერი ერთ მისამართზე არ მიამაგროს. ფასია დამოკიდებულება NS მონაცემების აქტუალობაზე და იმაზე, რომ სიაში მითითებული ყველა სახელის სერვერი ხელმისაწვდომი იყოს თქვენი resolver-ის წყარო-მისამართიდან.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};secondary პასუხობს ლოკალური მონაცემებიდან და გადაურჩება upstream-ის გათიშვას, და ეს არის გადაცემაზე დამოკიდებულების მიღების მიზეზი. ეს ასევე ნიშნავს, რომ თქვენი resolver ახლა ინახავს ზონის ასლს, რომელიც მისი არ არის, ამიტომ ფაილის გზა, პირველადი სერვერის გადაცემის ACL და განახლების ტაიმერები თქვენი ოპერაციული ზედაპირის ნაწილი ხდება.
შემოწმება, რომელიც მათ შორის წყვეტს
BIND თავად ქმნის გამავალ მოთხოვნას, ამიტომ კითხვა არ არის, შეუძლია თუ არა ლეპტოპს 10.40.0.53-მდე მისვლა, არამედ ის, შეუძლია თუ არა resolver-ის ჰოსტს, იმ წყარო-მისამართიდან, რომელსაც კორპორატიული სერვერი დაინახავს. ჰკითხეთ ბირთვს, შემდეგ ჰკითხეთ სერვერს, ამ თანმიმდევრობით.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleდაუშვით UDP და TCP გზაზე: შეკვეცილი პასუხი აიძულებს TCP-ს, ხოლო მხოლოდ UDP-ის დამშვები პოლიტიკა წარმოქმნის წყვეტილ წარუმატებლობებს, რომლებიც პაკეტების დაკარგვას ჰგავს. კორპორატიულ მხარეს სჭირდება როგორც მიღების წესი თქვენი resolver-ის წყაროსთვის, ისე დაბრუნების მარშრუტი მისკენ; ეს წყარო შეიძლება იყოს resolver-ის მარშრუტიზებული მისამართი ან ცხადად ნათარგმნი, და იშვიათად კლიენტთა პულის მისამართია. თუ NS მოთხოვნა ვერ შესრულდა, stub ზონა ვერ იმუშავებს, რაც არ უნდა იყოს forward ზონის ქცევა.
შეამოწმეთ პასუხი და არა გვირაბი
ჰკითხეთ ოფისის resolver-ის გავლით სახელი, რომელიც არასდროს გიკითხავთ, და შეხედეთ პასუხის authority ნაწილს, რომ გაიგოთ, მოვიდა თუ არა კორპორატიული ზონიდან. ქეშირებული პასუხი მიმდინარე გზაზე არაფერს ამტკიცებს, და upstream-ზე პირდაპირი წარმატებული მოთხოვნა არ ამტკიცებს, რომ თქვენმა resolver-მა სწორედ ეს ზონა აირჩია. გაიმეორეთ იგივე მოთხოვნა TCP-ით, რომ დაადასტუროთ გზის შეკვეცის გადატანა.
შეინარჩუნეთ კლიენტები ოფისის resolver-ისკენ მიმართული, და დატოვეთ DNSSEC ვალიდაცია ჩართული. დამოუკიდებელი დაშიფრული resolver-ით კონფიგურირებული ბრაუზერი მთლიანად გვერდს უვლის ამ მოწყობას, ხოლო ვალიდაციის გამორთვა იმისთვის, რომ მოულოდნელი პასუხი სწორად გამოიყურებოდეს, ხილულ წარუმატებლობას უხილავით ცვლის.
ჩაწერეთ, სამი ტიპიდან რომელი აირჩიეთ და რატომ. შემდეგ ადამიანს, რომელიც ზონის წარუმატებლობას დაინახავს, ეს წინადადება მეტად დასჭირდება, ვიდრე კონფიგურაციის ფაილი.