Atteindre un serveur SOCKS dans un invité NAT de VirtualBox
Redirigez un port loopback de l'hôte vers le proxy de l'invité et vérifiez que l'écouteur de l'invité accepte les connexions sur son interface réseau virtuelle.
Un service SOCKS dans un invité VirtualBox a deux exigences d'accessibilité distinctes : VirtualBox doit livrer la connexion à l'invité, et le service de l'invité doit l'accepter.
Pour une VM dont le premier adaptateur utilise un NAT ordinaire, VirtualBox 7.1 documente une règle de redirection de port sous cette forme. VM arrêtée :
VBoxManage modifyvm "Proxy VM" --nat-pf1 "socks,tcp,127.0.0.1,1080,,1080"
Remplacez le nom de la VM et les ports selon les besoins. L'application hôte sélectionne ensuite SOCKS sur 127.0.0.1:1080. Lier le côté hôte à 127.0.0.1 limite ce point d'entrée à l'hôte lui-même.
Le champ d'adresse d'invité vide suppose que l'invité utilise l'attribution DHCP intégrée du moteur NAT. Si l'invité utilise plutôt une adresse statique, indiquez cette adresse dans la règle. Le 1080 final est le port du service de l'invité ; il n'a pas besoin d'être égal au port de l'hôte.
L'écouteur de l'invité reste un service réseau
Un proxy lié uniquement à 127.0.0.1 dans l'invité accepte les connexions locales à l'invité. La redirection NAT ne fait pas accepter à cet écouteur loopback le trafic qui arrive sur l'interface virtuelle de l'invité. Configurez le service pour écouter sur une interface d'invité appropriée et autorisez le trafic prévu à travers le pare-feu de l'invité et les règles d'accès du proxy. Vérifiez les accès autorisés et refusés de l'écouteur après avoir modifié cette frontière.
En cas d'échec, examinez ces frontières séparément : le port et la règle de l'hôte, l'adresse d'invité choisie et l'écouteur dans l'invité. Passer à un réseau ponté ne peut pas réparer un service qui n'écoute toujours que sur le loopback de l'invité.
Cette règle TCP couvre une connexion SOCKS via TCP. Elle ne fournit pas à elle seule le chemin UDP supplémentaire dont un relay SOCKS5 UDP a besoin.