Nebula-ს შუქურის DNS: ვის შეუძლია რომელი ჩანაწერის კითხვა?
არასავალდებულო მსმენელი პასუხობს შუქურის მიერ შენახული ჰოსტების მონაცემებიდან. A ჩანაწერებისა და TXT-ის მოთხოვნები განსხვავდება ხელმისაწვდომობითა და აუდიტორიით, ამიტომ მიამაგრე ის განზრახ.
შუქურის როლი Nebula-ში ბევრ საქმეს ასრულებს, რომელსაც ადამიანები ავტომატურად თვლიან, და DNS-ზე პასუხის გაცემა მათგან ერთი არ არის. სახელების მომსახურება არასავალდებულო მსმენელია, რომელიც გამორთული იწყებს, ამიტომ overlay-ის შიგნით კარგად გადამწყვეტ ჰოსტს შეიძლება საერთოდ არაფერი ჰქონდეს კოლეგის ლეპტოპის გადასაწყვეტად. ჩართვამდე გადაწყვიტე, ვინ უნდა მიაღწიოს მას და რომელი ტიპის ჩანაწერებზე ხარ მზად უპასუხო, რადგან ეს ორი პასუხი განსხვავებულია.
მსმენელი არასავალდებულოა და ნაგულისხმევად გამორთული
აღმოჩენა და DNS ცალკე სერვისებია. შუქური ეხმარება peer-ებს იპოვონ ერთმანეთი და დამატებით შეუძლია უპასუხოს სახელების მოთხოვნებს მისთვის ცნობილი ჰოსტების შესახებ, მაგრამ ეს მეორე ნაწილი კონფიგურაციაში ცალსახად უნდა ჩაირთოს.
სანამ რამეს ჩართავ, გადაწყვიტე, რომელი ინტერფეისები და ქსელები უნდა აღწევდეს მსმენელს. DNS სერვისი, რომელიც პასუხობს იმ ინტერფეისზე, რომელიც არ გქონდა განზრახული, მცირე საინფორმაციო გაჟონვად იქცევა ყოველგვარი ჟურნალის ჩანაწერის გარეშე, რომელსაც ვინმე წაიკითხავს. გადაწყვეტილების მიღება ახლა გაცილებით იაფია, ვიდრე მოგვიანებით მისი შევიწროება, როცა რაღაც უკვე არასწორ პასუხზეა დამოკიდებული. კონფიგურაციის ორი სტრიქონი უფრო ადვილად დასაბუთებადია, ვიდრე ინციდენტის ჩანაწერი ნახევარი წლის შემდეგ.
A ჩანაწერები და TXT არ იზიარებენ აუდიტორიას
ამ ორ ტიპის ჩანაწერზე პასუხი სხვადასხვა პირობებში გაიცემა, და მათი ერთ სერვისად განხილვა ის შეცდომაა, რომლის თავიდან ასაცილებლადაც ეს სტატია არსებობს.
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
ეს ასიმეტრია განზრახ არის და არა გულგრილობა. სახელის მისამართზე დაბმას მცირე ღირებულება აქვს გარესამყაროსთვის, ხოლო სერტიფიკატის მეტამონაცემები აღწერს თქვენი overlay-ის იდენტობებს. ნუ გადაიტან დაშვებას ერთი სტრიქონიდან მეორეზე მხოლოდ იმიტომ, რომ ერთი და იგივე პროცესი პასუხობს ორივეს.
ის პასუხობს მხოლოდ შუქურის საკუთარი ჰოსტების შესახებ
ეს არ არის ზოგადი გადამწყვეტი თქვენი ოფისისთვის, ღრუბლოვანი VPC-ისთვის ან საჯარო ინტერნეტისთვის. შუქური პასუხობს მისთვის მიცემული ჰოსტის ინფორმაციიდან, ამიტომ ეს ფუნქცია შუქურის კვანძებზე ცხოვრობს და არა ყოველ peer-ზე.
როცა სახელი ვერ გადაწყდა და overlay-ს ამასთან კავშირი არ აქვს, იპოვე ზონა და გადამწყვეტი, რომლებიც მას ნამდვილად ფლობენ. overlay გადამწყვეტის შერევა ჰოსტის ზოგად DNS კონფიგურაციაში იწვევს წარუმატებლობებს, რომლებიც შემთხვევითურად გამოიყურება, რადგან ზოგი სახელი გადაწყდება, ზოგს კი არაფერი პასუხობს.
ყურადღება მიაქციე ასევე bootstrap-ის შესასვლელ წერტილს. პირველ შუქურამდე მისასვლელად გამოყენებული ჰოსტის სახელი ჩვეულებრივი გზით უნდა გადაწყდეს, სანამ აღმოჩენა მასზე დაეყრდნობა, ამიტომ ქათამი და კვერცხის პრობლემა აქ ზუსტად გატეხილ overlay-ს ჰგავს. ის იმავე გზით იუწყება კიდეც: peer, რომელიც არასდროს ადის და არავითარი აშკარა მიზეზი. შეამოწმე სახელების გადაწყვეტა სერტიფიკატებზე შეხებამდე, რადგან ეს რიგი იჭერს მათ, ვინც უფრო რთული ნახევრით დაიწყო.
შეამოწმე მიბმის მისამართი, შემდეგ გამოსცადე გარედან
lighthouse.dns.host და lighthouse.dns.port განსაზღვრავენ, სად უსმენს არასავალდებულო სერვისი. გადახედე ამ მნიშვნელობებს ჰოსტის firewall-თან და ქსელურ პოლიტიკასთან ერთად, რადგან მიბმის მისამართი განზრახვის განაცხადია და არა თავისთავად უსაფრთხოების კონტროლი.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortჰკითხე იმ ქსელებიდან, რომლებზეც ნებას აპირებ, და არა თავად შუქურიდან. წარმატებული ძიება შუქურზე ამტკიცებს, რომ პროცესი მუშაობს და არაფერს გეუბნება იმაზე, რასაც გარე ჰოსტი იკითხავს, და სწორედ ეს კითხვაა ნამდვილად მნიშვნელოვანი.
გამოავლინე ის განზრახ
სახელები და სერტიფიკატის მეტამონაცემები სასარგებლო ოპერაციული ინფორმაციაა და სარგებლიანობა ორივე მიმართულებით ჭრის. გადაწყვიტე, მსმენელი მხოლოდ overlay-ისთვის უნდა იყოს თუ არა, რომელი ტიპის ჩანაწერები დაიშვას და ვინ გადახედავს კონფიგურაციას, როცა ის იცვლება.
შემდეგ ჩაწერე ის შუქურის პარამეტრების გვერდით. შემდეგი ადამიანი, რომელიც გადაწყვეტის ხარვეზს გამართავს, სხვა შემთხვევაში ჩათვლის, რომ სერვისი იქ ყოველთვის იყო. ის ასევე ჩათვლის, რომ ის ყოველთვის ხელმისაწვდომი იყო იქიდან, სადაც შემთხვევით ტესტავს. ერთი აბზაცი, რომელიც აღრიცხავს მიბმის მისამართს, ნებადართულ ქსელებსა და ჩანაწერების ტიპებს, დაზოგავს იმ ადამიანს ერთ შუადღეს და დაზოგავს შენ შეტყობინებას, რომელიც კითხულობს, რატომ შეიცვალა რაღაც.