კერძო DNS სახელი თუ უბრალოდ IP? გადაწყვიტეთ გაზიარებამდე
აირჩიეთ სახელი resolver-ის გზიდან, ხოლო წვდომის წესი იმ წყაროდან, რომელსაც სერვისი ხედავს. ეს ორი ცალკე გადაწყვეტილებაა და თითოეულს თავისი ტესტი აქვს.
ორი კითხვა ერთმანეთში ირევა, როცა კერძო სერვისი დისტანციურ მომხმარებლებისთვის იხსნება. პირველია, რომელი სახელი უნდა გამოიყენონ კლიენტებმა; მეორეა, რომელი წყაროები უნდა დაუშვას სერვისმა. ამ რიგით უპასუხეთ, რადგან სწორი სახელი არასწორი წვდომის წესის უკან მაინც ვერ ასრულებს, და გადაუწყვეტელი სახელის უკან სწორი წესი არასოდეს არ მოწმდება.
პირველი პირობა: რომელი resolver-ის გზა აქვთ კლიენტებს?
კერძო სახელი მუშაობს მხოლოდ მაშინ, როცა კლიენტის resolver-ს შეუძლია პასუხის გაცემა. ეს ნიშნავს, რომ ავტორიზებულმა დისტანციურმა კლიენტმა უნდა მიაღწიოს ზონის მფლობელ DNS სერვერს, ან გვირაბის გავლით, ან resolver-ის გავლით, რომელსაც ორგანიზაცია უკვე ამუშავებს დისტანციური მომხმარებლებისთვის. გვირაბი ტრანსპორტია და არა საძიებელი. ის კლიენტს აძლევს გზას resolver-ისკენ და არ ეუბნება, რომელი ზონა ჰკითხოს.
resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example
საჯარო resolver არ ისწავლის კერძო ზონას მხოლოდ იმიტომ, რომ ლეპტოპი VPN-ს დაუკავშირდა.
სუფიქსი იმავე ყურადღების ღირსია. გამოიყენეთ ორგანიზაციის მიერ კონტროლირებული დომენის ქვედომენი, რომ საკუთრება და სერტიფიკატების დაგეგმვა ნათელი დარჩეს. მოერიდეთ .local-ს: multicast DNS-ის სპეციფიკაცია ამ სუფიქსს link-local გადაწყვეტას უკავშირებს, და მარშრუტიზებული გვირაბი ამ ქცევას თქვენთვის არ იმეორებს.
მეორე პირობა: რომელ წყაროს იღებს სერვისი?
წვდომის წესები მისამართების მიმართ იწერება, ამიტომ სასარგებლო კითხვაა, რომელ მისამართს ხედავს სერვისი მარშრუტიზაციისა და თარგმნის შემდეგ. მაგალითად, სერვისისთვის 10.20.30.40-ზე, ოფისის კლიენტები მოდიან 10.20.30.0/24-დან, ხოლო დისტანციური კლიენტები ცალკე აუზიდან, მაგალითად 10.99.0.0/24-დან.
თუ კარიბჭე დისტანციურ აუზს თარგმნის, სერვისი მთარგმნელს ხედავს, და 10.99.0.0/24-ისთვის დაწერილი წესი არ დაემთხვევა.
წაიკითხეთ ეს სერვისის მხრიდან და არა კლიენტის მხრიდან. მსმენელის ჟურნალი ან პაკეტის დაჭერა სერვისის ჰოსტზე აჩვენებს წყაროს, რომელიც რეალურად მოვიდა; კლიენტის საკუთარი მისამართი მხოლოდ ვარაუდია იმის შესახებ, თუ რა გადარჩა გზაზე.
მესამე პირობა: სახელი სერვისს უკავშირდება თუ ჰოსტს?
სახელი, რომელიც ერთი მანქანის მისამართზე მიუთითებს, ყველა კლიენტს ამ მანქანას აკავშირებს. სახელი, რომელიც დატვირთვის გამანაწილებელზე ან სტაბილურ სერვისის მისამართზე მიუთითებს, მის უკან მდგარი ჰოსტის შეცვლას გადაურჩება. შეგნებულად აირჩიეთ, რადგან ამის მოგვიანებით შეცვლა ნიშნავს ყოველი კლიენტის სანიშნებისა და ყოველი სერტიფიკატის სუბიექტის შეცვლას.
ერთი შიდა სერვისისთვის პირდაპირი ჩანაწერი ჩვეულებრივ კარგია და უფრო ადვილი გასააზრებელი.
ყველაფრისთვის, რაც შეიცვლება, აშენდება ან მასშტაბირდება, სტაბილური წინა ნაწილი დამატებით კონფიგურაციას ღირს. ტესტი მარტივია: თუ შეგიძლიათ ბექენდის შეცვლა მომხმარებლებისთვის უთქმელად, სახელი სერვისს უკავშირდება; თუ არა, ის ჰოსტს უკავშირდება.
ორი გადაწყვეტილება ცალკე გამოსცადეთ
ჯერ ამოხსენით, შემდეგ დაუკავშირდით. მოსალოდნელი მისამართის დაბრუნების გადაწყვეტის ტესტი ამტკიცებს სახელის გზას და არაფერს ამბობს წვდომაზე. კავშირის ტესტი გზასა და წესს ერთად ამტკიცებს, ამიტომ ის მხოლოდ წარმატებული გადაწყვეტის შემდეგ გაუშვით.
curl -sv --max-time 5 https://files.corp.example/health
შემდეგ ერთხელ გამოსცადეთ აკრძალული წყარო და ჩაწერეთ შედეგი.
ორი ჩანაწერი ცალკე შეინახეთ თქვენს დოკუმენტაციაში: სახელი და მისი ზონა, დაშვებული წყაროები და წესის მფლობელი. როცა ერთი იცვლება, მეორეს არ უნდა შეიცვალოს.
სად ცდება გადაწყვეტილება ჩვეულებრივ
ხშირი მარცხია სერვისი, რომელიც გამოქვეყნებულია სახელით, რომელიც მხოლოდ ოფისის ქსელში იხსნება, წვდომის წესით, რომელიც მხოლოდ ოფისის დიაპაზონს უშვებს. შემდეგ დისტანციური მომხმარებლები იტყობინებიან გატეხილ სერვისზე, რომელიც სინამდვილეში ორი ცალკე გამოტოვებაა. მეორე ხშირი მარცხი საპირისპიროა: სახელის პრობლემის მოსაშორებლად დამატებული ფართო წვდომის წესი სერვისს ისეთი წყაროებიდან ხდის ხელმისაწვდომს, რომლებიც არავის ჰქონია გულისხმაში. ორივე კონფიგურაციის გამოტოვებაა და მომხმარებლის სკამიდან ერთნაირად გამოიყურება.
არც ერთი შეცდომა არ ჩანს ერთი წარმატებული ტესტიდან. ამიტომ ორი გადაწყვეტილება იმსახურებს ცალკე ჩანაწერებსა და ცალკე ტესტებს, მაშინაც კი, როცა ერთი ადამიანი იღებს ორივეს.
ორივე ჩაწერეთ სანამ სერვისი ამუშავდება, რადგან შემდეგი ცვლილება უფრო ადვილი გასააზრებელი იქნება. ჩანაწერი მოკლეა: ერთი ხაზი სახელისა და მისი ზონისთვის, ერთი ხაზი დაშვებული წყაროებისა და წესის მფლობელისთვის.