Connecting to VMs¶
Generally you can connect to VMs on their “SRV” interface from the outside by calling:
$ ssh myvm00.fcio.net Last login: Wed Feb 19 14:54:07 CET 2014 from 126.96.36.199 on pts/0 Welcome to the Flying Circus!
However, due to a shortage of IPv4 addresses and an unpredictable status of IPv6 deployments, this might not work out of the box. Let’s go through a couple of options you have, if the example above does not work out of the box.
VM has a public IPv4 address on SRV:
$ ping myvm00.fcio.net PING myvm00.fcio.net (188.8.131.52): 56 data bytes 64 bytes from 184.108.40.206: icmp_seq=0 ttl=57 time=29.110 ms 64 bytes from 220.127.116.11: icmp_seq=1 ttl=57 time=25.364 ms ^C --- myvm00.fcio.net ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 25.364/27.237/29.110/1.873 ms
VM has a private IPv4 address on SRV:
$ ping myvm00.fcio.net ping: cannot resolve myvm00.fcio.net: Unknown host
VM is accessible through IPv6:
$ ping6 myvm00.fcio.net PING6(56=40+8+8 bytes) 2002:5e87:9a92:1:687c:1601:8692:c1e9 --> 2a02:238:f030:103::1d 16 bytes from 2a02:238:f030:103::1d, icmp_seq=0 hlim=59 time=27.642 ms 16 bytes from 2a02:238:f030:103::1d, icmp_seq=1 hlim=59 time=26.238 ms 16 bytes from 2a02:238:f030:103::1d, icmp_seq=2 hlim=59 time=25.941 ms ^C --- myvm00.fcio.net ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 25.941/26.607/27.642/0.742 ms
VM is not accessible through IPv6:
$ ping6 myvm00.fcio.net ping6: UDP connect: No route to host
If you get a result that isn’t shown here, please contact our support and we’ll amend this list.
Everything should be fine: independently of whether your ISP provides you with IPv4 and/or IPv6 you should be able to connect. If not: please contact our support.
Excellent! You should be able to connect as IPv6 will automatically pick up where IPv4 dropped the ball. If you can not connect in this scenario: please contact our support.
This is the tricky part: the VM is only accessible via IPv6 directly from the outside but you don’t have it yet.
SSH can perform complex connection setups including proxying through other machines. Fortunately there will always be at least one public IPv4 address that is accessible to you and you can use this to connect to the machine you actually want to go to.
Put the following in your
~/.ssh/config to enable transparent SSH jump
Host *.gocept.net User <USERNAME> ProxyCommand ssh flyingcircus-jump-host -W %h:%p Host *.fcio.net User <USERNAME> ProxyCommand ssh flyingcircus-jump-host -W %h:%p Host flyingcircus-jump-host HostName <VMNAME>.fe.rzob.ipv4.fcio.net User <USERNAME> ProxyCommand none
Remember to replace <VMNAME> with the name of a VM that has a public frontend IPv4 address configured. It doesn’t matter which other VM you connect to. Also, replace <USERNAME> with the unix username that you are using in the Flying Circus.
If a project has an OpenVPN server available (External network gateway role), tunneling through a VPN connection may be a convenient alternative.
Even if your provider does not provide you with IPv6 there is a good chance you can easily get IPv6 with one of the following “rapid deployment” options.
The technologies we recommend are:
6to4 which works in many cases and is supported by Linux, Windows, Mac OS X and many routers. You can often turn this on for your whole office network by simply setting an “Enable 6to4” option in your router.
Teredo tunneling may be a last-resort option that can be configured on individual machines and is supported on Windows and Linux.
Traditional IP tunnels, like provided by Tunnelbroker are also an option, although their performance and reliability varies.
IPv6 deployment is gaining traction but the rapid deployment options are unreliable at times. Check above options or let us know if you found a solution that worked better for you. If you struggle, please contact our support: we’re here to help you through the hard times of IPv4 exhaustion!