Сервер не видит клиентов OpenVPN

[rchubenko]

Всем доброго времени суток.
Понадобился мне VPN для объеденения ряда устройств в одну сеть, также с возможностью выхода в интернет через выделенный ip-адрес (в обход провайдерского NAT)
Вообщем проблема такая. Есть сервер с KMV-виртуализацией от FirstVDS, на нем был предустановлен в системе VPN-сервер (из рецепта, который FirstVDS предоставляет). Сервер и клиентов (пока только два ноутбука на windows 10) настроил. Интерфейсы поднимаются, ip-адреса выдаются и в интернеты выходят, вроде все отлично. Но сервер никак не хочет пинговать клиентов, хотя сервер с клиентов пингуется и клиенты друг друга тоже видят. Клиентов на Windows запускаю под админом. Брандмауер отключен. Гуглил, пока решения проблемы не нашел и у меня варианты закончились. Буду рад любой помощи, несколько дней уже не могу решить.

Конфиги, логи, маршруты и правила Iptables все дам

[fisher74]

Конфиги, логи, маршруты и правила Iptables все дам

То есть нужно уговаривать, да?

Выбираем любого клиента и показываем его сетевую диагностику и серванта, с демонстрацией icmp-обмена с одной стороны и с другой.

[rchubenko]

Выбираем любого клиента и показываем его сетевую диагностику и серванта, с демонстрацией icmp-обмена с одной стороны и с другой.

Интерфейс сервера:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:573147 errors:0 dropped:0 overruns:0 frame:0
          TX packets:679422 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:255484630 (243.6 MiB)  TX bytes:612428881 (584.0 MiB)

Интерфейс клиента:
Адаптер Ethernet Ethernet 2:

   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : TAP-Windows Adapter V9
   Физический адрес. . . . . . . . . : 00-FF-E6-C0-43-28
   DHCP включен. . . . . . . . . . . : Да
   Автонастройка включена. . . . . . : Да
   IPv4-адрес. . . . . . . . . . . . : 10.8.0.9(Основной)
   Маска подсети . . . . . . . . . . : 255.255.255.252
   Аренда получена. . . . . . . . . . : 25 сентября 2017 г. 6:59:36
   Срок аренды истекает. . . . . . . . . . : 25 сентября 2018 г. 6:59:36
   Основной шлюз. . . . . . . . . : 10.8.0.10
   DHCP-сервер. . . . . . . . . . . : 10.8.0.10
   DNS-серверы. . . . . . . . . . . : 8.8.8.8
   NetBios через TCP/IP. . . . . . . . : Включен

Маршрутизация на сервере такая:
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Посылаю обычный пинг на клиента:
# ping -c 3 10.8.0.9
PING 10.8.0.9 (10.8.0.9) 56(84) bytes of data.
^C
--- 10.8.0.9 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

Пытаюсь отловить пакеты...
# tcpdump host 10.8.0.9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Пользователь добавил сообщение 25 Сентября 2017, 11:03:18:

То есть нужно уговаривать, да?

Нет, уговаривать не надо. Просто думал отправлять данные по мере необходимости, а не все сразу.

Конфиг сервера:

mode server
port 1194
proto tcp
dev tun
tls-server
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
client-config-dir /etc/openvpn/ccd/
server 10.8.0.0 255.255.255.0
#ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 5
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
client-to-client
log-append /var/log/openvpn.log

Конфиг клиента (x.x.x.x - ip-сервера):

client
dev tun
proto tcp
remote x.x.x.x 1194
tls-client
ca "ca.crt"
cert "client.crt"
key "client.key"
remote-cert-tls server
comp-lzo
tun-mtu 1500
mssfix 1450
verb 3
nobind
resolv-retry infinite
route-method  exe
route-delay 2

Правила iptables:

# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:1194

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  10.8.0.0/24          192.168.0.0/24
ACCEPT     all  --  192.168.0.0/24       10.8.0.0/24
ACCEPT     all  --  10.8.0.0/24          0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            10.8.0.0/24

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Причем я уверен, что решение очевидное и ответ банальный, но застрял конкретно.

[fisher74]

на сервере открываем два терминала, на одном запускаем tcpdump на другом пингуем клиента

Код: [Выделить]

sudo tcpdump -i tun0 -vnn icmpВыхлоп показываем.

И, на всякий случай, покажите ещё ifconfig eth0

[rchubenko]

sudo tcpdump -i tun0 -vnn icmp
Выхлоп показываем.

И, на всякий случай, покажите ещё ifconfig eth0

хм, видно что сервер отправляет пакеты:
# sudo tcpdump -i tun0 -vnn icmp
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
15:01:29.877803 IP (tos 0x0, ttl 64, id 36041, offset 0, flags [DF], proto ICMP (1), length 84)
    82.146.43.38 > 10.8.0.5: ICMP echo request, id 30590, seq 1, length 64
15:01:30.877712 IP (tos 0x0, ttl 64, id 36136, offset 0, flags [DF], proto ICMP (1), length 84)
    82.146.43.38 > 10.8.0.5: ICMP echo request, id 30590, seq 2, length 64
