[lago-devel] Bridge Networking

[Barak Korren]

>>
>> Can you help me visualize what this would look like from a code or user
>> perspective? Right now I have it reduced to "run this script" and
>> environment gets setup and installation steps occur. Ideally, that same
>> script would setup or configure whatever is needed so a developer just hits
>> the IP in their browser and is off and running.

If you bridge the VMs directly to the external network, you would need
to to apply external network IP configuration for the VMs, which may
or may not be simple depending on how the external network is
configured. (If this is what vagrant does, then the fact that it
worked for many developers so far is just sheer luck)

Any names or IPs the external network would assign to the VMs can be
completely random, the external DHCP may also just refuse to assign
anything, the developer may even run his setup on a network without
DHCP, that would force him to somehow manually assign an external IP
to the VM running Satellite.

Since Satellite is running on a VM it knows nothing about the hostname
and IP of the underlying host, if we want the developer to eventually
enter the host address in his browser, we could perhaps, use NAT or
HTTP reverse proxy to expose ports from the VM on the host, but
fully-qualified URLs in links or redirects sent from the app will not
function properly since they will point to the VM hostname which is
unknown on the external network.

You can vision the situation like this - the dev laptop is attached to
the "internet" while the Lago network is a closed separate network
sitting behind a firewall. Host names and addresses on the Lago
network are not and cannot be exposed to "the internet". To allow the
dev laptop to work against the VMs you need something that essentially
behaves like a VPN, so its hard to avoid any setup on the dev laptop.

>
> For the ports, just adding an option to the nets specifying with ports to
> forward to which ips/vms
>
>
> For the ssh tunnel, you have to start it from your laptop to the machine that
> is running lago, something like:
>
>    ssh -D 8888 -Nf lago_machine
>    # the -N is for not running any command, -f is to go to background
>
> That will start a socks proxy at 127.0.0.1:8888 (in your laptop) that you can
> setup in your browser as proxy, and will forward any traffic through it, so
> pointing your browser to the internal vm ip/name should work.
>

This solution may work but I think there will be an issue with name
resolution because the SSHD running on the host AFAIK does not know to
resolve names against the Lago internal DNS. Also I'm not sure
browsers know how to resolve hostnames via socks proxies in the same
manner they know to resolve via HTTP froward proxies.

I now remembr that the way it worked for me was that I had configure
MDNS on all the VMs and the host so that multicast name resolution was
working through the Lago bridges, this solution is not applicable to
the general case. What we need is a proxy process, running on the
host, that is attached to the external network on one end and to the
Lago internal one on the other, and is configured to resolve names
against the internal Lago DNS.

There are a few challenges here especially if you don't want to modify
the outside-visible configuration of the host (for example
'/ets/resolv.conf' on the host may be DHCP-managed so you cannot
change it).

With some scripting, the end-user experience could come down to:
1. Run our script on the beefy host
2. Go to we page on the beefy host that would setup the VPM/proxy
seeting for you.

I think there may be an interesting Lago feature we could have here -
Have a 'lago proxy' or 'lago vpn' command to expose a Lago network via
a proxy or a vpn.

-- 
Barak Korren
bkorren at redhat.com
RHEV-CI Team