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

OpenVPN сервер не видит сеть за клиентом

 


0

2

Здравствуйте, прошу не кидаться тапками, тема уже набила многим оскомину, но решение моей проблемы на многочисленных форумах так и не было найдено. Проблема: Существует OenVPN сервер в интернете и локальная сеть 192.168.0.0 (маска 255.255.255.0 шлюз 192.168.0.254) в офисе. Машина с ip 192.168.0.68 подключена к Open VPN, адрес в сети openvpn 10.8.0.26.

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

port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
route 192.168.0.0 255.255.255.0
route 10.8.0.0 255.255.255.0
client-config-dir /etc/openvpn/ccd
client-to-client
keepalive 10 120
persist-key
persist-tun
status /var/log/openvpn-status.log
log        /var/log/openvpn.log
verb 3
auth-user-pass-verify /etc/openvpn/verify.sh via-file
client-cert-not-required
username-as-common-name
tmp-dir /etc/openvpn/tmp
script-security 2

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

client
dev tun
proto tcp
remote **** 1194
resolv-retry infinite 
nobind
ca ca.crt
persist-key
persist-tun
ns-cert-type server
pull
log openvpn7503.log
verb 3
auth-user-pass pass.txt

route -n сервера 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 venet0

route -n клиента 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 eth1
10.8.0.0        10.8.0.25       255.255.255.0   UG    0      0        0 tun0
10.8.0.25       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

На шлюзе 192.168.0.254 добавлен маршрут 10.8.0.0 255.255.255.0 gw 192.168.0.68

ip_forward на клиенте включен ip_tables на клиенте -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT

Вроде все должно работать, но traceroute с сервера доходит до машины клиента и на этом всё . 

traceroute to 192.168.0.87 (192.168.0.87), 30 hops max, 60 byte packets
 1  10.8.0.26 (10.8.0.26)  63.107 ms  173.297 ms  173.304 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
Головой понимаю, что скорее всего не хватает какого-то маршрута на клиенте, но понять какого именно не могу. traceroute с сервера до клиента 
traceroute to 192.168.0.68 (192.168.0.68), 30 hops max, 60 byte packets
 1  192.168.0.68 (192.168.0.68)  64.049 ms  143.736 ms  143.688 ms

P.S. заранее спасибо всем откликнувшимся



Последнее исправление: Fati (всего исправлений: 1)
← маршрут до VPN сервера через туннель
Кипит мозг от iptables →

чтобы это работало, 192.168.0.254 должен отсылать icmp redirect, а 192.168.0.87 их принимать, ну или надёжнее добавить маршрут на 10/ для машин в 192/ через 192.168.0.68

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

не совсем. Это сработает при условиях, о которых я писал выше. шлюз не будет пересылать пакет в той же подсети. он может сказать хосту, что пакеты туда-то нужно слать не через него, а через другой шлюз. Но это потенциальная дыра, поэтому часто отключено

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

Прошу прощения, но тогда я немного не поняла

Где добавить маршрут? Вроде с сервера данные доходят до машины 192.168.0.68, дальше уже они загибаются 

traceroute to 192.168.0.87 (192.168.0.87), 30 hops max, 60 byte packets
 1  10.8.0.26 (10.8.0.26)  63.107 ms  173.297 ms  173.304 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

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

а нельзя это сделать как-нибудь средствами OpenVPN, чтобы не прописывать на каждом отдельном компьютере путь?

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

Получается как-то так

168.192.0.68 (debi.local) клиент OpenVPN, 168.192.0.19 машина внутри сети 

PING 192.168.0.68 (192.168.0.68) 56(84) bytes of data.
64 bytes from 192.168.0.68: icmp_req=1 ttl=64 time=75.7 ms
64 bytes from 192.168.0.68: icmp_req=2 ttl=64 time=73.9 ms
64 bytes from 192.168.0.68: icmp_req=3 ttl=64 time=72.7 ms

--- 192.168.0.68 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 72.742/74.125/75.726/1.227 ms


PING 192.168.0.19 (192.168.0.19) 56(84) bytes of data.
--- 192.168.0.19 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms



listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
16:40:02.795205 IP 10.8.0.1 > debi.local: ICMP echo request, id 14291, seq 1, length 64
16:40:02.795253 IP debi.local > 10.8.0.1: ICMP echo reply, id 14291, seq 1, length 64
16:40:03.791867 IP 10.8.0.1 > debi.local: ICMP echo request, id 14291, seq 2, length 64
16:40:03.791906 IP debi.local > 10.8.0.1: ICMP echo reply, id 14291, seq 2, length 64
16:40:04.792558 IP 10.8.0.1 > debi.local: ICMP echo request, id 14291, seq 3, length 64
16:40:04.792601 IP debi.local > 10.8.0.1: ICMP echo reply, id 14291, seq 3, length 64
16:40:14.208937 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 1, length 64
16:40:15.204093 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 2, length 64
16:40:16.208621 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 3, length 64
16:40:17.196628 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 4, length 64
16:40:18.210091 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 5, length 64
16:40:19.211907 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 6, length 64
16:40:20.196561 IP 10.8.0.1 > 192.168.0.19: ICMP echo request, id 14292, seq 7, length 64
13 packets captured
13 packets received by filter
0 packets dropped by kernel

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