15:01:31.877788 IP (tos 0x0, ttl 64, id 36287, offset 0, flags [DF], proto ICMP (1), length 84)
    82.146.43.38 > 10.8.0.5: ICMP echo request, id 30590, seq 3, length 64
15:01:32.877719 IP (tos 0x0, ttl 64, id 36440, offset 0, flags [DF], proto ICMP (1), length 84)
    82.146.43.38 > 10.8.0.5: ICMP echo request, id 30590, seq 4, length 64
15:01:33.877804 IP (tos 0x0, ttl 64, id 36633, offset 0, flags [DF], proto ICMP (1), length 84)
    82.146.43.38 > 10.8.0.5: ICMP echo request, id 30590, seq 5, length 64

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 52:54:00:15:a7:d1
          inet addr:82.146.43.38  Bcast:82.146.43.38  Mask:255.255.255.255
          inet6 addr: fe80::5054:ff:fe15:a7d1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13317524 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7051109 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5697714758 (5.3 GiB)  TX bytes:5462336286 (5.0 GiB)

[fisher74]

угу, только source-address почему-то от eth0, а не tun0

[rchubenko]

угу, только source-address почему-то от eth0, а не tun0

Хоть знаю теперь в какую сторону копать. У Вас есть какие-нибудь предположения на этот счет?

[fisher74]

Нужно внимательней изучать таблицу маршрутизации, скорее всего там затык.
OVPN в этот момент точно был поднят? Хотя тогда бы tcpdump не завёлся на tun0
Надо полумать

[rchubenko]

Спасибо, что отзываетесь и помогаете.

А в обратную сторону пакеты ловит tun.

# tcpdump -i tun0 -vnn icmp
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
16:22:03.046666 IP (tos 0x0, ttl 128, id 32357, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.5 > 10.8.0.1: ICMP echo request, id 1, seq 8, length 40
16:22:03.046743 IP (tos 0x0, ttl 64, id 49544, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.1 > 10.8.0.5: ICMP echo reply, id 1, seq 8, length 40
16:22:04.076793 IP (tos 0x0, ttl 128, id 32363, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.5 > 10.8.0.1: ICMP echo request, id 1, seq 9, length 40
16:22:04.076828 IP (tos 0x0, ttl 64, id 49611, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.1 > 10.8.0.5: ICMP echo reply, id 1, seq 9, length 40

Маршруты на сервере:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

[fisher74]

Видимо это из необычной адресации eth0, ввиду чего "короткая" метрака на default gateway
Предлагаю проверить эту теорию так

Код: [Выделить]

sudo ip r a default via 10.0.0.1 dev eth0 metric 10
sudo ip r d default via 10.0.0.1 dev eth0 metric 0
проверьте, что метрика в первой строке теперь 10 и пропнгуйте клиента

[rchubenko]

Видимо это из необычной адресации eth0, ввиду чего "короткая" метрака на default gateway
Предлагаю проверить эту теорию так

Код: [Выделить]

sudo ip r a default via 10.0.0.1 dev eth0 metric 10
sudo ip r d default via 10.0.0.1 dev eth0 metric 0
проверьте, что метрика в первой строке теперь 10 и пропнгуйте клиента

Метрика установилась в 10, но к сожалению, результат тот же. Пинг все равно идет с eth0

[fisher74]

Метрика установилась в 10

Покажете? (всю таблицу)
ip r

[rchubenko]

Код: [Выделить]

# ip r
default via 10.0.0.1 dev eth0  metric 10
10.0.0.1 dev eth0  proto kernel  scope link  src 82.146.43.38
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1


[fisher74]

Код: [Выделить]

sudo iptables-save

[rchubenko]

Вот такой вот вывод:

# sudo iptables-save
# Generated by iptables-save v1.4.21 on Tue Sep 26 20:50:59 2017
*mangle
:PREROUTING ACCEPT [4138927:3555628419]
:INPUT ACCEPT [1110056:184551743]
:FORWARD ACCEPT [3028838:3371075686]
:OUTPUT ACCEPT [2757178:3537467968]
:POSTROUTING ACCEPT [5786016:6908543654]
COMMIT
# Completed on Tue Sep 26 20:50:59 2017
# Generated by iptables-save v1.4.21 on Tue Sep 26 20:50:59 2017
*filter
:INPUT ACCEPT [144455:13547029]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2757187:3537469064]
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -d 10.8.0.0/24 -j ACCEPT
COMMIT
# Completed on Tue Sep 26 20:50:59 2017
# Generated by iptables-save v1.4.21 on Tue Sep 26 20:50:59 2017
*nat
:PREROUTING ACCEPT [7940:945247]
:INPUT ACCEPT [3897:217252]
:OUTPUT ACCEPT [12894:791328]
:POSTROUTING ACCEPT [12866:789624]
-A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 82.146.43.38
COMMIT
# Completed on Tue Sep 26 20:50:59 2017