-
|
Version Problem
I have added & re-added the node trying various configurations but have not yet managed to get it to work. Configuration
I also have a domain with A records for both VM config file
teleport:
nodename: name
data_dir: /var/lib/teleport
log:
output: /var/lib/teleport/teleport.log
severity: DEBUG
format:
output: text
ca_pin: []
auth_service:
enabled: "yes"
cluster_name: hostname.com
proxy_protocol: on
authentication:
type: github
listen_addr: 0.0.0.0:3025
ssh_service:
enabled: "yes"
listen_addr: 0.0.0.0:3022
labels:
env: admin
commands:
- name: hostname
command: [hostname]
period: 1m0s
- name: arch
command: ['/bin/uname', '-p']
period: 1h0m0s
port_forwarding: true
proxy_service:
enabled: "yes"
proxy_protocol: on
listen_addr: 0.0.0.0:3023
tunnel_listen_addr: 0.0.0.0:3024
web_listen_addr: 0.0.0.0:443
public_addr: hostname.com:443
https_keypairs: []
acme:
enabled: "yes"
email:[email protected]
app_service:
enabled: no
kubernetes_service:
enabled: no
db_service:
enabled: noI also have a raspberry pi running on my home network behind NAT which I would like to be able to connect to from outside my home network, proxying into a reverse tunnel through the teleport proxy service running on the above VM. I tried adding the rpi using the directions here. I seemingly successfully added the node to the cluster (it appears when I run rpi config file
teleport:
nodename: raspberrypi
data_dir: /var/lib/teleport
auth_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ca_pin: "sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
advertise_ip: raspberrypi.local
auth_servers:
- hostname.com
log:
output: /var/lib/teleport/teleport.log
severity: DEBUG
format:
output: text
auth_service:
enabled: no
ssh_service:
enabled: yes
listen_addr: 0.0.0.0:3022
labels:
env: NAT
commands:
- name: hostname
command: [hostname]
period: 1m0s
- name: arch
command: ['/bin/uname', '-p']
period: 1h0m0s
port_forwarding: true
proxy_service:
enabled: no
app_service:
enabled: no
kubernetes_service:
enabled: no
db_service:
enabled: noHere is the log file on the rpi: rpi log file in /var/lib/teleport/teleport.log
2021-10-21T18:00:38-04:00 DEBU [PROC:1] Adding service to supervisor. service:register.node service/supervisor.go:201 Important note: I had to differ from the NAT instructions when running the command to add the rpi to the cluster, because when using
If I start it with rpi log file in /var/lib/teleport/teleport.log
2021-10-22T09:44:15-04:00 [PROC:1] DEBU Adding service to supervisor. service:register.node service/supervisor.go:201 From the logs it actually looks like it tries to set up a reverse tunnel. The From the rpi I can use telnet to verify I can connect to Any help or troubleshooting tips would be greatly appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
I think the fundamental issue is that the cluster name has to be a subdomain of your domain, like
which is similar to this issue: #7938 and I suspect I am just getting throttled by letsencrypt. So I will try again next week. |
Beta Was this translation helpful? Give feedback.
-
|
@ahelwer , when you connect just via Can you confirm that both 3080 and 3024 are reachable from the raspberrypi node with |
Beta Was this translation helpful? Give feedback.
-
|
@AHARIC thank you for your reply. I have validated that I can connect to 3080 and 3024 via telnet from the rpi. I also upgraded to teleport 7.3.3. I am now running my auth/proxy server with the following configuration, so I access the cluster management webpage on Auth/proxy server config
teleport:
nodename: avalanche
data_dir: /var/lib/teleport
log:
#output: /var/lib/teleport/teleport.log
output: stdout
severity: DEBUG
format:
output: text
ca_pin: []
advertise_ip: 10.0.0.4
auth_service:
enabled: "yes"
cluster_name: teleport.hostname.com
proxy_protocol: on
authentication:
type: local
second_factor: off
listen_addr: 0.0.0.0:3025
ssh_service:
enabled: "yes"
listen_addr: 0.0.0.0:3022
labels:
env: admin
commands:
- name: hostname
command: [hostname]
period: 1m0s
- name: arch
command: ['/bin/uname', '-p']
period: 1h0m0s
port_forwarding: true
proxy_service:
enabled: "yes"
proxy_protocol: on
listen_addr: 0.0.0.0:3023
tunnel_listen_addr: 0.0.0.0:3024
web_listen_addr: 0.0.0.0:3080
public_addr: teleport-proxy.hostname.com:3080
https_keypairs: []
acme:
enabled: "yes"
email: [email protected]
app_service:
enabled: "no"
kubernetes_service:
enabled: "no"
db_service:
enabled: "no"I put the following config on the rpi, so it tries to connect to auth server rpi config
teleport:
nodename: raspberrypi
data_dir: /var/lib/teleport
auth_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ca_pin: "sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
advertise_ip: raspberrypi.local
auth_servers:
- teleport-proxy.hostname.com:3080
log:
#output: /var/lib/teleport/teleport.log
output: stdout
severity: DEBUG
format:
output: text
ssh_service:
enabled: yes
listen_addr: 0.0.0.0:3022
labels:
env: NAT
commands:
- name: hostname
command: [hostname]
period: 1m0s
- name: arch
command: ['/bin/uname', '-p']
period: 1h0m0s
port_forwarding: true
auth_service:
enabled: no
proxy_service:
enabled: no
app_service:
enabled: no
kubernetes_service:
enabled: no
db_service:
enabled: nohowever, trying to add the rpi to the cluster produces the following error: rpi error output
cc @webvictim |
Beta Was this translation helpful? Give feedback.
-
|
@ahelwer It looks like you already have a client certificate cached on the Pi (shown in the logs by: Try stopping the Teleport process, removing |
Beta Was this translation helpful? Give feedback.
-
|
@webvictim that worked! I can now tunnel into my rpi. Thanks for all the help! |
Beta Was this translation helpful? Give feedback.
-
|
No problem! Glad we got there in the end. |
Beta Was this translation helpful? Give feedback.
-
|
The key part here (as @AHARIC touched on) is that if you don't specify a port for your |
Beta Was this translation helpful? Give feedback.
The key part here (as @AHARIC touched on) is that if you don't specify a port for your
auth_serversconfiguration, Teleport assumes 3025 and will not use node tunnelling. It's only when joining to a proxy (via 3080/443) than node tunnelling is enabled.