O gateway de redirecionamento OpenVPN quebra outros túneis

Question

Esta é a configuração do meu ifconfig:

eth1      Link encap:Ethernet  HWaddr 54:04:a6:49:99:16  
          inet addr:192.168.0.12  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::5604:a6ff:fe49:9916/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33325389 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19876569 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:38511610122 (38.5 GB)  TX bytes:5030880286 (5.0 GB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1532251 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1532251 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:128544929 (128.5 MB)  TX bytes:128544929 (128.5 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:113 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1663663 errors:0 dropped:489668 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:14523 (14.5 KB)  TX bytes:1140762511 (1.1 GB)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.9.0.6  P-t-P:10.9.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1623870 errors:0 dropped:570939 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:828 (828.0 B)  TX bytes:1130753499 (1.1 GB)

wlan0     Link encap:Ethernet  HWaddr 00:21:00:e6:c8:aa  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Então eu tenho essa configuração de roteamento IP:

default via 192.168.0.1 dev eth1  proto static 
10.8.0.0/24 via 10.8.0.5 dev tun0 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6 
10.9.0.0/24 via 10.9.0.5 dev tun1 
10.9.0.5 dev tun1  proto kernel  scope link  src 10.9.0.6 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.12  metric 1 
192.168.1.0/24 via 10.8.0.5 dev tun0 

Funciona como pretendido. Eu sou capaz de pingar máquinas através de ambos os túneis (openvpn).

No entanto, quando adiciono

sudo ip route add 0.0.0.0/1 via 10.9.0.5 dev tun1 
sudo ip route add 128.0.0.0/1 via 10.9.0.5 dev tun1 

tudo quebra. Eu não posso mais pingar máquinas através de túneis.

Eu realmente não entendo o porquê. Desde que eu tenho uma rota de "prefixo maior" definida como

10.8.0.0/24 via 10.8.0.5 dev tun0 

Por que a nova rota "prefixo inferior" impede que eu faça o ping em 10.8.0.1?

Para o contexto, estou executando um servidor openvpn ao qual este cliente se conecta e é atribuído o 10.8.0.6 ip. Depois disso, ele se conecta a outro servidor openvpn (10.8.0.10) que está conectado ao mesmo servidor "original" (10.8.0.1). O primeiro servidor basicamente me coloca na mesma sub-rede que o segundo servidor (o segundo servidor não tem um ip estático e não pode ser redirecionado por porta). As duas rotas de prefixo baixo que estou adicionando fazem parte de uma opção "redirecionamento de gateway", pois estou tentando encaminhar todo o tráfego pelo segundo servidor.

EDITAR:

Estou adicionando todos os arquivos de configuração. (Omitirei as configurações irrelevantes ou padrão)

• main > o principal cliente que está tentando alcançar o tráfego da Internet roteamento
• alfa > o servidor que coloca todos na mesma sub-rede
• beta > o servidor / cliente que o principal quer rotear seu tráfego através. (note que o beta não tem um ip estático e não pode ser port forwaded)

alpha server.conf

port 443
proto udp
dev tun
server 10.8.0.0 255.255.255.0
client-to-client
# broadcast beta's subnet
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

beta client.conf (usado para conectar ao servidor alfa)

client
dev tun
proto udp
remote [alpha IP] 443

beta server.conf (o tráfego deve ser roteado através deste servidor)

port 444
proto udp
dev tun
server 10.9.0.0 255.255.255.0
client-to-client
push "redirect-gateway local def1"
push "dhcp-option DNS 8.8.8.8"

principal alfa client.conf

client
dev tun
proto udp
remote [alpha IP] 443

principal beta client.conf

client
dev tun
proto udp
remote 10.8.0.10 444

EDIT 2:

Eu tentei usar um túnel SSH reverso no servidor alfa, em vez de usar um servidor intermediário openvpn, mas tive exatamente o mesmo problema.

Eu fiz um túnel de beta assim

ssh -Nf -R \*:444:localhost:444 root@[alpha IP] 

E mudou o client.conf principal para se conectar ao [alpha IP]: 444 ao invés de 10.8.0.10.

A configuração funcionou perfeitamente sem o redirecionamento do gateway, mas assim que o redirecionamento do gateway adicionou as rotas 0.0.0.0/1 e 128.0.0.0/1, não consegui fazer ping em nenhum outro lugar.

    

Answer 1

Você está roteando o endpoint externo de seus túneis para o endereço do túnel. Isso não vai funcionar. Se você adicionar rotas específicas para os terminais de túnel via eth1, ele funciona.