OpenVPN проблемы

0

2

Добрый день. Пытаемся настроить туннель между офисами.

1 офис : Сервер Ubuntu 10.04.3, openvpn 2.1.0. Стоит за шлюзом (Cisco IP X.X.X.X). IP 192.168.25.9, локальная сетка 192.168.25.0/24. Конфиг сервера:

    port 4768
    proto udp
    dev tun
    ca /etc/openvpn/keys/ca.crt
    cert /etc/openvpn/keys/server.crt
    key /etc/openvpn/keys/server.key
    dh /etc/openvpn/keys/dh1024.pem
    server 10.10.111.0 255.255.255.0
    ifconfig-pool-persist ipp.txt
    push "route 192.168.25.0 255.255.255.0"
    client-config-dir ccd
    route 192.168.111.0 255.255.255.0
    route 192.168.1.0 255.255.255.0
    route 192.168.0.0 255.255.255.0
    client-to-client
    keepalive 10 120
    comp-lzo
    max-clients 100
    user nobody
    group nogroup
    persist-key
    persist-tun
    status /var/log/openvpn/openvpn-status.log
    log         /var/log/openvpn/openvpn.log
    verb 6
    mute 20

Ifconfig

    eth0      Link encap:Ethernet  HWaddr цифры
              inet addr:192.168.25.9  Bcast:192.168.25.255  Mask:255.255.255.0
              inet6 addr: цифры/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:68112 errors:0 dropped:0 overruns:0 frame:0
              TX packets:21025 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:7720245 (7.7 MB)  TX bytes:3414228 (3.4 MB)

    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
              inet addr:10.10.111.1  P-t-P:10.10.111.2  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:669 errors:0 dropped:0 overruns:0 frame:0
              TX packets:16925 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100
              RX bytes:53453 (53.4 KB)  TX bytes:1347145 (1.3 MB)

netstat

    10.10.111.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
    192.168.1.0     10.10.111.2     255.255.255.0   UG        0 0          0 tun0
    192.168.0.0     10.10.111.2     255.255.255.0   UG        0 0          0 tun0
    10.10.111.0     10.10.111.2     255.255.255.0   UG        0 0          0 tun0
    192.168.111.0   10.10.111.2     255.255.255.0   UG        0 0          0 tun0
    192.168.25.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
    0.0.0.0         192.168.25.1    0.0.0.0         UG        0 0          0 eth0

2 офис: Клиент FreeBSD 8.2, openvpn 2.1.4, является шлюзом. IP внешний A.B.C.D, внутренний 192.168.0.110, локальная сетка 192.168.0.0/24. Конфиг клиента

    client
    dev tun
    proto udp
    remote X.X.X.X 4768
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca /usr/local/etc/openvpn/keys/ca.crt
    cert /usr/local/etc/openvpn/keys/dikom.crt
    key /usr/local/etc/openvpn/keys/dikom.key
    comp-lzo
    verb 6
    mute 20
    user nobody
    group nogroup
    status /var/log/openvpn/openvpn-status.log
    log /var/log/openvpn/openvpn.log

Ifconfig

    rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=3808<VLAN_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
            ether цифры
            inet A.B.C.D netmask 0xfffffffc broadcast провайдера
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=82009<RXCSUM,VLAN_MTU,WOL_MAGIC,LINKSTATE>
            ether цифры
            inet 192.168.0.110 netmask 0xffffff00 broadcast 192.168.0.255
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    tun1: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1500
            options=80000<LINKSTATE>
            inet 10.10.111.14 --> 10.10.111.13 netmask 0xffffffff
            Opened by PID 86934

netstat

    default            ip провайдера      UGS      1167  8026801    rl0
    10.10.111.0/24     10.10.111.13       UGS         0    24134   tun1
    10.10.111.13       link#20            UH          0        5   tun1
    10.10.111.14       link#20            UHS         0        6    lo0
    192.168.25.0/24    tun1               US          0     2648   tun1
    сетка провайдера/30   link#1             U           0        2    rl0
    A.B.C.D              link#1             UHS         0    26864    lo0
    127.0.0.1             link#6             UH          0  1437550    lo0
    192.168.0.0/24     link#2             U          88  9683556    xl0
    192.168.0.110      link#2             UHS         3    74436    lo0

На freebsd стоит pf, но его отключение на результат не влияет. Проблема в том, что с локалки 1офиса сеть 2офиса пингуется, а со 2офиса на 1офис нет.

Ссылка

←	Как сделать сеть в QEMU без KVM?

lm_sensors

→

Покажите, какие именно адреса у пингующих и какие именно адреса у пингуемых. Причём в случае пинга с 1-й сети и в случае пинга со 2-й сети.
Желательно ещё и traceroute

Slavaz ★★★★★
(19.02.12 14:20:17 MSK)

Ответ на: комментарий от Slavaz 19.02.12 14:20:17 MSK

с 1офиса на 2офис

ping -S 192.168.25.9 192.168.0.110
PING 192.168.0.110 (192.168.0.110) 56(84) bytes of data.
64 bytes from 192.168.0.110: icmp_seq=1 ttl=64 time=18.1 ms

со 2офиса на 1офис ping с 192.168.0.110 на 192.168.25.9 не идет, на другие тоже

traceroute -s 192.168.0.110 192.168.25.9 
traceroute to 192.168.25.9 (192.168.25.9) from 192.168.0.110, 64 hops max, 40 byte packets
 1  * * *

traceroute -s 192.168.0.110 192.168.25.27
traceroute to 192.168.25.27 (192.168.25.27) from 192.168.0.110, 64 hops max, 40 byte packets
 1  10.10.111.1 (10.10.111.1)  19.615 ms  20.328 ms  18.615 ms
 2  * * *

