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 220.127.116.11 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.
Getting an overview of your situation¶
VM has a public IPv4 address on SRV:
$ ping myvm00.fcio.net PING myvm00.fcio.net (18.104.22.168): 56 data bytes 64 bytes from 22.214.171.124: icmp_seq=0 ttl=57 time=29.110 ms 64 bytes from 126.96.36.199: 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.
VM has a public IPv4 address¶
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.
VM has a private IPV4 address but you have native IPv6 from your ISP¶
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.
VM has a private IPv4 and you do not have native IPv6¶
This is the tricky part: the VM is only accessible via IPv6 directly from the outside but you don’t have it yet.
Using an IPv4 SSH jump host¶
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.gocept.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.
Using a private OpenVPN server¶
If a project has an OpenVPN server available (
role), tunneling through a VPN connection may be a convenient alternative.
Using IPv6 rapid deployment options¶
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!