매우 이상한 문제가 있습니다. kubectl cli가 VPN 내부의 클러스터에 연결할 수 없습니다.
내 배경:
- 운영 체제archlinux
- kubectl 클라이언트 버전: v1.28.1(최신)
- 내 컴퓨터에서 API 끝점에 대한 컬이 제대로 작동합니다.
- 브라우저에서 API를 열 수도 있습니다
- go_client 전송을 사용하는 작은 go 모듈도 작성했는데 그것도 작동합니다.
- 원격 클러스터 버전과 일치하도록 kubectl 클라이언트를 다운그레이드하려고 시도했지만 작동하지 않았습니다.
모든 게 괜찮은 것 같아와는 별개로Kubeker.
kubectl get pods --request-timeout='5s' -n my-ns -v=99
I0913 17:43:34.500572 60035 loader.go:395] Config loaded from file: /home/alexander/.config/kube/config
I0913 17:43:34.501699 60035 round_trippers.go:466] curl -v -XGET -H "Accept: application/json;g=apidiscovery.k8s.io;v=v2beta1;as=APIGroupDiscoveryList,application/json" -H "User-Agent: kubectl/v1.28.1 (linux/amd64) kubernetes/8dc49c4" 'https://172.16.10.10:6443/api?timeout=5s'
I0913 17:43:34.556074 60035 round_trippers.go:510] HTTP Trace: Dial to tcp:172.16.10.10:6443 succeed
I0913 17:43:39.503205 60035 round_trippers.go:553] GET https://172.16.10.10:6443/api?timeout=5s in 5001 milliseconds
I0913 17:43:39.503231 60035 round_trippers.go:570] HTTP Statistics: DNSLookup 0 ms Dial 43 ms TLSHandshake 47 ms Duration 5001 ms
I0913 17:43:39.503241 60035 round_trippers.go:577] Response Headers:
E0913 17:43:39.503298 60035 memcache.go:265] couldn't get current server API group list: Get "https://172.16.10.10:6443/api?timeout=5s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
I0913 17:43:39.503312 60035 cached_discovery.go:120] skipped caching discovery info due to Get "https://172.16.10.10:6443/api?timeout=5s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
I0913 17:43:39.503398 60035 round_trippers.go:466] curl -v -XGET -H "Accept: application/json;g=apidiscovery.k8s.io;v=v2beta1;as=APIGroupDiscoveryList,application/json" -H "User-Agent: kubectl/v1.28.1 (linux/amd64) kubernetes/8dc49c4" 'https://172.16.10.10:6443/api?timeout=5s'
내 IP 테이블에는 172.17 및 172.18 범위를 사용하는 일부 "docker" 관련 구성이 포함되어 있지만 "curl" 및 브라우저가 제대로 작동하기 때문에 이것이 무엇과 관련이 있는지 잘 모르겠습니다.
IP 라우팅도 좋아 보입니다. 트래픽은 VPN의 "tun" 인터페이스를 통해 라우팅됩니다.
default via 192.168.91.249 dev tun0 proto static metric 50
default via 192.168.10.254 dev enp5s0 proto dhcp src 192.168.10.134 metric 100
default via 192.168.10.254 dev wlp3s0 proto dhcp src 192.168.10.119 metric 600
172.16.100.0/24 via 192.168.91.249 dev tun0 proto static metric 50
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-53500e17974d proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-c1725b2d64cd proto kernel scope link src 172.19.0.1 linkdown
172.28.0.0/16 dev br-788b95918c9a proto kernel scope link src 172.28.0.1
192.168.10.0/24 dev enp5s0 proto kernel scope link src 192.168.10.134 metric 100
192.168.10.0/24 dev wlp3s0 proto kernel scope link src 192.168.10.119 metric 600
192.168.10.254 dev enp5s0 proto static scope link metric 50
192.168.91.1 via 192.168.91.249 dev tun0 proto static metric 50
192.168.91.249 dev tun0 proto kernel scope link src 192.168.91.250 metric 50
196.179.246.130 via 192.168.10.254 dev enp5s0 proto static metric 50
답변1
많은 고민 끝에 우리는 서버에 대한 UDP 네트워크 연결이 차단된 것을 발견하여 결국 "수정 1400"클라이언트 구성에서는 문제가 해결되었습니다.
내가 올바르게 이해했다면 이 값은 패킷 크기가 터널을 통과하도록 강제하여 우리의 경우 문제를 해결했습니다.
많은 사람들이 추천하는 "fragment" 변수도 있지만 서버 측에서는 활성화되지 않습니다.
자세한 내용은:https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/