რატომ ეხმარება SRV ჩანაწერი მხოლოდ იმ კლიენტს, რომელიც თავად იკითხავს მას

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

ჩანაწერი, რომელსაც არავინ იკითხავს, ვერავის დაეხმარება

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

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

წაიკითხეთ ველები სანამ დაწერთ

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

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

იპოვეთ იარლიყი, რომელსაც კლიენტი რეალურად აგზავნის

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

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

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

სამიზნეც უნდა არსებობდეს

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

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

აღმოჩენა არ არის ავთენტიფიკაცია

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

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