Fix teleport parsing to support IPV6

[klizhentas]

This commit fixes #2124

[russjones]

Couple of things I ran into while testing this PR, have not looked at the code yet.

---

If advertise_ip is localhost like this: advertise_ip: "::1", when I run tsh ls, I get IPv4 output.

$ tsh ls
Node Name Address        Labels                           
--------- -------------- -------------------------------- 
server01  127.0.0.1:3022 arch=x86_64, cluster=example.com 

---

If I set both advertise_ip and listen_addr to the loopback address like this: advertise_ip: "::1" and listen_addr: "[::1]:3022", I can't connect to the node, and it appears Teleport might be using the IPv4 address to connect (see above)?

$ tsh ssh server01
error: "failed connecting to node server01.
Original Error: *net.OpError dial tcp 127.0.0.1:3022: connect: connection refused

---

If I set advertise_ip to the loopback address like this: advertise_ip: 0:0:0:0:0:0:0:1, it doesn't allow me to login when when I try to login to ::1, which is the same address.

I suspect it's because 0:0:0:0:0:0:0:1 gets hard coded into the certificate, but in general that makes IPv6 address handling brittle, especially if the caller is not a human. We can tell a human to always used either the abbreviated form or full form, but the caller is another piece of software (for example Ansible), it may use either format.

This doesn't just apply to the loopback address, for example, 2001:0db8:0000:0000:0000:ff00:0042:8329 and 2001:db8::ff00:42:8329 are the same.

$ tsh ssh ::1
error: access denied to rjones connecting to ::1 on cluster example.com

---

If advertise_ip is set to the address of the interface, like this: advertise_ip: "1111::2222:3333:4444:5555" where the IPv6 address is the legitimate output of ifconfig -a, I get the following in the Web UI when I try and connect to a node.

disconnected
failed connecting to node server01.
Original Error: *net.OpError dial tcp [1111::2222:3333:4444:5555]:3022: connect: invalid argument

---

If I set advertise_ip and listen_addr to the address of my interface, like this: advertise_ip: "1111::2222:3333:4444:5555" and listen_addr: "[1111::2222:3333:4444:5555]:3022", then Teleport refuses to start.

ERROR REPORT:
Original Error: *net.OpError listen tcp [1111::2222:3333:4444:5555]:3022: bind: invalid argument

[klizhentas]

If advertise_ip is localhost like this: advertise_ip: "::1", when I run tsh ls, I get IPv4 output.

This (and probably some other problems you have encountered) is because ::1 is classified as a localhost address and you are getting it replaced with our heartbeat logic. So you might want to try with some other synthetic IPV6 address. I'd probably need to do more testing too with various types of IPV6 addresses

[klizhentas]

You invalid argument probably is an OS level error, with a wrong IPV6 format?

[russjones]

@klizhentas You're right about the address not having an valid IPv6 format, it was missing the interface in listen_addr. I was able to start Teleport with the below configuration.

teleport:
  advertise_ip: "1111::2222:3333:4444:5555"

ssh:
   listen_addr: "[1111::2222:3333:4444:5555%eth0]:3022"

With the above two set, Teleport will start, but I can't connect to a host. I wonder if it's because the Dial does not occur with the interface scope?

disconnected                                                                                                                                                                                                                     
failed connecting to node server01.                                                                                                                                                                                              
Original Error: *net.OpError dial tcp [1111::2222:3333:4444:5555]:3022: connect: no route to host                                                                                                                                  

[klizhentas]

@russjones yes, no route to host usually means a routing problem or firewall issue that could block packets and return this vague error - you can set up tcpdump and check it out on the wire, could be as easy as adding a routing table entry.

[russjones]

@klizhentas Turns out it's because the address I was trying to connect to was a link-local address (fe80 prefix) which requires the interface as well so the address had to look like fe80::2222:3333:4444:5555%eth0.

[klizhentas]

retest this please