SOCKS სერვერთან წვდომა VirtualBox NAT სტუმრის შიგნით

VirtualBox სტუმრის შიგნით არსებულ SOCKS სერვისს ორი ცალკე ხელმისაწვდომობის მოთხოვნა აქვს: VirtualBox-მა უნდა მიაწოდოს კავშირი სტუმარს, ხოლო სტუმრის სერვისმა უნდა მიიღოს ის.

VM-ისთვის, რომლის პირველი ადაპტერი ჩვეულებრივ NAT-ს იყენებს, VirtualBox 7.1 ამ ფორმით აღწერს პორტის გადამისამართების წესს. VM გამორთული მდგომარეობით:

VBoxManage modifyvm "Proxy VM" --nat-pf1 "socks,tcp,127.0.0.1,1080,,1080"

შეცვალეთ VM-ის სახელი და პორტები საჭიროებისამებრ. შემდეგ ჰოსტის აპლიკაცია ირჩევს SOCKS-ს 127.0.0.1:1080-ზე. ჰოსტის მხარის 127.0.0.1-ზე მიბმა ამ შესასვლელ წერტილს თავად ჰოსტით ზღუდავს.

სტუმრის მისამართის ცარიელი ველი ვარაუდობს, რომ სტუმარი იყენებს NAT ძრავის ჩაშენებულ DHCP განაწილებას. თუ სტუმარი სტატიკურ მისამართს იყენებს, მიუთითეთ ის წესში. ბოლო 1080 სტუმრის სერვისის პორტია; ის არ უნდა იყოს ჰოსტის პორტის ტოლი.

სტუმრის მსმენელი კვლავ ქსელური სერვისია

მხოლოდ 127.0.0.1-ზე მიბმული პროქსი სტუმრის შიგნით იღებს სტუმრის ლოკალურ კავშირებს. NAT გადამისამართება არ აიძულებს ამ loopback მსმენელს მიიღოს ტრაფიკი, რომელიც სტუმრის ვირტუალურ ინტერფეისზე მოდის. დააკონფიგურირეთ სერვისი შესაბამის სტუმრის ინტერფეისზე მოსასმენად და დაუშვით განზრახული ტრაფიკი სტუმრის firewall-სა და პროქსის წვდომის წესებში. შეამოწმეთ მსმენელის დაშვებული და აკრძალული წვდომა ამ საზღვრის შეცვლის შემდეგ.

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

ეს TCP წესი მოიცავს SOCKS კავშირს TCP-ზე. ის თავისთავად არ უზრუნველყოფს დამატებით UDP გზას, რომელიც SOCKS5 UDP relay-ს სჭირდება.