გაყოფილი DNS და VPN: დომენის წესები IP მარშრუტები არ არის
გაყოფილი DNS ამომხსნელს სახელის მიხედვით ირჩევს და პასუხს მაინც მარშრუტი სჭირდება. გამოსცადეთ დომენის წესი და ბილიკი ცალ-ცალკე, იმ პლატფორმაზე, რომელსაც რეალურად იყენებთ.
თქვენი ლეპტოპი intranet.corp-ს გვირაბის გავლით წყვეტს, ხოლო gitlab.com კვლავ პროვაიდერის ამომხსნელთან მიდის და ეს ის წყობაა, რომელიც დაპროექტებულისამებრ მუშაობს. ორმა ცალკეულმა გადაწყვეტილებამ შექმნა იგი: სახელის დამთხვევის წესმა აირჩია ამომხსნელი და მარშრუტმა უკან დააბრუნა პასუხი. გატეხეთ რომელიმე მათგანი და ბრაუზერი აჩვენებს ჩავარდნას, რომელიც გარედან ერთნაირად გამოიყურება. გაყოფილი DNS-ის შესახებ მოხსენებების უმეტესობა მეორე ჩავარდნას აღწერს და ამავდროულად პირველზე მტკიცებულებებს ციტირებს.
ორი ნახევარი სხვადასხვა ადგილას ცხოვრობს და ჩვეულებრივ სხვადასხვა ადამიანი არედაქტირებს მათ. ერთი VPN პროფილზე მიმაგრებული DNS პოლიტიკაა, მეორე კი მარშრუტი, რომელსაც გვირაბი აყენებს ან იკავებს. გამართვა ჩერდება, როცა არავინ ადგენს, რომელი ნახევარი გადაადგილდა სინამდვილეში.
ორი გადაწყვეტილება ერთ მოთხოვნაში დამალული
სახელის ნახევარი პოლიტიკის ობიექტია და არა მარშრუტი. Windows-ში ეს არის სახელის ამოხსნის პოლიტიკა VPN პროფილზე; Apple-ის პლატფორმებზე — შესაბამისი დომენების ნაკრები DNS პარამეტრების ობიექტზე; Linux-ში — მარშრუტიზაციის დომენი, გაყოფილი ამომხსნელის ხაზი ან სახელის სერვისის გადამრთველის რიგი. ბილიკის ნახევარი ჩვეულებრივი მარშრუტიზაციაა, დაყენებული გვირაბის ან ხელის მიერ, და მან არ იცის რა არის ჰოსტის სახელი. პროფილი, რომელიც სუფიქსს უშვებს, მხოლოდ წყვეტს ვინ უპასუხებს; ის არასოდეს ხდის პასუხს მისაწვდომს.
სწრაფი სიმპტომური ტესტი ჰყოფს მათ: შეცვალეთ სახელი მისამართით. თუ მისამართი მუშაობს, ბილიკი რიგზეა და წესი არასწორია. თუ მისამართიც ვერ მუშაობს, წესი შეიძლება სწორი იყოს და ბილიკი აკლდეს.
როგორ გამოხატავს თითოეული პლატფორმა იმავე სახელის წესს
განზრახვა იდენტურია და ველების სახელები არა. ერთი კლიენტიდან მეორეში კოპირებული მაგალითი სუფთად იშლება და არასოდეს ემთხვევა. სამი ფორმა ასე გამოიყურება:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
შესაბამისობის ან მარშრუტიზაციის დომენი სუფიქსის ტესტია, ამიტომ intranet.corp ფარავს git.intranet.corp-ს და არ ფარავს corp.intranet-ს, და მისი შებრუნება მთელი კონფიგურაციის ყველაზე გავრცელებული შეცდომაა. Windows ატარებს დაბმას პროფილზე მიმაგრებული სახელის ამოხსნის პოლიტიკის სახით, საკუთარი უპირატესობის რიგით იმ სუფიქსების სიის მიმართ, რომელიც ინტერფეისს უკვე ჰქონდა. Apple-ის პლატფორმები შესაბამის დომენებს ამაგრებენ ქსელური გაფართოების DNS პარამეტრების ობიექტზე და სისტემა მათ თითოეულ შემოფარგლულ ამომხსნელზე იყენებს. არც ერთი ეს ფორმა მარშრუტი არ არის და არც ერთს არ შეუძლია მიუწვდომელი მისამართის მისაწვდომად ქცევა. Windows-ის სახელის ამოხსნის პოლიტიკის ცნობარი ჩამოთვლის ამ პლატფორმის ველების სახელებსა და უპირატესობის წესებს და ეს ის წესები არ არის, რომლებსაც Apple-ის ან systemd-ის დოკუმენტები იყენებენ.
სწორ პასუხს მაინც ბილიკი სჭირდება
ამომხსნელის პასუხი მხოლოდ მისამართია და აპლიკაციამ მას მაინც უნდა მიაღწიოს. გაყოფილი გვირაბის დიზაინი ხშირად უბიძგებს 10.20.0.0/16-ს და იკავებს ნაგულისხმევ მარშრუტს, ამიტომ შიდა სახელი წყდება და კავშირი შემდეგ იკიდება. საპირისპირო შემთხვევა ისევე ხშირია: მარშრუტი არსებობს, საჯარო ამომხსნელი პირად სახელს NXDOMAIN-ით პასუხობს და ჩავარდნა მარშრუტიზაციის პრობლემად რეგისტრირდება. ბილიკის პირველად ტესტირება გტოვებთ იმ სახელის მარშრუტებზე ყურებაში, რომელიც არასოდეს უნდა წყდებოდეს.
მესამე კარიბჭეც არსებობს, რომელსაც არც ერთი ნახევარი არ ფარავს. ACL კარიბჭეზე, ფაირვოლის წესი ან კლიენტის მხარის პოლიტიკა შეიძლება კავშირი ჩამოაგდოს მას შემდეგ, რაც ორივე გადაწყვეტილება სწორი იყო. როცა სახელი წყდება, მარშრუტი არსებობს და კავშირი მაინც დროთა გასვლით სრულდება, შეწყვიტეთ DNS-ის ტესტირება.
სახელებისა და ბილიკების ტესტირება ფიქსირებული რიგით
აირჩიეთ რიგი და დაიცავით ის, თორემ გაურბენთ იმ ნაბიჯს, რომელიც ბოლოს ჩავარდა. ამოხსენით დოკუმენტირებული სრული შიდა სახელი, დაადასტურეთ, რომ პასუხი მისამართია, რომელსაც მარშრუტების ცხრილი ზიდავს, შემდეგ გაიმეორეთ საჯარო სახელით, რათა დაამტკიცოთ, რომ გვირაბმა ყველაფერი არ დაიჭირა. systemd ჰოსტზე მოთხოვნა და ამომხსნელის მარშრუტიზაციის დომენი ერთი ბრძანების დაშორებითაა:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows კლიენტი იმავე ორ კითხვას სხვა cmdlet-ებით სვამს. მეორე აცნობს იმ ინტერფეისს, რომელსაც სისტემა რეალურად გამოიყენებდა:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10თუ ძებნა მისამართს აბრუნებს და ბილიკის შემოწმება ფიზიკურ ინტერფეისს ასახელებს, სახელის წესმა იმუშავა და მარშრუტმა არა. თუ მოკლე სახელი ვერ მუშაობს, სანამ სრული სახელი წყდება, სუფიქსების სიაა არასწორი და არა ამომხსნელი.
სად ცდება შედარება ჩვეულებრივ
პირველი შეცდომაა დაუკავშირებელ საჯარო ამომხსნელს პირად სახელზე ჰკითხო და უარი VPN-ის შესახებ მტკიცებულებად წაიკითხო. მეორეა ჩათვალო, რომ მოქმედი საჯარო ძებნა გვირაბის ამომხსნელის ბილიკს ამტკიცებს. მესამეა გაყოფილი გვირაბი და გაყოფილი DNS ერთ დიზაინის გადაწყვეტილებად მივიჩნიოთ, მაშინ როცა განლაგება ერთში სწორი და მეორეში გატეხილი შეიძლება იყოს. ყოველი შეცდომა თავდაჯერებულ დასკვნებს იძლევა ტესტიდან, რომელსაც ბრალდებული ნაწილი არასოდეს უვარჯიშია.
საკუთარი უსაფრთხო DNS-ის მქონე ბრაუზერსაც შეუძლია სისტემური წესის გვერდის ავლა, ამიტომ ერთი ბრაუზერის ჩავარდნა, სანამ მეორე წარმატებას აღწევს, წინააღმდეგობა არ არის. შეადარეთ ამომხსნელი, რომელმაც უპასუხა და არა ბრაუზერი, რომელმაც იჩივლა.
როცა ორივე ნახევარი ხილულია, დარჩენილი კითხვა პოლიტიკის კითხვაა და არა ტექნიკური: რომელი სახელის სივრცეები ეკუთვნის ორგანიზაციას, ვის ეკუთვნის თითოეული პასუხი და რომელი მათგანი უნდა გავიდეს მანქანიდან საერთოდ. ჩაწერეთ ეს პროფილის გვერდით, რადგან წესზე შემდეგი შემხებ ადამიანს ეს დასჭირდება.