Gateway padrão de roteamento para a segunda vlan em um túnel (linux / tinc)

1

Corrigido: Acabou sendo uma combinação do que o BatchyX disse (faltando a rota 172.16.101.0/24 no final remoto), e tinc no lado remoto falhando em executar um script (o script não era executável).

Então agora tudo funciona muito bem, obrigado pela ajuda a todos:)

=============================================== ==============================

Meu problema é surpreendentemente difícil de explicar, então vou dividi-lo em partes menores, desculpe antecipadamente pelo texto longo:)

Eu tenho um servidor em um provedor de hospedagem, que tem um ip público, esse servidor está executando o tinc (software vpn).

Em casa, tenho duas vlans, a VLAN1 (minha sub-rede normal para o PC, etc., sentada atrás do NAT) e a VLAN20, para o meu laboratório vmware. meio ambiente.

O que eu gostaria de configurar é para que minha rede VLAN20 possa usar o servidor no provedor de hospedagem como seu gateway (seu ip externo), em vez do gateway externo que tenho em casa.

Para isso eu tenho um servidor em casa, que tem duas interfaces de rede, uma em VLAN1 e outra em VLAN20.

Digamos que eu tenha os seguintes ips:

Server at hosting provider:
Public IP: 123.123.123.123 (eth0)
Private IP: 10.1.0.1/24  (tun0)

Network at home:
VLAN1 - 192.168.1.0/24  (.1 is the gateway)
VLAN20 - 172.16.101.0/24

Network on server at home:
NIC1 (VLAN1) - 192.168.1.50/24 (eth0)
NIC2 (VLAN20) - 172.16.101.1/24 (eth1)
Tunnel - 10.1.0.2/24 (tun0)

Configurei o tinc, para que meu servidor em casa funcione no túnel, eu posso fazer ping de 10.1.0.1 do servidor em casa e 10.1.0.2 do servidor no provedor de hospedagem.

Além disso, eu configurei para que o servidor em casa use o túnel para o gateway padrão, tudo isso funciona do servidor real em casa, meu problema é que eu não consigo clientes na rede VLAN20 para acessar a internet .

Portanto, o problema que tenho é que não consigo descobrir como configurar o roteamento para que a rede 172.16.101.0/24 use o gateway padrão no túnel.

As rotas no servidor em casa são estas:

root@home:/etc/tinc/vpn/hosts# ip route
0.0.0.0/1 dev tun0  scope link
default via 192.168.1.1 dev eth0
10.1.0.0/24 dev tun0  proto kernel  scope link  src 10.1.0.2
123.123.132.123 via 192.168.1.1 dev eth0
128.0.0.0/1 dev tun0  scope link
172.16.101.0/24 dev eth1  proto kernel  scope link  src 172.16.101.1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.50

os / 1 são adicionados quando o túnel está com:

ip route add 0.0.0.0/1 dev $INTERFACE
ip route add 128.0.0.0/1 dev $INTERFACE

Fazendo um traceroute do servidor em casa para 8.8.8.8:

root@home:/etc/tinc/vpn/hosts# traceroute -s 10.1.0.2 8.8.8.8 -n
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.1.0.1  33.681 ms  33.698 ms  33.658 ms
 2  Router_At_Hosting_Provider  34.930 ms  34.907 ms  34.875 ms

Portanto, a sub-rede "tunnel" (10.1.0.0) funciona bem com o gateway padrão sobre o túnel.

Isso também funciona bem:

root@home:/etc/tinc/vpn/hosts# traceroute -s 172.16.101.1 10.1.0.2 -n
traceroute to 10.1.0.2 (10.1.0.2), 30 hops max, 60 byte packets
 1  10.1.0.2  0.032 ms  0.003 ms  0.005 ms

Mas meu problema é este:

root@home:/etc/tinc/vpn/hosts# traceroute -s 172.16.101.1 8.8.8.8 -n
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *

Se alguém tiver alguma indicação de onde eu deveria estar procurando, seria muito apreciado.

(A lista completa das mudanças feitas em ambos os servidores após a instalação do debian, está aqui link )

Editar Eu sou péssimo no Visio, mas aqui está minha tentativa de mostrar o que estou tentando configurar: link (não posso colocar inline ainda porque meu representante não é alto o suficiente).

    
por Peter 22.03.2014 / 17:34

1 resposta

2

Existem vários WTF nesta configuração:

ip route add 0.0.0.0/1 dev $INTERFACE
ip route add 128.0.0.0/1 dev $INTERFACE

Sirva-se e substitua-o por ip route change default dev $INTERFACE . Isso removerá o gateway padrão da eth1 e o substituirá pelo seu. Você também pode definir o endereço de origem preferido nessa rota, adicionando src 10.1.0.2 no final.

Se preferir manter a rota padrão, mas adicionar a sua própria, altere a métrica da rota padrão original para 1 ou mais. Quando você adicionar sua rota padrão, ela substituirá (mas não destruirá) a rota padrão original.

Além disso, a rota para 10.1.0.0/24 quando a VPN está ativa é um pouco redundante, já que ela já é coberta pela rota padrão.

O que você deseja como tabela de roteamento será mais parecido com isto:

default dev tun0 scope link src 10.1.0.2
default via 192.168.1.1 dev eth0 metric 1
123.123.132.123 via 192.168.1.1 dev eth0
172.16.101.0/24 dev eth1  proto kernel  scope link  src 172.16.101.1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.50

Agora esta tabela de roteamento está correta. O único problema agora está em seu servidor, não tem uma rota para 172.16.101.0/24, então tentará rotear isso através de sua interface pública. O caminho de retorno é essencialmente quebrado, então traceroute funciona, mas pings não.

Basta adicionar uma rota no site remoto para 172.16.101.0/24 via tun0 e será bom.

    
por 22.03.2014 / 20:57