dalekiy
(19.02.12 16:20:28 MSK) автор топика

Ответ на: комментарий от dalekiy 19.02.12 16:20:28 MSK

Судя по всему, адрес 10.10.111.1 отвечает, а это адрес туннеля на стороне шлюза в 1-м офисе. Второй адрес в первом офисе молчит, ходя он на том же компе. Вероятно, форвардинг отключен (sysctl net.ipv4.ip_forward=1)

Ещё посмотрите iptables, может они мешают. Посмотрите правила на шлюзе в 1-м офисе, разрешены ли icmp-запросы и ответы на них. Ну и вообще, разрешён ли трафик со статусом NEW и какие правила на FORWARD-цепочке.

Slavaz ★★★★★
(19.02.12 16:30:38 MSK)

Ответ на: комментарий от Slavaz 19.02.12 16:30:38 MSK

На VPN сервере 1офис

net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv4.ip_forward = 1

На FreeBSD 2офис

net.inet.ip.forwarding: 1

Тут, есть еще один нюанс. К 1офису подключен еще 3офис по этим же настройкам, с ним всё работает, разница на стороне 3офиса(от 2офиса) только в том, что стоит FreeBSD 7.4. Я админю 2 и 3 офисы, соответственно настройки на обоих одинаковые( в частности pf), единственно в таблице маршрутизации небольшая разница 2офис (см выше)

10.10.111.0/24     10.10.111.13       UGS         0    24134   tun1
    10.10.111.13       link#20            UH          0        5   tun1
    10.10.111.14       link#20            UHS         0        6    lo0
    192.168.25.0/24    tun1               US          0     2648   tun1

3офис

192.168.25.0/24    10.10.111.17     UGS         0    17601   tun0
10.10.111.0/24   10.10.111.17     UGS         0        2   tun0
10.10.111.17     10.10.111.18    UH          3        0   tun0

Админ 1офиса, естественно кивает на то что с 3 офисом всё в порядке, поэтому настройки сервера правильные. Не очень понятно куда копать.

dalekiy
(19.02.12 16:55:44 MSK) автор топика

Ответ на: комментарий от dalekiy 19.02.12 16:55:44 MSK

попробуйте запустить tcpdump на 1-м офисе (на туннеле и на сетевом интерфейсах) и просмотрите, доходят ли пакеты и как они проходят

Slavaz ★★★★★
(19.02.12 17:04:49 MSK)

Ответ на: комментарий от Slavaz 19.02.12 17:04:49 MSK

Попрошу в понедельник того админа. Спасибо за ответы. Завтра, надеюсь продолжим.

dalekiy
(19.02.12 17:26:13 MSK) автор топика

Ссылка

http://openvpn.net/index.php/open-source/documentation/howto.html#scope

~~zgen~~ ★★★★★
(19.02.12 22:45:19 MSK)

Ссылка

Ответ на: комментарий от Slavaz 19.02.12 17:04:49 MSK

[телепат моде он]
С исходящего виртуального интерфейса одного офиса уходят, но на входящий виртуальный интерфейс другого офиса не приходит.
[телепат моде офф]

~~zgen~~ ★★★★★
(19.02.12 22:47:52 MSK)

Ссылка

man openvpn, route недостаточно, надо еще втыкать на сервере iroute в файле, соответствующем CN клиента в ccd

xdeller
(20.02.12 00:44:05 MSK)

Ответ на: комментарий от xdeller 20.02.12 00:44:05 MSK

ccd/имя подключения

iroute 192.168.0.0 255.255.255.0

dalekiy
(20.02.12 10:31:52 MSK) автор топика

Ответ на: комментарий от dalekiy 20.02.12 10:31:52 MSK

На фре случаем нету айписека, даже неактивного, с диапазоном, перекрывающим подсеть за опенвпн сервером?

xdeller
(20.02.12 10:51:30 MSK)

Ответ на: комментарий от xdeller 20.02.12 10:51:30 MSK

Да ipsec есть, работающий, но диапазон не перекрывается

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet A.B.C.D --> X1.X1.X1.X1
        inet 192.168.0.110 --> 192.168.10.10 netmask 0xffffffff 
        options=1<ACCEPT_REV_ETHIP_VER>
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet A.B.C.D --> X2.X2.X2.X2
        inet 192.168.0.110 --> 192.168.11.111 netmask 0xffffffff 
        options=1<ACCEPT_REV_ETHIP_VER>
gif2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet A.B.C.D --> X3.X3.X3.X3
        inet 192.168.0.110 --> 192.168.1.10 netmask 0xffffffff 
        options=1<ACCEPT_REV_ETHIP_VER>

dalekiy
(20.02.12 12:23:53 MSK) автор топика

Ссылка

Ответ на: комментарий от xdeller 20.02.12 10:51:30 MSK

И да, с начала хотели поднять ipsec, может что-то от настроек остаться? Сейчас просмотрю.

dalekiy
(20.02.12 12:26:58 MSK) автор топика

Ответ на: комментарий от dalekiy 20.02.12 12:26:58 MSK

На заметку, на роутинг могут влиять как политики самого айписека(цепляются при поднятии сервиса, а не при инициализации соединения у *swan), так и собственно роуты, которые пушатся при запуске ипсек соединения. Для чистоты эксперимента, если есть возможность, ипсек лучше полностью скосить из автозагрузки и перезагрузиться.

xdeller
(20.02.12 13:16:34 MSK)

Ссылка

Ответ на: комментарий от xdeller 20.02.12 10:51:30 MSK

Огромное спасибо. Так и было. Зарабтало.

dalekiy
(20.02.12 13:25:14 MSK) автор топика

Ссылка

Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.

←	Как сделать сеть в QEMU без KVM?

Admin

lm_sensors

→

Похожие темы