O Ubuntu Server não está roteando pacotes do meu VTun VPN

1

Eu tenho um servidor virtual Ubuntu 12.04 LTE, kernel 2.6.32 e uma VPN com VTun em execução.

Na VPN, o servidor é 6.6.6.6 e os dois clientes são 6.6.6.29 e 6.6.6.35 .

Se eu pingar 6.6.6.6 de qualquer cliente, o servidor responderá imediatamente. Então eu acredito que os clientes estão configurados corretamente. MAS se eu pingar 6.6.6.35 de 6.6.6.29 , ou vice-versa, não há resposta.

Um traceroute de 6.6.6.29 diz:

$ traceroute -n 6.6.6.35

traceroute to 6.6.6.35 (6.6.6.35), 30 hops max, 60 byte packets
 1  6.6.6.6  78.409 ms  80.202 ms  82.820 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

Eu acho que há um problema de roteamento nas tabelas de roteamento do servidor.

Meus arquivos de configuração são:

$ cat /etc/default/vtun

RUN_SERVER=yes

$ cat /etc/vtund.conf

options {
    bindaddr {
        addr 85.84.83.82;
    };
}

default {
    type      tun;
    proto     tcp;
    persist   yes;
    keepalive yes;
    stat      yes;
    multi     yes;
}

client1 {
    passwd   U'dLikeToKnow;

    up {
        ifconfig "%% 6.6.6.6 pointopoint 6.6.6.29 mtu 1450";
        route "add -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.29";
    };
    down {
        ifconfig "%% down";
        route "del -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.29";
    };
}

client2 {
    passwd   U'dLikeToKnow;

    up {  
        ifconfig "%% 6.6.6.6 pointopoint 6.6.6.35 mtu 1450";
        route "add -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.35";
    };
    down {
        ifconfig "%% down";
        route "del -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.35";
    };
}     

$ ifconfig

tun0      Link encap:UNSPEC  direcciónHW 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          Direc. inet:6.6.6.6  P-t-P:6.6.6.29  Másc:255.255.255.255
          ACTIVO PUNTO A PUNTO FUNCIONANDO NOARP MULTICAST  MTU:1450  Métrica:1
          Paquetes RX:358 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:18 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:500 
          Bytes RX:27624 (27.6 KB)  TX bytes:1560 (1.5 KB)

tun1      Link encap:UNSPEC  direcciónHW 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          Direc. inet:6.6.6.6  P-t-P:6.6.6.35  Másc:255.255.255.255
          ACTIVO PUNTO A PUNTO FUNCIONANDO NOARP MULTICAST  MTU:1450  Métrica:1
          Paquetes RX:98 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:91 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:500 
          Bytes RX:10580 (10.5 KB)  TX bytes:8579 (8.5 KB)

$ route

Tabla de rutas IP del núcleo
Destino         Pasarela        Genmask         Indic Métric Ref    Uso Interfaz
6.6.6.29        *               255.255.255.255 UH    0      0        0 tun0
6.6.6.35        *               255.255.255.255 UH    0      0        0 tun1
6.6.6.0         6.6.6.35        255.255.255.0   UG    0      0        0 tun1
6.6.6.0         6.6.6.29        255.255.255.0   UG    0      0        0 tun0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         *               0.0.0.0         U     0      0        0 venet0

Mas a coisa mais estranha é que esse problema apareceu quando atualizei o servidor da versão 10.04 LTE para 12.04 LTE.

Quando faço isso: # cat /proc/sys/net/ipv4/ip_forward recebo 1

Quando faço isso: # ufw recebo -bash: ufw: command not found

ADICIONADO 15 / abr / 2013:

Quando faço isso: # iptables -L recebo:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8443
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8880
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ftp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssmtp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3s
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imap2
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imaps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:poppassd
DROP       tcp  --  anywhere             anywhere             tcp dpt:mysql
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:postgresql
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:9008
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:9080
ACCEPT     udp  --  anywhere             anywhere             udp dpt:netbios-ns
ACCEPT     udp  --  anywhere             anywhere             udp dpt:netbios-dgm
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:netbios-ssn
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:microsoft-ds
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
DROP       udp  --  anywhere             anywhere             udp dpt:domain
DROP       tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     icmp --  anywhere             anywhere             icmptype 8 code 0
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
LOG        all  --  anywhere            !6.6.6.0/24           limit: avg 5/min burst 5 LOG level warning
LOG        all  --  anywhere            !6.6.6.0/24           limit: avg 5/min burst 5 LOG level warning
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere   

Se eu fizer tcpdump -n -vvv -i tun0 e ping 6.6.6.35 de 6.6.6.29 , obtenho:

tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
00:17:16.876853 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 1, length 64
00:17:17.875252 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 2, length 64
00:17:18.882941 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 3, length 64
00:17:19.891173 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 4, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

E se ao mesmo tempo eu faço tcpdump -n -vvv -i tun1 , espero e espero e não recebo nada:

tcpdump: listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Quando faço tcpdump -n -vvv -e -i any host 6.6.6.29 , obtenho:

tcpdump -n -vvv -e -i any host 6.6.6.29
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
09:50:05.051513  In ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 11932, seq 1, length 64

E quando eu faço ip route get 6.6.6.35 from 6.6.6.29 iif tun0 eu recebo:

6.6.6.35 from 6.6.6.29 dev tun1  src 6.6.6.6 
    cache <src-direct>  mtu 1450 advmss 1410 hoplimit 64 iif tun0

Alguma sugestão?

    
por Ricardo Bou 17.03.2013 / 08:33

1 resposta

1

Soa mais como um problema de encaminhamento de firewall / pacote para mim ... O seu servidor encaminha pacotes em tudo? Como habilitar o encaminhamento de pacotes? ou mais oficialmente UFW (Uncomplicated Firewall) .

Se o encaminhamento de pacotes está funcionando, o firewall (e a configuração VPN) permite o tráfego entre os clientes (eu sei que existe um configuração de configuração chamada" client-to-client "para isso no OpenVPN ).

Ou talvez o openvpn funcione, mas o cliente só consegue fazer ping no servidor ajuda?

UPDATE Desculpe, acabei de perceber: seu roteamento está errado ...

6.6.6.0         6.6.6.35        255.255.255.0   UG    0      0        0 tun1
6.6.6.0         6.6.6.29        255.255.255.0   UG    0      0        0 tun0

não faz sentido (mas também não deve levar ao problema que você descreve).

Você está dizendo ao seu servidor que a rede 6.6.6.0/24 está atrás de ambos, 6.6.6.29 e 6.6.6.35. Isso não é bom. O que você está tentando conseguir com essas rotas? Eu acho que você não precisa deles.

Mas o servidor ainda deve ser capaz de rotear para 6.6.6.29 e .39, respectivamente. Você pode fazer ping em 6.6.6.29 e .39 do seu servidor (6.6.6.6)?

A propósito: 6.6.6.0/24 não é uma rede que você pode usar como quiser. Seria mais apropriado usar uma rede RFC1918 (10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16).

    
por 11.04.2013 / 11:03