LINUX.ORG.RU
Форум — Admin  

OpenVPN сервер не пингует клиента

 ,


0

1

Добрый день. Есть сервер с CentOS 7 и клиент тоже с CentOS 7. На сервере 2 сетевые карты (Локалка 192.168.0.14 и ppp-сессия с белым IP) и поднят OpenVPN сервер, на клиенте соответственно, OpenVPN клиент и одна сетевуха для локалки (192.168.137.14) и для VPN. И на сервере и на клиенте выставлена net.ipv4.ip_forward=1. Iptables, опять же, на обоих на время тестирования выключен. Защищенный канал устанавливается без проблем, с клиента до локального интерфейса сервера пинг ходит, а вот с сервера интерфейс клиента не пингуется, пакеты на стороны сервера в тоннель попадают (tcpdump логи приложу), а на стороне клиента пакеты не появляются. При этом в обратную сторону (пинг с клиента на сервер) все четко ходит по тоннелю в обе стороны.

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

local 7.7.7.7
port 21333
proto tcp
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem

server 10.0.0.0 255.255.255.0
route 192.168.137.0 255.255.255.0 # указываем подсеть, к которой будем обращаться через vpn


ifconfig-pool-persist ipp.txt # файл с записями соответствий clinet - ip
client-to-client # позволяет клиентам openvpn подключаться друг к другу
client-config-dir /etc/openvpn/ccd # директория с индивидуальными настройками клиентов

keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

/etc/openvpn/ccd/client: 

                                                                       
iroute 192.168.137.0 255.255.255.0

Конфиг клиента 

   
/etc/openvpn/client.conf                                                                             
dev tun
proto tcp
remote 7.7.7.7 21333
client
resolv-retry infinite
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
route 192.168.0.0 255.255.255.0
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log /var/log/openvpn/openvpn-client.log

ip server: 

                                                                       
p a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether f4:f2:6d:03:cd:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.14/24 brd 192.168.0.255 scope global enp2s0
       valid_lft forever preferred_lft forever
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 74:d4:35:49:31:cf brd ff:ff:ff:ff:ff:ff
8: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 7.7.7.7 peer 7.7.7.6/32 scope global ppp0
       valid_lft forever preferred_lft forever
26: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.0.0.1 peer 10.0.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
ip client 
     
 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 74:d4:35:f6:51:4b brd ff:ff:ff:ff:ff:ff
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 60:e3:27:02:30:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.137.14/24 brd 192.168.137.255 scope global enp4s0
       valid_lft forever preferred_lft forever
    inet6 fe80::62e3:27ff:fe02:3074/64 scope link
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.0.0.6 peer 10.0.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever
Маршруты сервера 
  
 netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
10.0.0.0        10.0.0.2        255.255.255.0   UG        0 0          0 tun0
10.0.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
7.7.7.7         0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp2s0
192.168.137.0   10.0.0.2        255.255.255.0   UG        0 0          0 tun0
Маршруты клиента 
 
netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.137.1   255.255.255.255 UGH       0 0          0 enp4s0
0.0.0.0         192.168.137.1   0.0.0.0         UG        0 0          0 enp4s0
10.0.0.0        10.0.0.5        255.255.255.0   UG        0 0          0 tun0
10.0.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.0.0     10.0.0.5        255.255.255.0   UG        0 0          0 tun0
192.168.137.0   0.0.0.0         255.255.255.0   U         0 0          0 enp4s0

