Ein SOCKS-teneste inne i ein VirtualBox-gjest har to separate tilgjengelegheitskrav: VirtualBox må levere tilkoplinga til gjesten, og tenesta i gjesten må godta ho.

For ein VM der den første adapteren brukar vanleg NAT, dokumenterer VirtualBox 7.1 ein portvidaresendingsregel i denne forma. Med VM-en stoppa:

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

Bytt ut VM-namnet og portane etter behov. Programmet på verten vel då SOCKS på 127.0.0.1:1080. Å binda vertssida til 127.0.0.1 avgrensar dette inngangspunktet til verten sjølv.

Det tomme gjestadressefeltet føreset at gjesten brukar den innebygde DHCP-tildelinga til NAT-motoren. Viss gjesten i staden brukar ei statisk adresse, oppgi den adressa i regelen. Den siste 1080 er tenesteporten til gjesten; han treng ikkje vera lik vertsporten.

Lyttaren i gjesten er framleis ein nettverksteneste

Ein proxy som berre er bunden til 127.0.0.1 inne i gjesten, godtek gjestelokale tilkoplingar. NAT-vidaresending gjer ikkje at denne loopback-lyttaren godtek trafikk som kjem på det virtuelle grensesnittet til gjesten. Konfigurer tenesta til å lytta på eit passande gjestegrensesnitt, og lat den tiltenkte trafikken gå gjennom brannmuren til gjesten og tilgangsreglane til proxyen. Kontroller tillaten og avvist tilgang for lyttaren etter at du har endra den grensa.

Når det mislukkast, gransk desse grensene kvar for seg: vertsporten og regelen, den valde gjestadressa og lyttaren inne i gjesten. Å byta til bru-nettverk kan ikkje reparera ei teneste som framleis berre lyttar på loopbacken til gjesten.

Denne TCP-regelen dekkjer ei SOCKS-tilkopling over TCP. Han gjev ikkje i seg sjølv den ekstra UDP-vegen som eit SOCKS5 UDP-relay treng.

Relaterte artiklar