Tráfego não encaminhado de volta ao cluster GKE da rede remota via VPN

Question

(Acompanhamento no pod de GKE conectando via VPN? )

Estou tentando conectar um cluster GKE a uma rede remota usando uma VPN GCE para um Cisco ASA 5510. Ping do pod de GKE 10.248.0.26 - > o nó remoto 10.99.193.115 chega em 10.99.193.115 e o ASA diz que a resposta do eco volta através do túnel ao GKE. No entanto, o tcpdump em 10.248.0.26 não mostra nenhuma resposta.

Firewall e roteamento conforme relatado pelo Google Cloud Console:

Name    Source tag / IP range   Allowed protocols / ports   Target tags

default-allow-icmp  0.0.0.0/0   icmp    Apply to all targets
default-allow-internal  10.240.0.0/16   tcp:1-65535; udp:1-65535; icmp  Apply to all targets
default-allow-ssh   0.0.0.0/0   tcp:22  Apply to all targets
gke-zecluster-d6cc7a55-all  10.248.0.0/14   tcp; udp; icmp;     Apply to all targets
gke-zecluster-d6cc7a55-ssh  <public_ip>/32  tcp:22  gke-zecluster-d6cc7a55-node
gke-zecluster-d6cc7a55-vms  10.240.0.0/16   tcp:1-65535; udp:1-65535; icmp  gke-zecluster-d6cc7a55-node
k8s-fw-a1a92183fb18e11e5be3442010af0001     0.0.0.0/0   tcp:80,443  gke-zecluster-d6cc7a55-node
k8s-fw-a1aa3fe95b18e11e5be3442010af0001     0.0.0.0/0   tcp:2003    gke-zecluster-d6cc7a55-node

Name    Destination IP ranges   Priority    Instance tags   Next hop

default-route-3eed071cad0670e8  0.0.0.0/0   1000    None    Default internet gateway
default-route-7a9ddc4457c714a0  10.240.0.0/16   1000    None    Virtual network
gke-zecluster-d6cc7a55-7b61213c-b187-11e5-be34-42010af00015     10.248.0.0/24   1000    None    gke-zecluster-d6cc7a55-node-j4jx (Zone ze-zone-1)
gke-zecluster-d6cc7a55-7ec5f7a9-b187-11e5-be34-42010af00015     10.248.1.0/24   1000    None    gke-zecluster-d6cc7a55-node-rluf (Zone ze-zone-1)
vpn-1-tunnel-1-route-1  10.99.0.0/16    1000    None    

Existe algum registro que posso ativar para ver o que acontece? Tanto quanto eu posso ver, a VPN não diz nada pertinente sobre esse tráfego, apenas:

15:24:51.058 sending DPD request
15:24:51.058 generating INFORMATIONAL_V1 request 3069408857 [ HASH N(DPD) ]
15:24:51.058 sending packet: from <gce-vpn-ip>[500] to <asa-ip>[500] (92 bytes)
15:24:51.092 received packet: from <asa-ip>[500] to <gce-vpn-ip>[500] (92 bytes)
15:24:51.092 parsed INFORMATIONAL_V1 request 146600869 [ HASH N(DPD_ACK) ]

Se eu modificar o túnel da VPN (GCE VPN, ASA) para que a rede padrão 10.240.0.0/16 no tráfego final do GCE passe corretamente em ambas as direções.

Suponho que isso seja um problema de roteamento, mas o que? A rota 10.248.0.0/24 não deveria enviar o tráfego de volta ao nó do GKE? Ou eu tenho que de alguma forma declarar a rede GKE como uma rede?

    

Answer 1

No final, eu tive que escolher uma opção diferente. A configuração da opção spec.hostNetwork empurrou o pod para o espaço de endereço do nó, 10.240.0.0/16, para o qual a VPN funcionou bem.

Até onde eu sei, quando você cria um cluster GKE, existe uma rede "mágica" configurada para o espaço de endereçamento do pod, que parece não ter o roteamento correto em relação às VPNs. É possível que Karman esteja correto, mas não consigo encontrar uma maneira de declarar uma rede virtual explícita para os pods aplicarem as regras de firewall. Basta colocá-los na rede padrão parece não ajudar.

A criação de uma nova rede não legada não ajuda, pois o GKE se recusa a criar um cluster com endereço de pod em uma rede virtual existente e o GCE SDN se recusa a criar sub-redes virtuais para um espaço de endereçamento já reivindicado pelo GKE.

    

Answer 2

Se o endereço IP 10.248.0.26 pertencer a um nó GKE, para fazer ping entre o nó GKE e seu nó remoto, você precisará adicionar uma regra de firewall em 10.248.0.26/24 network para permitir o tráfego de entrada para o nó GKE ou todos os alvos dessa rede a partir de sua fonte remota.