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