.png)
Objetivo: rotear todo o tráfego da Internet de eth0 -> tun0 -> tun1 para VPN de salto duplo. A tabela de roteamento a seguir está correta para esse objetivo?
$ ip show de rota:
0.0.0.0/1 via 10.8.1.1 dev tun1
default via 10.8.3.1 dev tun0 proto static metric 50
10.8.1.0/24 dev tun1 proto kernel scope link src 10.8.1.6
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.4 metric 50
101.133.213.73 via 10.8.3.1 dev tun0
127.0.0.0/8 dev lo scope link
128.0.0.0/1 via 10.8.1.1 dev tun1
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100
182.160.0.0/24 dev eth0 proto kernel scope link src 182.160.0.19 metric 100
182.160.0.0/24 dev eth0 proto dhcp scope link src 182.160.0.19 metric 208
182.160.0.1 dev eth0 proto static scope link metric 100
Responder1
eth0 : 182.160.0.19/24 (GW: 182.160.0.1)
tun0 : 10.8.3.4/24 (GW: 10.8.3.1 / VPN endpoint : 191.72.65.45 via eth0)
tun1 : 10.8.1.6/24 (GW: 10.8.1.1 / VPN endpoint : 101.133.213.73 via tun0)
Desta forma, todo o tráfego (incluindo o tráfego proveniente de tun0) será roteado via tun1, exceto o tráfego local em Ethernet (182.160.0.0/24) e o tráfego local em tun0/"VPN1" (10.8.3.0/24).
Com esta tabela de roteamentotambém todo o tráfego vindo da eth0 será roteado via tun1que não é mencionado/solicitado na pergunta... Esta situação está boa para você? Caso a resposta seja sim, você pode manter esta configuração.
Caso esta situação não seja desejada (você não deseja rotear o tráfego de eth0 para tun1/tun0), você tem (pelo menos) duas opções de como lidar com isso.
- tabela de roteamento "personalizada"
Pode haver mais de uma tabela de roteamento e com base na regra/política você pode gerenciar qual tráfego seria tratado por outro que não seja o padrão. Dessa forma, você pode definir uma tabela de roteamento personalizada onde o GW padrão seria tun1 e somente o tráfego vindo de tun0 seria apontado para esta tabela de roteamento personalizada.
- Namespace de rede
Dessa forma, você pode isolar interfaces tun inteiras da eth0 (com roteamento interno entre namespaces) para que você possa ter uma tabela de roteamento simples (padrão) configurada no namespace para que apenas o tráfego de tun0 possa chegar a tun1.
Responder2
Supondo que a sequência desejada é o tráfego da sua LAN deve ir da máquina local -> tun0 -> tun1, é provável que isso seja o que está acontecendo, porém está acontecendo de uma forma que não é visível em um tracreroute.
Vamos pegar um pacote destinado a um endereço de Internet arbitrário - usarei 8.8.8.8 neste exemplo.
O computador pega o pacote e procura como enviá-lo. Ele vê que deveria ser enviado via tun1 (porque as 2 rotas abaixo são equivalentes a uma rota padrão, porém mais limitada, portanto preferida à rota padrão - neste caso a primeira rota é atingida) -
0.0.0.0/1 via 10.8.1.1 dev tun1
128.0.0.0/1 via 10.8.1.1 dev tun1
Mas aqui está a parte que pode não ser óbvia. Se você observar a configuração de tun1, descobrirá que ele tem um endpoint que é 101.133.213.73. Existe uma rota específica para este endereço IP que passa por tun0
101.133.213.73 via 10.8.3.1 dev tun0
Da mesma forma, há outra rota
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100
Esta rota torna o tráfego enviado via tun0 diretamente acessível através da interface Ethernet.
Por se tratar de uma rota muito específica, o tráfego para 101.133.213.73 passará pelo tun0. Assim, todo o tráfego que flui para a Internet (pelo tun1) deve passar por 101.133.213.73, que é em si um túnel,então sim, os dados fluirão pelos dois túneis.
Um traceroute não mostrará isso porque o pacote não sabe que está sendo encapsulado através de um túnel. Dito isto, você ainda pode verificar se isso está acontecendo observando os níveis mais baixos - Gerando tráfego enquanto está em outra janela fazendo um "sudo tcpdump -n -i any". Você verá que sempre que um pacote for enviado para a Internet mais ampla, um pacote será enviado através de eth0, tun0, tun1, e o mesmo acontecerá com os pacotes retornados. Todos os pacotes associados ao tun0 terão o destino 101.133.213.73.