GRE Tunnel para localhost

Question

Estou tentando usar um GRE Tunnel (ou TAP) para conectar uma VM de peso leve de namespace de rede Linux local à máquina HOST local. Tudo aparece para funcionar, exceto que as respostas do host não retornam para a VM.

Minha configuração:

IP real do HOST: 10.1.101.101/24

HOST GRE (Configuração assim):

ip l add dev gre1 type gretap remote 10.1.101.101 local 10.1.101.101 key 101
ip a add dev gre1 10.201.0.2/24
ip l set dev gre1 up

Configuração de rede do HOST:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:30:1b:42:65:ac brd ff:ff:ff:ff:ff:ff
    inet 10.1.101.101/24 brd 10.1.101.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::230:1bff:fe42:65ac/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:50:04:d0:50:0f brd ff:ff:ff:ff:ff:ff

82: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 0.0.0.0 brd 0.0.0.0
83: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
84: gre1@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65494 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether e2:83:0d:a4:cc:23 brd ff:ff:ff:ff:ff:ff
    inet 10.201.0.2/24 scope global gre1
       valid_lft forever preferred_lft forever
    inet6 fe80::e083:dff:fea4:cc23/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

Rotas do HOST:

ip r
default via 10.1.101.1 dev eth0 
10.1.101.0/24 dev eth0  proto kernel  scope link  src 10.1.101.101 
10.201.0.0/24 dev gre1  proto kernel  scope link  src 10.201.0.2 
169.254.0.0/16 dev eth0  scope link  metric 1000 

O iptables do HOST está em branco (IE: iptables -F )

Configuração de rede da VM:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
114: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:aa:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.201.0.1/24 brd 10.201.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::200:ff:feaa:0/64 scope link 
       valid_lft forever preferred_lft forever

Rotas da VM:

ip r
10.201.0.0/24 dev eth0  proto kernel  scope link  src 10.201.0.1 

Agora faça o ping do HOST 10.201.0.2 da VM 10.201.0.1 e capture os pacotes:

tcpdump -ni gre1 no HOST:

11:57:36.379404 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:36.379431 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:36.379455 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:37.376634 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:37.376658 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:37.376683 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:38.376539 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:38.376567 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:38.376596 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28

tcpdump -ni eth0 na VM:

11:57:36.379243 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:37.376384 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:38.376384 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28

Assim, a AFAICS envia a solicitação ARP para o HOST, o HOST responde ao ARP (corretamente), mas o pacote ARP não volta através do túnel GRE?

Nota 1: A VM é criada por um produto chamado CORE Emulator e consiste em um roteador básico anexado a um GRE Node , este nó aponta para 10.1.101.101 e a chave é 101

Nota 2: Se, em vez de usar o Core Emulator localmente, eu o executo em uma máquina diferente, mas com as mesmas configurações, a mesma configuração funciona corretamente (usando 10.1.101.101).

Eu também tentei configurar o HOST GRE Tunnel para:

ip l add gre1 type gretap remote 127.0.0.1 local 127.0.0.1 key 101

e o nó da VM GRE para apontar para 127.0.0.1

mas recebo o mesmo resultado, o ARP é visto e respondido pelo HOST, mas não é visto pela VM.

EDIT 1:
Em resposta ao meu problema do "mundo real", o CORE me fornece uma solução adequada, conforme descrito aqui: link

EDIT 2: pergunta subseqüente?
É possível que uma VM "Container / Rede Linux namespace / LXC" etc se comunique com a máquina HOST por meio de um túnel GRE. Os pontos de extremidade do túnel GRE seriam algo como HOST:127.0.0.1 to VM:?.?.?.? (Esses pontos de interrogação me levam à conclusão de que, embora a VM possa enviar para 127.0.0.1, o HOST não tem um caminho de retorno para a VM, que pode ser por isso que o ARP, na minha pergunta inicial, não chega à VM).

Obrigado por ler isto, qualquer ajuda é muito apreciada.

    

Answer 1

Resposta parcial: Um túnel GRE funciona em cima de uma conexão normal e fornece uma interface de rede adicional, que adiciona / remove os cabeçalhos de encapsulamento nos pacotes de rede.

Assim, a configuração normal para fazer um túnel entre duas máquinas A e B é a seguinte:

1) Verifique se A e B têm endereços IP "normais" e se podem ver uns aos outros. Por exemplo, se A tem IP "10.0.0.1/24" em seu eth0 e B tem IP IP "10.0.0.2/24" em seu eth0 , faça um ping 10.0.0.2 em A e um ping 10.0.0.1 em B .

2) Adicione um dispositivo de encapsulamento em A com o IP local de A e o IP remoto de B, adicione um novo IP à interface:

ip link add dev gre0 type gretap remote 10.0.0.2 local 10.0.0.1 key 123
ip addr add 10.0.44.1/24 dev gre0 
ip link set gre0 up

3) O mesmo para B, com os endereços IP apropriados:

ip link add dev gre0 type gretap remote 10.0.0.1 local 10.0.0.2 key 123
ip addr add 10.0.44.2/24 dev gre0
ip link set gre0 up

4) Faça ping 10.0.44.2 em A e ping 10.0.44.1 em B para ver se o túnel funciona.

Como você pode ver, esta não é a configuração que você tem: Seu endereço local e remoto para o túnel no HOST é o mesmo, não há endereço local e remoto para o túnel na VM, as interfaces de túnel na VM são para baixo e o endereço IP que pertence ao túnel acabou em eth0 . Nada disso faz sentido, então não é surpresa que não funcione.

Eu não sei como o Core Emulator lida com "GRE Nodes", mas a partir da configuração que você mostrou, isso parece ser apenas uma camada para configurar a interface GRE. Então, descubra como o Core Emulator lida com isso ou esqueça os "GRE Nodes" no emulador e configure-o manualmente.

Melhor ainda, como exercício, configure duas VMs A e B conectadas ao Core Emulator e adicione os túneis GRE manualmente, conforme descrito acima. Esta é uma situação simétrica e deve ser a menos confusa.