tcpdump клиента 192.168.137.14 с удачным пингом к серверу 192.168.0.14 

  
00:00:25.297860 IP (tos 0x0, ttl 64, id 47913, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.6 > 192.168.0.14: ICMP echo request, id 4647, seq 1, length 64
00:00:00.004469 IP (tos 0x0, ttl 64, id 58091, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.14 > 10.0.0.6: ICMP echo reply, id 4647, seq 1, length 64
00:00:00.996800 IP (tos 0x0, ttl 64, id 47915, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.6 > 192.168.0.14: ICMP echo request, id 4647, seq 2, length 64
00:00:00.002679 IP (tos 0x0, ttl 64, id 58093, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.14 > 10.0.0.6: ICMP echo reply, id 4647, seq 2, length 64
00:00:00.999285 IP (tos 0x0, ttl 64, id 47916, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.6 > 192.168.0.14: ICMP echo request, id 4647, seq 3, length 64
00:00:00.002924 IP (tos 0x0, ttl 64, id 58094, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.14 > 10.0.0.6: ICMP echo reply, id 4647, seq 3, length 64
 tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vv

tcpdump сервера 192.168.0.14 с удачным пингом от клиента до самого сервера: 

 
tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vvvvvv
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
00:00:00.000000 IP (tos 0x0, ttl 64, id 47929, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.6 > 192.168.0.14: ICMP echo request, id 4649, seq 1, length 64
00:00:00.000032 IP (tos 0x0, ttl 64, id 58107, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.14 > 10.0.0.6: ICMP echo reply, id 4649, seq 1, length 64
00:00:01.001677 IP (tos 0x0, ttl 64, id 47930, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.6 > 192.168.0.14: ICMP echo request, id 4649, seq 2, length 64
00:00:00.000027 IP (tos 0x0, ttl 64, id 58108, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.14 > 10.0.0.6: ICMP echo reply, id 4649, seq 2, length 64
00:00:01.001401 IP (tos 0x0, ttl 64, id 47931, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.6 > 192.168.0.14: ICMP echo request, id 4649, seq 3, length 64
00:00:00.000027 IP (tos 0x0, ttl 64, id 58109, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.14 > 10.0.0.6: ICMP echo reply, id 4649, seq 3, length 64

Теперь пингуем с севера адрес клиента 192.168.137.14, у нас все три пакета зашли в туннель:

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

 
# tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vvvvvv
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
00:00:00.000000 IP (tos 0x0, ttl 64, id 28416, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.137.14: ICMP echo request, id 31588, seq 1, length 64
00:00:00.999646 IP (tos 0x0, ttl 64, id 28417, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.137.14: ICMP echo request, id 31588, seq 2, length 64
00:00:00.999998 IP (tos 0x0, ttl 64, id 28418, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.137.14: ICMP echo request, id 31588, seq 3, length 64

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

 
#  tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vv
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
А там пусто, в туннеле вообще ни одного icmp пакета-то и нету!

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



Последнее исправление: alex843 (всего исправлений: 2)
← makefile проверка пременной
Помер wireshark. →

Ощущение как будто iroute не отрабатывает, посмотрите на права /etc/openvpn/ccd и /etc/openvpn/ccd/client
Посмотрите со стороны сервера tcpdump не на tun а на физическом интерфейсе, начинает ли он кидать пакеты при пинге в сторону клиента.

anc ★★★★★
()
Ответ на: комментарий от anc

Права доступа: 

drwxr-xr-x   4 root     root        119 мар 23 15:35 openvpn
drwxr-xr-x 2 root root   21 мар 23 12:12 ccd

tcpdump на физическом интерфейсе в локалку:

tcpdump -i enp2s0 -n -nn -ttt 'ip proto \icmp' -vvvvvv
tcpdump: listening on enp2s0, link-type EN10MB (Ethernet), capture size 65535 bytes
Ни одного пакета, они по идее в туннель заруливают, как в первом сообщении и писал.

alex843
() автор топика
Ответ на: комментарий от anc

Да, из под рута и на сервере и на клиенте. 

ps -ef | fgrep openvpn
root     31705     1  0 15:36 ?        00:00:00 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --cd /etc/openvpn/ --config server.conf

alex843
() автор топика
Ответ на: комментарий от anc

Тоже пусто: 

 tcpdump -i enp2s0 -n -nn -ttt tcp port 21333
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

alex843
() автор топика
Ответ на: комментарий от Radjah

маршрут к сети за сервером OpenVPN. Можно было и с сервера через push раздать, но сделал у клиента в файле.

alex843
() автор топика
Ответ на: комментарий от alex843

Уже лучше, т.е. iroute похоже. Посмотрите логи на сервере в момент подсоединения клиента там должно быть что-то типа MULTI: internal route 192.168.137.0/24

На всякий случай уточню, это с сервера и при этом пинг запущен был?

anc ★★★★★
()
Ответ на: комментарий от alex843

Как раз про это дописывал.

Сервер должен запушить клиенту маршруты: 

push "route 192.168.0.0 255.255.255.0"
push "route 192.168.137.0 255.255.255.0"

(Вторая строка на случай множества клиентов.)

iroute говрит, что за клиентом «client» есть сеть 192.168.137.0/24. И все запросы в эту сеть будут гнаться на него.

Т.е. в конфиге клиента по уму никаких маршрутов быть не должно, он всё будет от сервера получать.

Radjah ★★★★★
()
Последнее исправление: Radjah (всего исправлений: 1)
Ответ на: комментарий от Radjah

то есть роут из конфига клиента убрать и добавить в конфиг сервера push «route 192.168.0.0 255.255.255.0» Так?

alex843
() автор топика
Ответ на: комментарий от alex843

посмотрите внимательно на опцию client-config-dir /etc/openvpn/ccd и сам файл /etc/openvpn/ccd/client может какой не читаемый символ попался. Да и ентер после iroute 192.168.137.0 255.255.255.0 проверьте.

anc ★★★★★
()
Ответ на: комментарий от Radjah

Эй плохому не учите push «route 192.168.137.0 255.255.255.0» здесь вообще не в кассу, вы чего самому себе (клиенту) его пушить собрались?
У ТС в целом все верно, можно через ccd push «route 192.168.0.0 255.255.255.0» а можно в конфиге клиента, да хоть руками на клиенте через ip route add... добавляй, роли не играет.

anc ★★★★★
()
Ответ на: комментарий от anc

Никаких символов лишних там нет. Вот таблицы маршрутизации до и после запуска сервера: 

[root@localhost openvpn]# service openvpn@server stop
Redirecting to /bin/systemctl stop  openvpn@server.service
[root@localhost openvpn]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
7.7.7.7   0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp2s0
[root@localhost openvpn]# service openvpn@server start
Redirecting to /bin/systemctl start  openvpn@server.service
[root@localhost openvpn]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
10.0.0.0        10.0.0.2        255.255.255.0   UG        0 0          0 tun0
10.0.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
7.7.7.7   0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp2s0
192.168.137.0   10.0.0.2        255.255.255.0   UG        0 0          0 tun0

alex843
() автор топика
Ответ на: комментарий от alex843

Да с таблицами у вас все норм, у вас конкретно не работает вот это iroute 192.168.137.0 255.255.255.0. Дело в том что сам сервер должен узнать какому клиенту должет отсылать пакеты именно для этого эта опция и нужна, в таблице роутинга вы этого не увидите.
В качестве предложения что бы убедиться что файлик читается и т.д.
На сервере остановите openvpn
Пререименуйте/удалите файл /etc/openvpn/ipp.txt
Создайте заново файл /etc/openvpn/client

iroute 192.168.137.0 255.255.255.0
ifconfig-push 10.0.0.17 10.0.0.18

Запустите openvpn
Соединитесь клиентом и посмотрите получит ли он соответствующий ip

anc ★★★★★
()
Ответ на: комментарий от anc

Я для особо одарённых пояснение прям сразу написал.

можно в конфиге клиента, да хоть руками на клиенте через ip route add... добавляй, роли не играет.

У - Удобство.

У меня, например, с помощью OpenVPN связаны две локалки и до кучи сам могу подключиться из любого места. Мне теперь в случае каких-то одвиже в сети править конфиги в куче мест, или поправить конфиг сервера и не заморачиваться с клиентами?

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

У - Удобство.

Ну так может человеку именно так удобно... Хтож знает... Вопрос про функционал: у него правильно написано - Правильно, к вопросу отношение имеет - Не имеет.
А вот излишества в виде push «route 192.168.137.0 255.255.255.0» явно лишнии, человек скопипастит а потом совсем по другой причине работать не будет.

anc ★★★★★
()
Ответ на: комментарий от anc

Большое спасибо! Файлик удалил, заново создал, ip остался старый. Залез в логи, смотрю имя клиента - а оно не совпадает с именем файлика клиента в папке ccd. После переименования файла все заработало как надо и пинги заходили в обе стороны!

alex843
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← makefile проверка пременной
Admin
Помер wireshark. →