Միայն SSH սերվերի վրա սահմանված կեղծանունը կարող է աշխատել նրա դինամիկ SOCKS փոխանցման միջոցով, եթե հավելվածն ուղարկում է նպատակակետի անվանը։ Եթե այն նախ լուծում է տեղում և ուղարկում թվային հասցե, սերվերի hosts քարտեզը երբեք չի ստանում սկզբնական անվանը լուծելու համար։

OpenSSH-ի սովորական դինամիկ փոխանցումը ելքային կապի համար տիրույթային նպատակակետը տանում է սերվերի կողմ։ Այնտեղ OpenSSH-ն օգտագործում է համակարգի հասցեների որոնման API-ն։ Սովորական glibc Linux հոսթում NSS-ը կառավարում է hosts տվյալների բազան և որոնման հերթականությունը, ուստի hosts ֆայլի գրառումը կարող է մասնակցել։ Սա դյուրակիր համակարգչին պատճենված DNS գրառում չէ։

Պահպանեք նախատեսված անվանը, օրինակ preview.internal, կայքի URL-ում և ընտրեք հաճախորդի հեռավոր հոսթի անվան SOCKS ռեժիմը։ URL-ի հոսթի անվանը IP-ով փոխարինելը կարող է փոխել և՛ HTTP Host-ը, և՛ TLS ինքնությունը. հասանելիությունը վկայականը վավեր չի դարձնում այլ անվան համար։

Եթե կեղծանունը դեռ ձախողվում է, բացահայտեք այն միջավայրը, որը կատարում է հեռավոր որոնումը։ Կոնտեյները, chroot-ը կամ առանձին ծառայության օրինակը կարող է չօգտագործել ձեր խմբագրած hosts ֆայլը։ Այլ SOCKS իրականացումներ կարող են օգտագործել իրենց լուծիչները, ուստի այս համակարգային որոնման վարքը չպետք է ենթադրվի յուրաքանչյուր պրոքսի սերվերի համար։

Առնչվող հոդվածներ