Proxy peering docs should mention DNS requirements

stevenGravy commented 11 months ago

Applies To

https://goteleport.com/docs/architecture/proxy-peering/ https://goteleport.com/docs/management/operations/proxy-peering/

Details

Proxy peering relies on using DNS resolution for agents and users to connect to. These guides do not describe that DNS configuration is required for that, typically split dns. That proxies should be reachable by regions or logical networks.

How will we know this is resolved?

A reader will understand that peer proxying has Proxies deployed separately. DNS resolution is required. A architecture diagram of that would help.

programmerq commented 11 months ago

DNS must be set up for Teleport proxies whether proxy peering is enabled or not. Can you elaborate on the use case a bit?

pschisa commented 11 months ago

I think the intention is to emphasize that the use of proxy peering requires control over the DNS record for the Teleport Cluster to be latency/geo based or split along a single endpoint. There is not an option for example to have different public addresses for the different proxies and still use proxy peering.

flybyray commented 2 months ago

@programmerq i guess the essential detail "typically split dns" . which is a term in vpn environments. i have a typical issue with teleport client in such environment. The teleport client produces a message like this

running tsh -d --proxy=teleport.example.com:3080 --auth=local --user=username ls

ERROR REPORT:
Original Error: *interceptors.RemoteError connection error: desc = &#34;transport: Error while dialing: failed to dial: unable to establish proxy stream\n\trpc error: code = Unavailable desc = connection error: desc = \&#34;transport: Error while dialing: dial tcp: lookup teleport.example.com on 192.168.1.1:53: no such host\&#34;&#34;
Stack Trace:
    github.com/gravitational/teleport/api@v0.0.0/client/client.go:3895 github.com/gravitational/teleport/api/client.(*Client).ListUnifiedResources
    github.com/gravitational/teleport/api@v0.0.0/client/client.go:3961 github.com/gravitational/teleport/api/client.GetUnifiedResourcePage
    github.com/gravitational/teleport/lib/client/api.go:2420 github.com/gravitational/teleport/lib/client.(*TeleportClient).ListNodesWithFilters
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:2184 github.com/gravitational/teleport/tool/tsh/common.onListNodes.func1
    github.com/gravitational/teleport/lib/client/api.go:591 github.com/gravitational/teleport/lib/client.RetryWithRelogin
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:2183 github.com/gravitational/teleport/tool/tsh/common.onListNodes
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:1414 github.com/gravitational/teleport/tool/tsh/common.Run
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:605 github.com/gravitational/teleport/tool/tsh/common.Main
    github.com/gravitational/teleport/tool/tsh/main.go:26 main.main
    runtime/proc.go:271 runtime.main
    runtime/asm_amd64.s:1695 runtime.goexit
User Message: connection error: desc = &#34;transport: Error while dialing: failed to dial: unable to establish proxy stream\n\trpc error: code = Unavailable desc = connection error: desc = \&#34;transport: Error while dialing: dial tcp: lookup teleport.example.com on 192.168.1.1:53: no such host\&#34;&#34;

The problem here is that this teleport.example.com is resolvable for all other applications but not teleport client itself. dig teleport.example.com on the same host were tsh ls was invoked outputs:

; <<>> DiG 9.18.24-1-Debian <<>> teleport.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11407
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;teleport.example.com.  IN  A

;; ANSWER SECTION:
teleport.example.com. 1534 IN   A   10.11.1.11

;; Query time: 23 msec
;; SERVER: 192.168.9.1#53(192.168.9.1) (UDP)
;; WHEN: Fri Jul 12 13:21:37 CEST 2024
;; MSG SIZE  rcvd: 71

From this you can see that normal dns queries go against a DNS server 192.168.9.1 on different subnet (subnet provided by vpn).

It would be cool if a workarround to call the ip directly would work: tsh -d --proxy=10.11.1.11:3080 --auth=local --user=username ls BUT it will not and produces this certificate error

ERROR REPORT:
Original Error: *url.Error Get &#34;https://10.11.1.11:3080/webapi/ping/local&#34;: tls: failed to verify certificate: x509: cannot validate certificate for 10.11.1.11 because it doesn&#39;t contain any IP SANs
Stack Trace:
    github.com/gravitational/teleport/api@v0.0.0/client/webclient/webclient.go:143 github.com/gravitational/teleport/api/client/webclient.doWithFallback
    github.com/gravitational/teleport/api@v0.0.0/client/webclient/webclient.go:217 github.com/gravitational/teleport/api/client/webclient.Ping
    github.com/gravitational/teleport/lib/client/api.go:4424 github.com/gravitational/teleport/lib/client.(*TeleportClient).Ping
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:3692 github.com/gravitational/teleport/tool/tsh/common.makeClientForProxy
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:3655 github.com/gravitational/teleport/tool/tsh/common.makeClient
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:2174 github.com/gravitational/teleport/tool/tsh/common.onListNodes
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:1414 github.com/gravitational/teleport/tool/tsh/common.Run
    github.com/gravitational/teleport/tool/tsh/common/tsh.go:605 github.com/gravitational/teleport/tool/tsh/common.Main
    github.com/gravitational/teleport/tool/tsh/main.go:26 main.main
    runtime/proc.go:271 runtime.main
    runtime/asm_amd64.s:1695 runtime.goexit
User Message: Get &#34;https://10.11.1.11:3080/webapi/ping/local&#34;: tls: failed to verify certificate: x509: cannot validate certificate for 10.11.1.11 because it doesn&#39;t contain any IP SANs

i guess i need to update the teleport certificates.

gravitational / teleport