1 votes

Le serveur Ubuntu n'achemine pas les paquets de mon VTun VPN.

J'ai un serveur virtuel Ubuntu 12.04 LTE, noyau 2.6.32, et un VPN avec VTun en cours d'exécution.

Dans le VPN, le serveur est 6.6.6.6 et les deux clients sont 6.6.6.29 y 6.6.6.35 .

Si j'envoie un message 6.6.6.6 de n'importe quel client, le serveur répond immédiatement. Je pense donc que les clients sont configurés correctement. MAIS si je fais un ping 6.6.6.35 de 6.6.6.29 ou vice-versa, il n'y a pas de réponse.

Un traceroute depuis 6.6.6.29 dit :

$ 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  * * *

Je suppose qu'il y a un problème de routage dans les tables de routage du serveur.

Mes fichiers de configuration sont :

$ 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

Mais le le plus étrange Le problème est apparu lorsque j'ai mis à niveau le serveur de la version 10.04 LTE à la version 12.04 LTE.

Quand je le fais : # cat /proc/sys/net/ipv4/ip_forward Je reçois 1

Quand je le fais : # ufw Je reçois -bash: ufw: command not found

AJOUTÉ 15/apr/2013 :

Quand je le fais : # iptables -L J'ai compris :

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   

Si je le fais tcpdump -n -vvv -i tun0 et je ping 6.6.6.35 de 6.6.6.29 J'ai compris :

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

Et si en même temps je fais tcpdump -n -vvv -i tun1 J'attends et j'attends et je n'ai rien :

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

Quand je le fais tcpdump -n -vvv -e -i any host 6.6.6.29 J'ai compris :

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

Et quand je le fais ip route get 6.6.6.35 from 6.6.6.29 iif tun0 J'ai compris :

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

Des suggestions ?

1voto

Krish Points 330

Cela ressemble plus à un problème de pare-feu/transfert de paquets pour moi... Votre serveur transfère-t-il des paquets ? Comment activer le transfert de paquets ? ou plus officiellement UFW (Uncomplicated Firewall) .

Si le transfert de paquets fonctionne, est-ce que le pare-feu (et la configuration du VPN) permet le trafic entre les clients (je sais qu'il y a une paramètre de configuration appelé "client-to-client" pour cela dans OpenVPN ).

Ou peut-être openvpn fonctionne mais le client est seulement capable de ping le serveur aide ?


UPDATE Désolé, je viens de réaliser : votre routage est mauvais...

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'a pas de sens (mais ne devrait pas non plus conduire au problème que vous décrivez).

Vous dites à votre serveur que le réseau 6.6.6.0/24 est derrière les réseaux 6.6.6.29 et 6.6.6.35. Ce n'est pas bon. Qu'est-ce que vous essayez d'obtenir avec ces routes ? Je pense que vous n'en avez pas besoin.

Mais le serveur devrait toujours être capable de router vers 6.6.6.29 et .39 respectivement. Pouvez-vous envoyer un ping à 6.6.6.29 et .39 depuis votre serveur (6.6.6.6) ?

À propos : 6.6.6.0/24 n'est pas un réseau que vous pouvez utiliser comme bon vous semble. Il serait plus approprié d'utiliser un réseau RFC1918 (10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X