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

OpenSSH-ის ჩვეულებრივი დინამიკური გადაცემა გამავალი კავშირისთვის დომენურ დანიშნულებას სერვერის მხარეს გადააქვს. იქ OpenSSH იყენებს სისტემის მისამართების ძიების API-ს. ტიპურ glibc Linux ჰოსტზე NSS აკონტროლებს hosts მონაცემთა ბაზასა და ძიების რიგს, ამიტომ hosts ფაილის ჩანაწერს შეუძლია მონაწილეობა. ეს არ არის ლეპტოპზე კოპირებული DNS ჩანაწერი.

შეინარჩუნეთ სასურველი სახელი, მაგალითად preview.internal, ვებსაიტის URL-ში და აირჩიეთ კლიენტის დისტანციური ჰოსტის სახელის SOCKS რეჟიმი. URL-ის ჰოსტის სახელის IP-ით ჩანაცვლებამ შეიძლება შეცვალოს როგორც HTTP Host, ისე TLS იდენტობა; ხელმისაწვდომობა სერტიფიკატს სხვა სახელისთვის ნამდვილს არ ხდის.

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

დაკავშირებული სტატიები