Fan Lin

@zzsoszz 把 `registry.cn-hangzhou.aliyuncs.com/rdc-incubator/kt-connect-shadow:v0.3.6` 和 `registry.cn-hangzhou.aliyuncs.com/rdc-incubator/kt-connect-router:v0.3.6` 两个镜像推到内网仓库，其中的 `v0.3.6` 需要和使用的 ktctl 工具版本匹配。 执行 connect 和 mesh 命令的时候相应加上 `--image` 和 `--routerImage` 参数，可以用 `ktctl config` 命令设置默认参数，如果在企业内多人使用的话，也可以参考 https://alibaba.github.io/kt-connect/#/zh-cn/reference/customize 文档把配置内置到 ktctl 二进制文件里

这种情况正常应该会触发自动重连，如果不是持续发生的话，可能只是网络抖动原因

这个问题不太好排查，exit status 99 在 sshuttle 里代表“未知错误“，就是运行环境检查都通过，但是进程异常奔溃。通常还是由于特定的环境问题，但没有现场的话不太好处理。 是什么原因不能使用默认的 tun 模式呢？

是个已知问题，Linux下默认的`localDNS`网络模式会修改全局iptables规则将所有DNS请求从定向给ktctl进程，ktctl将作为原DNS服务的子级DNS服务使用，在ktctl进程正常退出时会还原相应的网络配置。 如果此时ktctl进程异常退出或无法与原网络的DNS服务器通信，则会导致无法解析原DNS包含的域名，可以在ktctl connect退出后通过ktctl clean命令手动还原本地网络配置。直接使用--dnsMode=hosts模式运行ktctl connect也是一种可取的办法，这种模式不会修改本地iptables规则。

正常情况下应该总是会添加所有Service和Pod的路由规则的，和选择哪一种DNS Mode无关。 可以提供一下 --debug 参数的日志，观察一下日志中添加的路由IP段是否覆盖了所需的Pod和Service的IP地址。 如果确实没有覆盖，在查明原因之前，可以先通过 `ktctl config set connect.include-ips=` 命令设置默认包含的额外IP段地址，可以免去每次执行connect命令时使用`--includeIps`参数。

目前的逻辑是会先尝试在集群范围内查询Service的IP地址，如果权限不足，就默认只查询当前Namespace内的Service IP地址。 这里可以考虑加增加一个`--includeNamespaces`参数，来处理介于两者之间的情况，也就是说具有除当前Namespace以外的某些Namespace的权限，但又不具有整个集群权限。放到下个版本里吧。

启动时候加一个 `--excludeIps 10.31.0.0/16` 参数先绕过一下。这个是一个已知的路由合并BUG，在某些环境下会导致API Server所在的IP段被误纳入为集群IP范围，导致Port Forward失败。 近期会发布beta版本修复。

我这儿目前没有可做测试的 windows 7 环境，按golang官方issue的方法修改了一版，试试看是否可行？ https://github.com/alibaba/kt-connect/blob/master/pkg/kt/util/system_windows.go

目前不支持

这种一般是企业用了定制版的Windows系统，禁用了创建虚拟网卡功能。 只能加 `--disableTunDevice` 参数然后自行给需要访问集群网络的服务配置代理了