K3SDNS-家庭路由器/DNS的自签名证书干扰了https/tls？ 我的笔记本电脑通过curl -sfl https://get.k3s.io |在我的笔记本电脑上运行了K3S服务器| install_k3s_exec =“ server -disable = traefik” k3s_kubeconfig_mode =“ 644” sh -s - 它有一项服务：k ...

问题描述 投票：0回答：1
有服务：

kube-dns



$ kubectl -n kube-system get svc kube-dns
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.43.0.10   <none>        53/UDP,53/TCP,9153/TCP   2d18h



和一个豆荚：
core-dns
它有我笔记本电脑的LAN IP地址的一个。

.status.podIP

我已经应用了一个吊舱：
$ kubectl -n kube-system get pod coredns-ccb96694c-7vgbs
NAME                      READY   STATUS    RESTARTS      AGE
coredns-ccb96694c-7vgbs   1/1     Running   1 (43h ago)   2d18h

$ kubectl -n kube-system get pod coredns-ccb96694c-7vgbs -o yaml | yq '.status.hostIP'
192.168.1.47

$ kubectl -n kube-system get pod coredns-ccb96694c-7vgbs -o yaml | yq '.status.podIP'
10.42.0.3




dnsutils


在pod中，它的服务是
$ kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml

服务，它似乎在Internet上找到了群集服务和域。

dnsutils
但是，当试图连接到
nameserver
时，自我签名的证书被扔进了混音中。我注意到这是我当地的家庭路由器/DNS：
kube-dns
.
$ kubectl exec -it dnsutils -- cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local lan
nameserver 10.43.0.10
options ndots:5

$ kubectl exec -it dnsutils -- dig +search kubernetes

; <<>> DiG 9.16.27 <<>> +search kubernetes
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9727
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ff387272162f5dd5 (echoed)
;; QUESTION SECTION:
;kubernetes.default.svc.cluster.local. IN A

;; ANSWER SECTION:
kubernetes.default.svc.cluster.local. 5 IN A    10.43.0.1

;; Query time: 0 msec
;; SERVER: 10.43.0.10#53(10.43.0.10)
;; WHEN: Sat Feb 01 23:07:28 UTC 2025
;; MSG SIZE  rcvd: 129

$ kubectl exec -it dnsutils -- dig google.com

; <<>> DiG 9.16.27 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34878
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d63e52df0e4e0ac8 (echoed)
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             8       IN      A       142.250.115.138
google.com.             8       IN      A       142.250.115.101
google.com.             8       IN      A       142.250.115.113
google.com.             8       IN      A       142.250.115.102
google.com.             8       IN      A       142.250.115.139
google.com.             8       IN      A       142.250.115.100

;; Query time: 31 msec
;; SERVER: 10.43.0.10#53(10.43.0.10)
;; WHEN: Sat Feb 01 23:08:52 UTC 2025
;; MSG SIZE  rcvd: 207

如果我更改pod
https://google.com
Trying
192.168.1.1
$ kubectl exec -it dnsutils -- curl -vs https://google.com
*   Trying 192.168.1.1:443...
* Connected to google.com (192.168.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
command terminated with exit code 60

$ kubectl exec -it dnsutils -- ping google.com
PING google.com (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=63 time=336.742 ms
64 bytes from 192.168.1.1: seq=1 ttl=63 time=1.167 ms
64 bytes from 192.168.1.1: seq=2 ttl=63 time=1.174 ms
64 bytes from 192.168.1.1: seq=3 ttl=63 time=1.155 ms
64 bytes from 192.168.1.1: seq=4 ttl=63 time=1.405 ms
^C
--- google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.155/68.328/336.742 ms

$ kubectl exec -it dnsutils -- traceroute google.com
traceroute to google.com (192.168.1.1), 30 hops max, 46 byte packets
 1  10.42.0.1 (10.42.0.1)  0.018 ms  0.015 ms  0.011 ms
 2  192.168.1.1 (192.168.1.1)  1.915 ms  3.907 ms  1.719 ms

dnsutils
nameserver
/etc/resolv.conf
8.8.8.8
，它不会抱怨自我签名的证书。

$ kubectl exec -it dnsutils -- curl -vs https://google.com
*   Trying 142.251.116.101:443...
* Connected to google.com (142.251.116.101) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.google.com
*  start date: Jan 20 08:36:04 2025 GMT
*  expire date: Apr 14 08:36:03 2025 GMT
*  subjectAltName: host "google.com" matched cert's "google.com"
*  issuer: C=US; O=Google Trust Services; CN=WR2
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)



我猜测自签名的证书来自
Sagemcom
-听起来像是制造路由器。

$ kubectl exec -it dnsutils -- openssl s_client -connect  google.com:443 -showcerts
CONNECTED(00000003)
depth=0 C = FR, O = Sagemcom Ca, CN = self-signedKey
verify error:num=18:self signed certificate
verify return:1
depth=0 C = FR, O = Sagemcom Ca, CN = self-signedKey
verify return:1
---
Certificate chain
 0 s:C = FR, O = Sagemcom Ca, CN = self-signedKey
   i:C = FR, O = Sagemcom Ca, CN = self-signedKey

自我签名的证书来自哪里？是我的家路由器吗？
有什么方法可以配置我的豆荚或群集以避免此问题？
    

	
读了很多，我了解到它归结于容器中。
在
/etc/resolv.conf
指令中，有
/etc/resolv.conf
域。
另外，设定了。
per
search
，


lan




kubernetes

dns

k3s


1个回答




    
    
    

        

            

                

                    
0
投票

                    
                

            

        

        
options ndots: 5
域，除了我的笔记本电脑等合法主机外：

man /etc/resolv.conf
：
search Search list for host-name lookup.
      By default, the search list contains one entry, the local domain name.
      It is determined from the local hostname returned by gethostname(2); the
      local domain name is taken to be everything after the first '.'.
      Finally, if the hostname does not contain a '.', the root domain is
      assumed as the local domain name.

      This may be changed by listing the desired domain search path following
      the search keyword with spaces or tabs separating the names.  Resolver
      queries having fewer than ndots dots (default is 1) in them will be
      attempted using each component of the search path in turn until a match
      is found.  For environments with multiple subdomains please read options
      ndots:n below to avoid man-in-the-middle attacks and unnecessary traffic
      for the root-dns-servers.  Note that this process may be slow and will
      generate a lot of network traffic if the servers for the listed domains
      are not local, and that queries will time out if no server is available
      for one of the domains.



显然有不到5点，所以
映射到我的家庭路由器。很好

在另一层上下文上，K3S使用了核心。它促进服务，
用
lan
和pod进行配置。在
192.168.1.1
中，所有DNS请求均为
代理
*.lan
：
lan


COREDNS CONFIGMAPDOCS

cocoredns forward插件文档


最终使我解决这个问题的是
thinkpad.lan
。
我学会了将尾随点添加到域名中，以表示它是一个
FQDM（完全合格的域名）迫使DNS查找

192.168.1.47
，并且不做任何业务。
我意识到没有
google.com
没有

google.com.lan
搜索指令，这解释了为什么它不面对问题
Corefile
    

	



    

    


  

  

    
最新问题


  





  

    © www.soinside.com 2019 - 2025. All rights reserved.