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

OpenVPN доступ в подсеть клиента

 


1

2

Доброго времени суток.

Никак не могу разобраться с настройкой OpenVPN.

Схема: Client_A-----Server-----Client_B(роутер под DD-WRT)--Subnet

Задача: Получить доступ с Client_A к устройствам в Subnet.

Для начала стоит сказать что соединение через OpenVPN устанавливается нормально (конфиги и логи ниже). Client_B полностью доступен с Client_A как по своему VPN адресу, так и по локальному. Но любое устройство в подсети Client_B не доступно и на пинги не отвечает.

И вот тут начинается самое интересное. Если через, например, TeamViewer подключится к компьютеру из подсети Client_B то этот компьютер начинает отвечать на пинги, а роутер, как раз, отвечать перестаёт.

Конфиг: 

port 1498
proto udp
dev tun
 
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serv.crt
key /etc/openvpn/serv.key
dh /etc/openvpn/dh1024.pem
 
server 10.105.51.0 255.255.255.0

ifconfig-pool-persist ipp.txt
 
keepalive 10 120

route 192.168.1.0 255.255.255.0

client-config-dir ccd

client-to-client
push "route 192.168.1.0 255.255.255.0"

comp-lzo
cipher BF-CBC

persist-key
persist-tun
 
status /etc/openvpn/status_server.log
 
verb 3

Подсеть 192.168.1.x.
Client_B роутер с адресом 192.168.1.2.
Шлюз 192.168.1.1 ASDL модем.
В папке ccd на сервере имеется файл с именем Client_B содержащий строку 

iroute 192.168.1.0 255.255.255.0

Лог: 

OpenVPN CLIENT LIST
Updated,Wed Mar 12 13:57:18 2014
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
Client_B,xx.xx.xx.xx:xx,293083,56345,Wed Mar 12 13:24:57 2014
Client_A,xx.xx.xx.xx:xx,55578,299772,Wed Mar 12 13:23:26 2014
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.105.51.10,Client_B,xx.xx.xx.xx:xx,Wed Mar 12 13:25:10 2014
10.105.51.6,Client_A,xx.xx.xx.xx:xx,Wed Mar 12 13:42:28 2014
192.168.1.0/24,Client_B,xx.xx.xx.xx:xx,Wed Mar 12 13:24:59 2014
GLOBAL STATS
Max bcast/mcast queue length,1

Подключение к машине с адресом 192.168.1.3 через TeamViewer позвляет её пинговать пока идет сессия, а вот сам роутер 192.168.1.2 в это время не доступен. Подозреваю, корень проблемы находится в настройках роутера, а не самой VPN но понятия не имею, куда копать.

Заранее спасибо.

← не понимаю, как работает killall во фре?
Nagios разница между двумя проверками →

Клиенты из Subnet точно знают правильный маршрут до Client_A?

И вообще, покажи всюду роуты.

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

КлиентА

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface[br]
0.0.0.0         192.168.51.1    0.0.0.0         UG    0      0        0 eth0[br]
10.105.51.0     10.105.51.5     255.255.255.0   UG    0      0        0 tun0[br]
10.105.51.5     0.0.0.0         255.255.255.255 UH    0      0        0 tun0[br]
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0[br]
192.168.1.0     10.105.51.5     255.255.255.0   UG    0      0        0 tun0[br]
192.168.51.0    0.0.0.0         255.255.255.0   U     1      0        0 eth0[br]

192.168.51.0 локальная сеть КлиентаА

Комп за КлинтомБ:

Destination Gateway Genmask Flags Metric Ref Use Iface[br]
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0[br]
10.105.51.0     10.105.51.9     255.255.255.0   UG    0      0        0 tun0[br]
10.105.51.9     0.0.0.0         255.255.255.255 UH    0      0        0 tun0[br]
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0[br]
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0[br]

Судя по всему подсеть понятия не имеет, куда слать пакеты. Я так понимаю, я должен добавить машрут до моего КлиентаА, вот только какой он должен быть? К тому же, в сети имеются не только компьютеры но и прочие устройства, на андроиде например. Как с ними то бороться?

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

В папке ccd на сервере имеется файл с именем Client_B содержащий строку
iroute 192.168.1.0 255.255.255.0

А push «route 192.168.51.0 255.255.255.0» где? Откуда у тебя КлиентБ узнает, что на пакет, пришедший с 192.168.51.Х надо отвечать в tun?

Типовые ccd-файлы обычно имеют вид (для КлиентаХ):

