using vnet ssh from tsh - not resolving to 100.64.x.y IP

[uedvt359]

I'm (still) trying to setup vnet for ssh, using tsh.exe (v17.7.1). the problem I'm facing is that the vnet.teleport.example.org zone is not resolved by the vnet service, but falls back to the cluster's wildcard dns entry in the global dns.
I'm noticing that there is no connection-specific DNS suffix set by the TeleportVNet virtual network adapter. is that the problem? if so, how can i fix that?

I've generated the ssh config with tsh vnet-ssh-autoconfig:

# ---------------------------------------------------------------------
# THIS FILE IS AUTOMATICALLY GENERATED BY TELEPORT VNET. DO NOT EDIT.
# Your changes will be overwritten the next time the file is generated.
# ---------------------------------------------------------------------

Host *.teleport.example.org
    IdentityFile "C:\\Users\\user\\.tsh\\id_vnet"
    GlobalKnownHostsFile "C:\\Users\\user\\.tsh\\vnet_known_hosts"
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking yes
    IdentitiesOnly yes

and I'm starting the vnet service in a background shell:

C:\Users\user>tsh vnet
VNet is ready.

my vnet server config looks like this (my cluster name is teleport.example.org):

kind: vnet_config
version: v1
metadata:
  name: vnet-config
spec:
  custom_dns_zones:
  - suffix: vnet.teleport.example.org

when I try to connect to a host, it tries to connect to the cluster's IP address (10.10.10.10) - not the vnet subnet (100.64.x.y)

C:\Users\user>ssh -v root@myserver.example.org.vnet.teleport.example.org
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
debug1: Reading configuration data C:\\Users\\user/.ssh/config
debug1: Reading configuration data C:/Users/user/.tsh/vnet_ssh_config
debug1: C:/Users/user/.tsh/vnet_ssh_config line 6: Applying options for *.teleport.example.org
debug1: Connecting to myserver.example.org.vnet.teleport.example.org [10.10.10.10] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\user\\.tsh\\id_vnet type 3
debug1: identity file C:\\Users\\user\\.tsh\\id_vnet-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to myserver.example.org.vnet.teleport.example.org as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:...........................................
No ED25519 host key is known for myserver.example.org.vnet.teleport.example.org and you have requested strict checking.
Host key verification failed.

C:\Users\user>

ipconfig shows a vnet adapter:

Unbekannter Adapter TeleportVNet:

   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : fd7f:...::1
   Verbindungslokale IPv6-Adresse  . : fe80::...%24
   IPv4-Adresse  . . . . . . . . . . : 100.64.0.1
   Subnetzmaske  . . . . . . . . . . : 255.192.0.0
   Standardgateway . . . . . . . . . :

[uedvt359]

I guess the problem is that tsh vnet hasn't started a DNS server:

C:\Users\user>netstat -a|findstr 100.64
  TCP    100.64.0.1:139         myhostname:0      ABHÖREN
  UDP    100.64.0.1:137         *:*
  UDP    100.64.0.1:138         *:*

(filtering on :53 returns nothing either)

[uedvt359]

that was a red herring, the vNet DNS server is running on 100.64.0.2 and responds to nslookup commands directed to it. i've looked at issue 56060, but the registry entries look OK too. yet, neither ssh.exe, nor putty seem to use the vnet DNS service, but the normal host provided one.

[zmb3]

Is there a particular reason you're trying to use a custom_dns_zone for what is already your cluster domain? Custom zones are meant for cases where you want to override other public DNS. I wouldn't expect you to need a custom zone in this case at all.

[uedvt359]

I was following this part of the documentation, and I interpreted that as mandatory. I'll gladly remove it, though :)

[nklaassen]

VNet SSH does not use custom DNS zones, those are for apps only. Each SSH server should be available at <hostname>.<clustername>, so in your example I'd try ssh -v root@myserver.teleport.example.org. Make sure the suffix teleport.example.com matches the one in ~/.tsh/vnet_ssh_config.

If that doesn't work can you run the following in powershell while VNet is running?

> Get-DnsClientNrptRule
> Get-DnsClientNrptPolicy
> Resolve-DnsName myserver.teleport.example.org

[nklaassen]

in v17 you can also find logs from the VNet service in logs.txt in the same directory as tsh.exe

[uedvt359]

Each SSH server should be available at ., so in your example I'd try ssh -v root@myserver.teleport.example.org.

here's my resource definition:

metadata:
  name: 1b268de8-65e0-8404-e202-422ac1621457
spec:
  addr: 10.10.10.10:22
  hostname: myserver.intranet.local

I tried the following combinations, neither get resolved to a 100.64/16 IP by the vnet DNS service:

• myserver.teleport.example.org
• myserver.intranet.local.teleport.example.org
• myserver.intranet.local
• 1b268de8-65e0-8404-e202-422ac1621457.teleport.example.org

Make sure the suffix teleport.example.com matches the one in ~/.tsh/vnet_ssh_config.

yes, it matches. ssh -v even shows that it executed that part of the config.

If that doesn't work can you run the following in powershell while VNet is running?

PS C:\Users\user> Get-DnsClientNrptRule


Name                             : {ad074e9a-bd1b-447e-9108-14e545bf11a5}
Version                          : 1
Namespace                        : {.intranet.local, .teleport.example.org}
IPsecCARestriction               :
DirectAccessDnsServers           :
DirectAccessEnabled              : False
DirectAccessProxyType            :
DirectAccessProxyName            :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   :
NameServers                      : {fd83:b646:ec40::2, 100.64.0.2}
DnsSecEnabled                    : False
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         :
DnsSecValidationRequired         :
NameEncoding                     : Disable
DisplayName                      :
Comment                          :



PS C:\Users\user> Get-DnsClientNrptPolicy
PS C:\Users\user> # above command returned nothingnothing

Resolve-DnsName of any of the four previously mentioned hostname permutations all return either the teleport proxy IP or the server's "real" IP. I also get the same results with nslookup $host 100.64.0.2.