Hi Boris, On Wed, 2018-11-14 at 11:38 +0900, Boris Morozov wrote: > Hello, dear friends. I would like a share idea with you about new feature. > Please forgive me if i wrong. > > Current approach to publish ports from virtual machine is connecting it to > network by network adapter. > > In this case administrator should to write: > - Routes > - DNS-records > - Firewall rules > > In final result: > - Virtual machine start going to Internet from host local or ISP network. > - Virtual machine user can attack gateways and peer nodes in host network. > - Virtual machine user can attack global sites, services and leave host IP it > will raise problems with owners of attacked sites and services, authorities. > - Virtual machine user can download illegal or forbidden content and leave > host IP it will raise problems with authorities. > - Virtual machine can be attacked from other nodes in host network and > internet. > Internet gateway on host network should open extra ports to perform access to > virtual machine. > - Some computing power of host is begin to spent on NIC and network > emulation. > - Some time of administrator was spent to configuring and testing routing, > dns, firewall.
All of these are standard and both software and people are used to it. I dare say that it's actually a feature in most cases as administrators need to keep track of network metadata. Anyway... > > To avoid this responibility and performance problems and reduce time on > configuration when public access to virtual machine not needed it's better > way to tunnel ports on virtual machine from guest and vice-versa by SPICE. > You're introducing extra latency and limitation on network bandwidth when connecting to outside networks as network traffic from the VM has to hairpin through client computer. > In case of port tunneling over SPICE > > 1. In virtual machine running services and they opened ports (HTTP, SSH for > example) on localhost (127.0.0.1). > 2. Spice guest agent in virtual machine open client-port and become ready to > connect to services ports from client-port and redirect data to spice > channel. > 3. In other end of spice channel on client spice client open ports for > listening incoming connections on client localhost (127.0.0.1). > 4. Client user connect to tunneled ports on client-side localhost and start > working with tunneled ports as with local ones. > 5. Spice client & guest agent perform traffic redirection. > > As we can see offered approach is more simple. It can't be used against > traditional approach in public access but in personal access it's look > better. Also it's looks possible to tunnel not only localhost ports on > virtual machine and others nodes ones if network is working. > > Use cases: > - Web-browsing virtual machine sites on client machine > - Web-sites, network services (daemons) development > - Internet access in virtual machine via proxies on client (TOR, VPN, SOCKS, > HTTP) > - Monitoring (getting access to API and dashboards) of various services: > printers, miners, solar power chargers, UPS and others. > - File transfer between client and virtual machine via FTP, SFTP, HTTP > - Stream transfer between client and virtual machine video, audio and others. > - VDI-hosting (Isolated preinstalled VM without NIC) > > I think that you could use spiceport channel as a building block with TUN/TAP device attached to virtio device inside the guest. On client side, you'd have to write the connector however (similarly to file transfer or webdav features). Cheers, David _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