push "route 192.168.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 192.168.3.0 255.255.255.0"
push "route 192.168.4.0 255.255.255.0"
iroute 192.168.X.0 255.255.255.0

где подсети 0-4 - это подсети за другими точками OpenVPN, в том числе и за сервером.

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

Спасибо за совет!

Добавил в ccd-файл строчку:

push «route 192.168.51.0 255.255.255.0» К сожалению ничего не изменилось. 192.168.1.2 пингуется - остальное нет.

Откуда у тебя КлиентБ узнает, что на пакет, пришедший с 192.168.51.Х надо отвечать в tun?

Разве КлиентБ получает а этом случае пакет с локального адреса КлиентаА, а не с его VPN адреса?

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

Разве КлиентБ получает а этом случае пакет с локального адреса КлиентаА, а не с его VPN адреса?

Судя по вашей схеме, у вас vpn не на КлиентеА. Соответственно, приходит на КлиентБ пакет с обратным адресом 192.168.51.5 (например), КлиентБ хочет ответить, смотрит что для 51 сети у него маршрута нет и отсылает его по дефолтному маршруту, который смотрит в локалку. Вот и вся история, можете проверить это tcpdump'ом.

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

Судя по вашей схеме, у вас vpn не на КлиентеА. Соответственно, приходит на КлиентБ пакет с обратным адресом 192.168.51.5

Но ведь КлиентА при этом является VPN клиентом и имеет свой VPN адрес. Или там пакеты получают сначала локальный 192.168.51.x адрес, а потом «оборачиваются» тунелем?

После добавления строки 

push «route 192.168.51.0 255.255.255.0»

в ccd файл наблюдаю на одной из машин в подсети КлиентаБ такую рутинговую таблицу: 

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.105.51.0     10.105.51.9     255.255.255.0   UG    0      0        0 tun0
10.105.51.9     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
192.168.51.0    10.105.51.9     255.255.255.0   UG    0      0        0 tun0

Тоесть машина в курсе, что есть такая сеть 192.168.51.0 и что ломиться в нее нужно через 10.105.51.9 (КлиентБ)

При этом с этой машины пингуются VPN адреса (КлиентБ, Сервер, КлиентА). Сеть 192.168.51.0 не пингуется ни в какую вообще.

Прослушка tun0 при пинге на 192.168.51.118 (адрес КлиентаА) выдает это: 

18:23:49.980755 IP 10.105.51.10 > 192.168.51.118: ICMP echo request, id 4526, seq 1, length 64
18:23:50.979778 IP 10.105.51.10 > 192.168.51.118: ICMP echo request, id 4526, seq 2, length 64
18:23:51.979760 IP 10.105.51.10 > 192.168.51.118: ICMP echo request, id 4526, seq 3, length 64
18:23:52.979783 IP 10.105.51.10 > 192.168.51.118: ICMP echo request, id 4526, seq 4, length 64
18:23:53.979760 IP 10.105.51.10 > 192.168.51.118: ICMP echo request, id 4526, seq 5, length 64

На КлиентеА tun0 в это время даже не чешется.

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

Но ведь КлиентА при этом является VPN клиентом и имеет свой VPN адрес.

Аааа. Я из схемы понял, что КлиентА находится в локалке за впн-сервером. Ну тогда и на КлиентеА надо всю маршрутизацию прописывать.

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

Добавил схожий ccd файл для КлиентаА - эффекта ноль.

Все больше убеждаюсь в том что проблема зарыта в настроках роутера, который КлиентБ.

Сегодня наблюдаю что то уже совсем странное. Роутер 192.168.1.2 и компьютер в его сети 192.168.1.3 играют в чехарду. Доступен то один, то другой, поочереди. Причем, если послушать tcpdump'ом машину 192.168.1.3 во время безуспешных попыток пропинговать пропавший роутер по его локальному адресу с КлиентаА, пакеты приходят именно на машину 192.168.1.3, хотя она находится ЗА роутером.

Есть у кого бубен на изгнание злых духов?

SOIMiMozO
() автор топика
19 августа 2014 г.
Ответ на: комментарий от SOIMiMozO

столкнулся с анологичной проблемой, думается мне что проблема заключается в самом openvpn. Схема моей сети имеет вид: 

subnet(192.168.1.0/24) client1(10.8.0.2)< - > Server VPN(ip 192.168.99.101)(default gateway for networks vpn network 10.8.0.0/24) - subnet 192.168.99.0/24 - некоторый клиент из этой сети с ip 192.168.99.100(S)


