1

У меня есть виртуальный сервер Ubuntu 12.04 LTE, ядро 2.6.32 и VPN с запущенным VTun.

В VPN сервером является 6.6.6.6 , а двумя клиентами - 6.6.6.29 и 6.6.6.35 .

Если я пинг 6.6.6.6 с любого клиента, сервер отвечает немедленно. Поэтому я считаю, что клиенты настроены правильно. НО, если я пинг 6.6.6.35 от 6.6.6.29 , или наоборот, нет ответа.

Трассировка маршрута от 6.6.6.29 говорит:

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

Я предполагаю, что есть проблема маршрутизации в таблицах маршрутизации сервера.

Мои конфигурационные файлы:

$ 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

Но самое странное , что эта проблема появилась, когда я обновил сервер с версии 10.04 LTE до 12.04 LTE.

Когда я делаю: # cat /proc/sys/net/ipv4/ip_forward я получаю 1

Когда я делаю: # ufw я получаю -bash: ufw: command not found

ДОБАВЛЕНО 15 апреля 2013 г .:

Когда я делаю: # iptables -L я получаю:

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

Если я выполняю tcpdump -n -vvv -i tun0 и ping 6.6.6.35 из 6.6.6.29 я получаю:

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

И если в то же время я делаю tcpdump -n -vvv -i tun1 , я жду и жду и ничего не получаю:

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

Когда я выполняю tcpdump -n -vvv -e -i any host 6.6.6.29 я получаю:

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

И когда я делаю ip route get 6.6.6.35 from 6.6.6.29 iif tun0 я получаю:

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

Какие-либо предложения?

|источник

1 ответ1

1

Похоже, проблема брандмауэра / пересылки пакетов для меня ... Ваш сервер пересылает пакеты вообще? Как включить пересылку пакетов? или более официально UFW (несложный брандмауэр).

Если переадресация пакетов работает, разрешает ли брандмауэр (и конфигурация VPN) трафик между клиентами (я знаю, что для этого в OpenVPN есть параметр конфигурации «клиент-клиент»).

Или может openvpn работает, но клиент может только пинговать сервер помогает?

ОБНОВЛЕНИЕ Извините, я только что понял: ваш маршрут не так ...

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

не имеет смысла (но не должно приводить к проблеме, которую вы описываете).

Вы говорите своему серверу, что сеть 6.6.6.0/24 находится позади обоих, 6.6.6.29 и 6.6.6.35. Это не хорошо. Чего вы пытаетесь достичь с помощью этих маршрутов? Я думаю, что они вам не нужны.

Но сервер все еще должен быть в состоянии маршрутизировать к 6.6.6.29 и .39 соответственно. Можете ли вы пинговать 6.6.6.29 и .39 со своего сервера (6.6.6.6)?

Кстати: 6.6.6.0/24 - это не та сеть, которую вы можете использовать по своему усмотрению. Было бы более целесообразно использовать сеть RFC1918 (10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16).

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .