Túnel transparente entre interfaces em hosts remotos

Question

Eu preciso fazer uma solução que funcione como um switch de rede com duas portas: uma porta localizada em um país e a segunda porta em outro país.

              +------------ Virtual switch ----------------+
+---------+   |   +-------+    +----------+    +-------+   |   +--------+
|Client A |<--+-->| BOX 1 |<-->|VPN server|<-->| BOX 2 |<--+-->|Client B|
+---------+   |   +-------+    +----------+    +-------+   |   +--------+
              +--------------------------------------------+

O Cliente A e o Cliente B devem sentir como o interruptor usual da camada 2. Conexão VPN entre duas caixas é OpenVPN. Então eu preciso encaminhar quadros Ethernet de alguma forma sobre o túnel VPN entre duas caixas. Caixa 1 e 2 executando o Debian jessie. Espero não escrever meu próprio software para isso :) Alguém pode sugerir possíveis soluções?

P.S. É necessário conectar duas peças de hardware projetadas para funcionar somente na LAN.

UPD: instalei 4 VMs para simular essa configuração (o vpnserver foi omitido):
Todas as máquinas são caixas debian | - Caixa 1 e Caixa 2 têm túnel de derivação GRE entre eles (Ethernet sobre IP)
- No cliente Uma interface local interligada com a interface gretap: a bridge tem o endereço 10.0.0.253
- Na interface local do Cliente B em ponte com a interface gretap: a bridge tem o endereço 10.0.0.254
- cliente A tem IP estático 192.168.1.1
- Cliente B tem IP estático 192.168.1.2

Do cliente A estou enviando a solicitação de eco ICMP para 192.168.1.2 e posso ver a solicitação ARP "Quem tem 192.168.1.2 informando 192.168.1.1" na bridge na caixa 1, na bridge on Caixa 2 e no Cliente B. A resposta ARP Mas é visível apenas no Cliente B. Assim, a resposta do ARP não volta para o Box2 de alguma forma. E todas as redes entre 10.0.0.253 e 10.0.0.254 funcionam bem. Então, suponho que o problema causado pela ponte.

UPD2: Agora removi o tunelamento da TAT e estabeleci uma rede regular entre o Box 1 e o Box 2. Quando criei bridges, o ping começou a funcionar. O que poderia causar problema ao fazer túnel GRE?

Solução: finalmente configurei tudo nas VMs com GRE-TAP. Eu usei o túnel GRE-TAP sobre a rede regular entre o Box 1 e o Box 2. E então eu conectei a interface de tunelamento com o interfacec local em cada Box. Abaixo estão os meus passos:

Caixa 1

ip link add tunnel0 type gretap remote 192.168.0.2 local 192.168.0.1
brctl addbr br0
brctl addif br0 eth2  # eth2 - is a local interface on Box 1
brctl addif br0 tunnel
ip addr add 10.0.0.253 dev tunnel0
ip link set br0 up
ip link set tunnel0 up

Caixa 2

ip link add tunnel0 type gretap remote 192.168.0.1 local 192.168.0.2
brctl addbr br0
brctl addif br0 eth2  # eth2 - is a local interface on Box 2
brctl addif br0 tunnel
ip addr add 10.0.0.254 dev tunnel0
ip link set br0 up
ip link set tunnel0 up

Obrigado a todos!

    

Answer 1

Eu não tentei isso sozinho, mas sei que você pode usar gretap para camada de túnel 2 (ethernet) sobre camada 3 (ip). De acordo, e. para esta blogentry , você configura uma gretap interface em cada extremidade e colmatar com a sua interface ethernet. Se eu entendi tudo corretamente, no exemplo 172.31.0.1 deve ser o endereço do ponto de extremidade da VPN no Quadro 1 e 172.31.0.2 do endereço do ponto de extremidade da VPN na Caixa 2. 10.10.10.1 é o endereço da LAN local para o Quadro 1, e 10.10.10.2 do endereço da LAN para o Box 2.

Caixa 1:

ip link add gretap0 type gretap local 172.31.0.1 remote 172.31.0.2
ip link set dev gretap0 up
ip link set dev eth0 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth0
ip addr add 10.10.10.1/24 dev br0
ip link set br0 up

Caixa 2:

ip link add gretap0 type gretap local 172.31.0.2 remote 172.31.0.1
ip link set dev gretap0 up
ip link set dev eth0 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth0
ip addr add 10.10.10.2/24 dev br0
ip link set br0 up

Você pode precisar ajustar as configurações de MTU. Eu não posso testar essa configuração, então você também pode precisar ajustar outras coisas.

Editar : Aqui é um artigo que explica os problemas da MTU, aparentemente está um pouco envolvido. Pode ser mais fácil no seu caso se você puder controlar as configurações da VPN MTU.

    

Answer 2

Isto não é muito difícil, porque tudo o que você está pedindo é que todo o tráfego L2 possa passar de uma rede para outra, que é uma característica padrão de um conexão OpenVPN em ponte . Isso significa que:

1. você configura o servidor OpenVPN (e os dois clientes) para configurar uma conexão OpenVPN em ponte (e lembre-se de permitir conexões do cliente para outro cliente através da instrução cliente-para-cliente no arquivo de configuração do servidor), ...

2. ou você acaba com o intermediário e conecta diretamente Box1 e Box2, como discutido por exemplo aqui ou aqui .

No caso ou , você precisa trabalhar no DHCP e no roteamento em ambos LANs, porque ambos devem pertencer ao mesmo domínio de transmissão. Por exemplo, podemos decidir que a sub-rede que usamos é 192.168.0.0/23 , com o servidor DHCP em LAN1 enviando endereços fora no intervalo 192.168.0.0/24 , e o servidor DHCP em LAN2 dishing endereços no intervalo 192.168.1.0/24 .

Então você precisa ajustar as rotas. Suponha que Box1 é um pc em LAN1 com endereço 192.168.0.121 e Box2 é um pc em LAN2 com endereço IP 192.168.1.173. Então, no gateway da LAN1, você precisa adicionar a rota:

ip route add 192.168.1.0/24 via 192.168.0.121 

enquanto no gateway da LAN2 você precisa adicionar:

ip route add 192.168.0.0/24 via 192.168.1.173

Isso gera uma certa quantidade de tráfego L2 dentro do site, o que pode ser irritante. Eu tenho uma configuração de três sites como esta, e não tenho nenhum problema com a quantidade de tráfego e conexões de 100Mb / s, mas YMMV. Se você quiser limitar a quantidade de tráfego L2 cruzando o OpenVPN, você pode usar ebtables no Box1 e Box2.

Essa é a única maneira que conheço para perceber o que você pediu.