On Fri, Jul 07, 2017 at 01:17:54PM +1000, NeilBrown wrote: > On Fri, Jun 30 2017, Chuck Lever wrote: > > > > Wouldn't it be nicer if it worked like this: > > > > (guest)$ cat /etc/hosts > > 129.0.0.2 localhyper > > (guest)$ mount.nfs localhyper:/export /mnt > > > > And the result was a working NFS mount of the > > local hypervisor, using whatever NFS version the > > two both support, with no changes needed to the > > NFS implementation or the understanding of the > > system administrator? > > Yes. Yes. Definitely Yes. > Though I suspect you mean "127.0.0.2", not "129..."?? > > There must be some way to redirect TCP connections to some address > transparently through to the vsock protocol. > The "sshuttle" program does this to transparently forward TCP connections > over an ssh connection. Using a similar technique to forward > connections over vsock shouldn't be hard. Thanks for the sshuttle reference. I've taken a look at it and the underlying iptables extensions. sshuttle does not have the ability to accept incoming connections but that can be achieved by adding the IP to the loopback device. Here is how bi-directional TCP connections can be tunnelled without network interfaces: host <-> vsock transport <-> guest 129.0.0.2 (lo) 129.0.0.2 (lo) 129.0.0.3 (lo) 129.0.0.3 (lo) iptables REDIRECT is used to catch 129.0.0.2->.3 connections on the host and 129.0.0.3->.2 connections in the guest. A "connect" command is then sent across the tunnel to establish a new TCP connection on the other side. Note that this isn't NAT since both sides see the correct IP addresses. Unlike using a network interface (even tun/tap) this tunnelling approach is restricted to TCP connections. It doesn't have UDP, etc. Issues: 1. Adding IPs to dev lo has side effects. For example, firewall rules on dev lo will affect the traffic. This alone probably prevents the approach from working without conflicts on existing guests. 2. Is there a safe address range to use? Using IPv6 link-local addresses as suggested in this thread might work, especially when using an OUI so we can be sure there are no address collisions. 3. Performance has already been mentioned since a userspace process tunnels from loopback TCP to the vsock transport. splice(2) can probably be used. Stefan
Attachment:
signature.asc
Description: PGP signature