шлюз не будет пересылать пакет в той же подсети

Из чего следует такое утверждение?

Вроде бы чего хочет добиться ТС это ассиметричный путь следования трафика:

Туда:

10.8.0.1 -> 10.8.0.26/192.168.0.68 -(та же подсеть, поэтому напрямую)-> 192.168.0/24

Обратно:

192.168.0/24 -(нет маршрута до 10/8 поэтому на default gw)-> 192.168.0.254 -> 192.168.0.68/10.8.0.26 -> 10.8.0.1

Чисто умозрительно я не вижу здесь проблемы, кроме корявости решения.

Мой вопрос — есть какое-то правило, по которому роутеры не должны роутить трафик если gw для него лежит в той же подсети, где находится источник?

Думаю, что это если и реализуется, то как дополнительная функциональность при помощи netfilter. А т.к. сеть вроде бы внутренняя, то его можно и подоткрутить, чтобы он не отбрасывал подобный трафик.

ТС, надо смотреть в сторону настройки шлюза на предмет обработки такого трафика.

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

а нельзя это сделать как-нибудь средствами OpenVPN, чтобы не прописывать на каждом отдельном компьютере путь?

OpenVPN на компьютеры в сети клиента не может повлиять, но статические маршруты можно раздавать по DHCP, чтобы не прописывать на каждом.

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

Я не знаю, с линуксом знакома около месяца.

вот ifconfig на всякий случай.

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:3208 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3208 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:195380 (195.3 KB)  TX bytes:195380 (195.3 KB)

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:56 errors:0 dropped:0 overruns:0 frame:0
          TX packets:291 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5128 (5.1 KB)  TX bytes:18996 (18.9 KB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:4455873 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4918599 errors:0 dropped:209 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:797802856 (797.8 MB)  TX bytes:828424621 (828.4 MB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:*.*.*.*  P-t-P:*.*.*.*  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

Мне дали доступ по ssh на уже поставленную ос и сказали, что нужен доступ с домашнего компа во внутреннюю сеть офиса, от того и плясала. Системного администратора или человека разбирающегося в подобном в коллективе не обнаружилось. Кропотливо разбираться во всех нюансах нет времени, так как пора переключаться на другую задачу, а я никак не могу разобраться с этой.

Fati
() автор топика

Вот эта опция в конфиге сервера велит передать подключившемуся клиенту, чтобы он после подключения добавил маршрут до 192.168.0/24 через vpn-интерфейс. Если я правильно понял задачу, то это крайне странно, т.к. при попытке клиента соединиться с кем-то из своей подсети он будет слать пакеты OpenVPN серверу.

push "route 192.168.0.0 255.255.255.0"

Правда это предположение не согласуется с представленным выводом route -n на клиенте.

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

Но на всякий случай: пингуется ли тот же 192.168.0.19 с клиента при поднятом OpenVPN соединении?

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

push «route 10.8.0.0 255.255.255.0» я думаю это лишнее на клиенте. Он и так будет знать куда ему идти когда поднимится тунель.

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

Клиент внутри офиса на Debian, удаленный клиент Windows. На сервере стоит Ubuntu, и благодаря uspen, я знаю что используется OpenVZ виртуализация

push «route 10.8.0.0 255.255.255.0»

без этой строчки клиент Windows не пинговал сервер, пока сервер первым не пускал пинг, какой-то криминал, но эта строчка всё вылечила

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

Да, с этим всё в порядке. Это я

iroute 192.168.0.0 255.255.255.0

проглядел.

А что за операционка на 192.168.0.254? Есть ли возможность снять дамп трафика там, чтоб убедиться, что ответы на пинги приходят туда и там отбрасываются?

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

192.168.0.254 роутер TP-link Model No. TL-MR3020

с сервера OpenVPN роутер пингуется 

PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_req=1 ttl=63 time=111 ms
64 bytes from 192.168.0.254: icmp_req=2 ttl=63 time=88.3 ms
64 bytes from 192.168.0.254: icmp_req=3 ttl=63 time=97.4 ms

Еще одна странность Traceroute до машины внутри сети идет, а ping не проходит 

traceroute to 192.168.0.194 (192.168.0.194), 30 hops max, 60 byte packets
 1  10.8.0.6 (10.8.0.6)  111.939 ms  112.529 ms  112.494 ms
 2  192.168.0.194 (192.168.0.194)  112.467 ms  112.441 ms  112.410 ms
root@vm7503:/etc/openvpn# ping 192.168.0.194
PING 192.168.0.194 (192.168.0.194) 56(84) bytes of data.
--- 192.168.0.194 ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 17006ms

Пинг с 192.168.0.194 на OpenVPN сервер идет, и после этого OpenVPN сервер начинает пинговать 192.168.0.194. 

PING 192.168.0.194 (192.168.0.194) 56(84) bytes of data.
64 bytes from 192.168.0.194: icmp_req=1 ttl=127 time=91.0 ms
64 bytes from 192.168.0.194: icmp_req=2 ttl=127 time=95.4 ms
--- 192.168.0.194 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 91.077/93.287/95.498/2.231 ms

Fati
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← маршрут до VPN сервера через туннель
Admin
Кипит мозг от iptables →