если стучать от client1(C1) до хоста S то никаких пробелем нет, пинги между ними ходят, при этом на S добавлен статический маршрут в виде 10.8.0.0/24 gw  192.168.99.101 это ни каких проблем не вызывает. 

S# ping 10.8.0.2 
success

C1# ping 192.168.99.100
success

а вот когда мы с S пытаемся сделать:
S# ping 192.168.1.15(который заведомо доступен)
fail




ServerVPN(SV)# ifconfig  ///вывод физических интерфейсов убрал
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.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:249461 errors:0 dropped:0 overruns:0 frame:0
          TX packets:247164 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:42268797 (40.3 MiB)  TX bytes:67181103 (64.0 MiB)



C1# ifconfig   ///вывод физических интерфейсов убрал
tun1      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.2  P-t-P:10.8.0.2  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:420 (420.0 B)  TX bytes:504 (504.0 B)


SV# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0    10.8.0.2        255.255.255.0 UG    0      0        0 tun0
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
192.168.99.0    *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1002   0        0 eth0
default         192.168.99.1    0.0.0.0         UG    0      0        0 eth0

C1# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         nn5-switch-cod. 0.0.0.0         UG    0      0        0 eth0.73
10.8.0.0        *               255.255.255.0   U     0      0        0 tun1
192.168.1.0    *               255.255.255.0 U     0      0        0 eth0.73
link-local      *               255.255.0.0     U     1000   0        0 eth0.73
192.168.44.0    *               255.255.255.0   U     0      0        0 tun0
192.168.99.0    10.8.0.1        255.255.255.0   UG    0      0        0 tun1
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0

Здесь мы видим, что пакеты уходят в нужный интерфейс 

SV# ping 192.168.1.15 &
SV# tcpdump -i tun0 src 192.168.1.15 or dst 192.168.1.15
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
11:43:14.279097 IP 10.8.0.1 > 192.168.1.15: ICMP echo request, id 2418, seq 1930, length 64
11:43:14.947102 IP 10.8.0.1 > 192.168.1.15: ICMP echo request, id 16500, seq 8, length 64
11:43:15.279090 IP 10.8.0.1 > 192.168.1.15: ICMP echo request, id 2418, seq 1931, length 64


C1# tcpdump -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
//тишина

ну и ессно: 

C1# iptables -L -n 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ip_forward 

C1# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1


SV# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Есть у кого-нить какие соображения или,может, даже решали подобную проблему, или знаете о существовании такого бага в openvpn?

l4h
()

на самом деле, мне не очень понятна таблица роутинга, если посмотреть на 

Virtual Address,Common Name,Real Address,Last Ref
10.105.51.10,Client_B,xx.xx.xx.xx:xx,Wed Mar 12 13:25:10 2014
10.105.51.6,Client_A,xx.xx.xx.xx:xx,Wed Mar 12 13:42:28 2014
192.168.1.0/24,Client_B,xx.xx.xx.xx:xx,Wed Mar 12 13:24:59 2014

и на 

КлиентА
192.168.1.0     10.105.51.5     255.255.255.0   UG    0      0        0 tun0[br]

то возникает вопрос, почему пакеты, которые должны идти через 10.105.51.1 затем на Client_B(прямая маршрутизация(т.е. отправлять пакеты сразу на 10.105.51.10,Client_B) у меня почему-то отказалась работать),а идут через 10.105.51.5? мне вот не очень понятно, куда они идут. пакеты с компов находящихся за твоим роутером(subnet client B) нужно отправлять по адресу 192.168.1.2, при этом на роутере надо сделать sysctl -s net.ipv4.ip_forward =1(в синтаксисе возможно ошибаюсь) для дебага не плохо было бы сбросить все запрещающие правила iptables -F, и установить дефолтную политику в accept. на самом же роутере прописать route к сети за клиентом А, если таковые нужны.

т.е. таблица роутинга твоего клиента за clientB должна быть: 

Destination Gateway Genmask Flags Metric Ref Use Iface[br]
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0[br]
10.105.51.0     192.168.1.2     255.255.255.0   UG    0      0        0 eth0[br]
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0[br]

а на clientB, clientA: 

Destination Gateway Genmask Flags Metric Ref Use Iface[br]
0.0.0.0         192.168.X.Y     0.0.0.0         UG    0      0        0 eth0[br]
10.105.51.0     0.0.0.0     255.255.255.0   UG    0      0        0 tun0[br]
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
192.168.X.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0[br]

где X -  номер физической сети к которой подключен комп, Y - номер дефолтного шлюза

l4h
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← не понимаю, как работает killall во фре?
Admin
Nagios разница между двумя проверками →