Como enviar algum tráfego através da minha conexão vpn

Question

Eu tinha uma configuração de trabalho onde eu poderia acessar todos os meus recursos de trabalho que são acessados via VPN passando pelo meu servidor anteriormente, mas em algum momento recentemente isso parou de funcionar sem nenhum motivo óbvio.

desktop - servidor - (vpn) - trabalho

Atualmente, tenho as seguintes tabelas de roteamento:

Desktop:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.100   0.0.0.0         UG    2      0        0 eth0
10.2.1.0        192.168.1.10    255.255.255.0   UG    2      0        0 eth0
10.103.1.0      192.168.1.10    255.255.255.0   UG    2      0        0 eth0
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Servidor:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.100   0.0.0.0         UG    2      0        0 eth0
10.2.1.0        192.168.213.85  255.255.255.0   UG    0      0        0 tun0
...
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.213.0   192.168.213.85  255.255.255.0   UG    0      0        0 tun0
192.168.213.85  0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Esqueci o IP das caixas:

Servidor:

eth0: flags=4163  mtu 1500
        inet 192.168.1.10  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::4a5b:39ff:fed9:821b  prefixlen 64  scopeid 0x20
        ether 48:5b:39:d9:82:1b  txqueuelen 1000  (Ethernet)
        RX packets 189718543  bytes 130295498473 (121.3 GiB)


tun0: flags=4305  mtu 1500
        inet 192.168.213.86  netmask 255.255.255.255  destination 192.168.213.85
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)

Desktop:

eth0: flags=4163  mtu 1500
        inet 192.168.1.12  netmask 255.255.255.0  broadcast 192.168.2.255

Trabalho:

10.2.1.134

Regras atuais do IPTables:

# Generated by iptables-save v1.4.16.3 on Mon Mar 11 15:46:11 2013
*nat
:PREROUTING ACCEPT [1499:134874]
:INPUT ACCEPT [1499:134874]
:OUTPUT ACCEPT [1088:107916]
:POSTROUTING ACCEPT [1088:107916]
COMMIT
# Completed on Mon Mar 11 15:46:11 2013
# Generated by iptables-save v1.4.16.3 on Mon Mar 11 15:46:11 2013
*mangle
:PREROUTING ACCEPT [1680356:728348964]
:INPUT ACCEPT [1680356:728348964]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1399840:350789030]
:POSTROUTING ACCEPT [1400230:350882435]
COMMIT
# Completed on Mon Mar 11 15:46:11 2013
# Generated by iptables-save v1.4.16.3 on Mon Mar 11 15:46:11 2013
*filter
:INPUT ACCEPT [363:36065]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1399845:350789898]
:fail2ban-Apache - [0:0]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-Apache
-A INPUT -p tcp -m tcp --dport 1985 -j fail2ban-SSH
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 60151:60161 -j ACCEPT
-A INPUT -p udp -m udp --dport 6889 -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A fail2ban-Apache -j RETURN
-A fail2ban-SSH -j RETURN
COMMIT
# Completed on Mon Mar 11 15:46:11 2013

Como você pode ver, adicionei as regras de roteamento à área de trabalho para permitir que o tráfego seja transferido para o servidor da rede especificada. O trabalho está em 10.2.1.0/24 (Ignore os outros, eles são apenas partes extras de redes não importantes agora).

Eu acho que eu já tinha uma regra iptables que estava fazendo algo para o tráfego, mas eu a perdi durante um corte de energia (doh!) e agora não consigo descobrir o que eu fiz anteriormente para que funcione.

    

Answer 1

Acho que há um erro na tabela de roteamento do servidor.

A interface de túnel (conexão vpn) está listada como 192.168.213.86 com o ponto remoto sendo 192.168.213.85. Ainda na tabela de roteamento você tem

192.168.213.0   192.168.213.85  255.255.255.0   UG    0      0        0 tun0
192.168.213.85  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
0.0.0.0         192.168.1.100   0.0.0.0         UG    2      0        0 eth0

O problema está atingindo 192.168.213.85 via 192.168.1.100. Você precisa remover a entrada da tabela do meio. E, em vez disso, rotear para o final remoto através da interface tun local. Se a memória serve corretamente, a sintaxe correta deve ser:

route del -host 192.168.213.85 gw 0.0.0.0  
route add -host 129.168.213.85 gw 192.168.213.86

    

Answer 2

No final, reiniciei e funciona novamente.

Parece ser um bug estranho relacionado ao fato de termos um powercut ou eu retomei da hibernação. De qualquer forma, todos os detalhes, incluindo tabelas de roteamento e IPTables são indentical de antes e depois da reinicialização.

Irritante, mas, infelizmente, está resolvido.