LinuxForum.Fans
Тема

openvpn сеть за....(маршрутизация)

Автор: u________36 31 сообщений 6983 просмотров
09.09.2014 14:27 · отредактировано #392325

всем доброго дня! Знаю, что яндекс выдает кучу статей по сабжу. и половина из них начинается с "нигде не нашел, а надо было так...", но ответа на свой вопрос так и не нашел. а так же подразумеваю, что вопрос скорее по маршрутизации, нежели по, собственно, openvpn

итак, имеем 2 сети. 192.168.3.0/24 (главный офис) и 192.168.33.0/24 (филиал). в каждой сети есть роутер, одним концом в локаль, другим в интернет. хочется поставить отдельные машинки с Debian и поднять на них впн так, чтобы сети видели друг-друга

как-то так должно выглядеть https://yadi.sk/i/HFZw_bK0bJ388

впн сервер:
eth0 192.168.3.101
tun0 10.8.0.1

конфиг:

text
port 1194                                
proto udp                                
dev tun                                
ca /etc/openvpn/easy-rsa/keys/ca.crt        
cert /etc/openvpn/easy-rsa/keys/server.crt    
key /etc/openvpn/easy-rsa/keys/server.key    
dh /etc/openvpn/easy-rsa/keys/dh1024.pem    
server 10.8.0.0 255.255.255.0            
ifconfig-pool-persist ipp.txt
keepalive 10 120    
komp-lzo            
persist-key        
persist-tun
verb 3        
client-config-dir ccd                
push "route 192.168.3.0 255.255.255.0"    
route 192.168.33.0 255.255.255.0    

# Затем создал файл ccd/client, содержащий такую строку: iroute 192.168.33.0 255.255.255.0

log /etc/openvpn/logs/openvpn.log status /etc/openvpn/logs/openvpn-status.log

файле /etc/sysctl.conf раскомментировал строчку: net.ipv4.ip_forward=1

на роутере в сети сервера (192.168.3.1) (он же является шлюзом по-умолчанию для всех пк сети) прописал маршрут вида: все, что в 192.168.33.0/24 и в 10.8.0.0/24 - через 192.168.3.101


впн клиент:
eth0 192.168.33.148
tun0 10.8.0.6 (такой получает от впн-сервера. специально нигде не указывал)

конфиг:

text
client
dev tun                
proto udp                
remote x.x.x.x 1194
resolv-retry infinite    
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt                
cert /etc/openvpn/keys/client.crt        #
key /etc/openvpn/keys/client.key        #
ns-cert-type server
comp-lzo    
log /etc/openvpn/logs/openvpn.log
verb 3        

так же включил пересылку между интерфейсами (файле /etc/sysctl.conf раскомментировал строчку: net.ipv4.ip_forward=1)
на роутере (192.168.33.149) (он же является шлюзом по-умолчанию для всех пк сети) прописал маршрут вида: все, что в 192.168.3.0/24 и в 10.8.0.0/24 - через 192.168.33.148


и вот тут уперся лбом в стену. при таком раскладе:
из сети клиента (с машинки 192.168.33.80) пингуется:
- впн-клиент по обоим интерфейсам (10.8.0.6, 192.168.33.148)
- впн-сервер по обоим интерфейсам (10.8.0.1, 192.168.3.101)
и все. дальше сервера пакеты не пошли
так же ведут себя пинги и с самого впн-клиента (192.168.33.148)

из сети сервера (с машинки 192.168.3.10) пингуется:
- впн-сервер по обоим интерфейсам (10.8.0.1, 192.168.3.101)
- впн-клиент по обоим интерфейсам (10.8.0.6, 192.168.33.148)
дальше клиента пакеты не идут. пинги с самого впн-сервера ведут себя так же.

мат часть ниже плинтуса, потому не совсем понятно какими средствами разруливать дальше. на сколько я понимаю, от openvpn я итак уже все что нужно получил. дальше нужно маршрутизировать пакеты иными средствами? или я не прав и что-то недокрутил в конфигах?
В сети часто предлагают маскарадинг
например, на впн-сервере пишу

text
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

. В этом случае с клиента начинает пинговатсья сеть за сервером, но, из сети за клиентом она не пингуется, а адресом источника пакетов выставляется ip впн- сервера, что логично, но не удобно. хотелось бы видеть реальный ip-адрес источника.
и вообще, мне кажется, что NAT - не лучший претендент в данном случае. с наскока iptables взять не получилось, но там есть цепочки forwarding. может правильно использовать ее? только хз как. или вообще маршрут в ruote прописать надо? но тогда какой? никак не соображу в каком месте затыкается пакет и как правильно его прогнать

буду признателен за любую помощь

09.09.2014 14:40 · отредактировано #392327

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

10.09.2014 12:18 #392371

так в моем случае они не могут быть шлюзами для локальных сетей. шлюзом для сети является роутер (см. картинку в 1 посте) через который достижим интернет и в т.ч. внешний ip главного офиса с VPN-сервером

сейчас получается следующая картина
на сервере:

text
~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.3.1     0.0.0.0         UG    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        *               255.255.255.255 UH    0      0        0 tun0
192.168.3.0     *               255.255.255.0   U     0      0        0 eth0
192.168.33.0    10.8.0.2        255.255.255.0   UG    0      0        0 tun0

на клиенте:

text
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.33.149  0.0.0.0         UG    0      0        0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
192.168.3.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.33.0    *               255.255.255.0   U     0      0        0 eth0

добавить маршрут с сервера сразу в 192.168.33.0/24 через 192.168.33.148 - не получается, т.к. tun0 интерфейс не знает этой подсети.

по идее, когда я пингую с компа из-за сервера внутренний адрес впн-клиента (192.168.3.10 -> ping 192.168.33.148) пинг с моего компа идет на шлюз по-умолчанию (мой роутер), оттуда заворачивается на локальный адрес впн-сервера, оттуда транслируется на tun интерфейс, передается на впн-клиент и транслируется на eth интерфейс впн-клиента.
192.168.3.10 -> 192.168.3.1 -> 192.168.3.101 -> 10.8.0.1 -> 10.8.0.6 -> 192.168.33.148

(vpn похоже использует чуток другие адреса для передачи внутри туннеля 10.8.0.2 для сервера и 10.8.0.5 для клиента)

text
# ifconfig tun0
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:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2651 (2.5 KiB)  TX bytes:10076 (9.8 KiB)

и то же для клиента

text
 inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255 

для tracert тунель прозрачен (да, на рабочих станциях винда)

text
tracert 192.168.33.148

Трассировка маршрута к 192.168.33.148 с максимальным числом прыжков 30

1 <1 мс <1 мс <1 мс 192.168.3.1 2 3 ms 3 ms 2 ms 192.168.3.101 3 47 ms 45 ms 46 ms 192.168.33.148

Трассировка завершена.

а трассировка до компа за клиентом выглядит так:

text
tracert 192.168.33.80

Трассировка маршрута к 192.168.33.80 с максимальным числом прыжков 30:

1 1 ms <1 мс 1 ms 192.168.3.1 2 <1 мс <1 мс <1 мс 192.168.3.101 3 46 ms 45 ms 45 ms 10.8.0.6 4 * * * Превышен интервал ожидания для запроса. 5 * * * Превышен интервал ожидания для запроса.

может загвоздка в том, что маршрут нужен с интерфейса 10.8.0.6? раз tracert указывает туда? а все, что создает openvpn используют 10.8.0.5


и еще по ходу возник вопрос: попытался со своей тачки за сервером подключиться к клиенту по ssh. putty черное окно открывает, но приглашения на ввод пользователя не дает
а netstat на клиента показывает

text
~# netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 10.8.0.6:22             192.168.3.10:48080      SYN_RECV
tcp        0      0 192.168.33.148:22        192.168.3.10:51034      SYN_RECV
tcp        0    132 192.168.33.148:22       192.168.33.80:1615      ESTABLISHED

это настройки ssh-сервера нужно крутить или где-то обратный маршрут тупит или iptables нужно подкручивать, чтобы пропускал ? (хотя вроде как в правилах пусто).

10.09.2014 12:27 · отредактировано #392372
"Ленивый" написал:
см. картинку в 1 посте

Я не вижу вашу картинку, да и остальные участники форума, скорее всего тоже, вот как у меня она отображается:

"Ленивый" написал:
так в моем случае они не могут быть шлюзами для локальных сетей.

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

на шлюзе VPN клиента пропишите маршрут, что локальная сеть за VPN сервером доступна через IP адрес из локальной VPN клиента

text

ip route add 192.168.3.0/24 via 192.168.33.148

, а на самом VPN клиенте проложите маршрут, что локальная сеть VPN сервера доступна через IP адрес сервера из VPN сети;

text

ip route add 192.168.3.0/24 via 10.8.0.1

на шлюзе VPN сервера пропишите маршрут, что локальная сеть за VPN клиентом доступна через IP адрес из локальной VPN сервера

text

ip route add 192.168.33.0/24 via 192.168.3.101

, а на самом VPN сервере проложите маршрут, что локальная сеть VPN клиента доступна через IP адрес клиента из VPN сети;

text

ip route add 192.168.33.0/24 via 10.8.0.6

Ну и задействует IP_FORWARDING на системах VPN сервера и VPN клиента.

"Ленивый" написал:

tun0 10.8.0.6 (такой получает от впн-сервера. специально нигде не указывал)

Сделайте, что бы VPN клиент всегда получал этот IP адрес.


Или можете настроить маршруты, только на шлюзах:

на шлюзе VPN клиента пропишите маршрут, что локальная сеть за VPN сервером доступна через IP адрес VPN сервера из VPN сети

text

ip route add 192.168.3.0/24 via 10.8.0.1

, а сам VPN сервер по IP адресу 10.8.0.1 доступен через IP адрес VPN клиента из локальной сети;

text

ip route add 10.8.0.1 via 192.168.33.148

на шлюзе VPN сервера пропишите маршрут, что локальная сеть за VPN клиентом доступна через IP VPN клиента из VPN сети

text

ip route add 192.168.33.0/24 via 10.8.0.6

, а сам VPN клиент по IP адресу 10.8.0.6 доступен через IP адрес VPN сервера из локальной сети;

text

ip route add 10.8.0.6 via 192.168.3.101

ВАЖНО:
Только во втором случае вам нужно вначале добавить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.

10.09.2014 14:03 #392377

да, с картинкой какая-то лажа. давайте попробуем вот так. я же старался, рисовал =)
https://yadi.sk/i/HFZw_bK0bJ388

маршруты на шлюзе уже прописаны, форвардинг включен. в первом посте это есть

файле /etc/sysctl.conf раскомментировал строчку: net.ipv4.ip_forward=1

на роутере в сети сервера (192.168.3.1) (он же является шлюзом по-умолчанию для всех пк сети) прописал маршрут вида: все, что в 192.168.33.0/24 и в 10.8.0.0/24 - через 192.168.3.101
на роутере (192.168.33.149) (он же является шлюзом по-умолчанию для всех пк сети) прописал маршрут вида: все, что в 192.168.3.0/24 и в 10.8.0.0/24 - через 192.168.33.148

а вторая часть совета не прокатывает:

клиент:

text
ip route add 192.168.3.0/24 via 10.8.0.1
RTNETLINK answers: Network is unreachable  

сервер:

text
# ip route add 192.168.33.0/24 via 10.8.0.6
RTNETLINK answers: No such process

прописать все на шлюзе не получилось. задал в веб-морде эти правила на шлюзе сервера - перестал пинговаться локальный интерфейс впн-клиента (192.168.33.148). т.е. пакеты не идут через 10.8.0.6. попробовал подрубиться к железке по ssh - в таблице маршрутизации нет этих правил. она реализует это как-то иначе. боюсь, если полезу править табличку руками - не испортить бы уже существующие маршруты


есть еще варианты? может поставить снифер и посмотреть на каком этапе какие пакеты проходят?

10.09.2014 14:08 #392378

я так понимаю, что раз пинги от компа за клиентом доходят до локального интерфейса ВПН сервера и не доходят до сети аз сервером, загвозка кроестя в том, что в первом случае последний шаг реализуется через форвардинг между интерфейсами, а во втором - нужен маршрут с впн-адреса впн-сервера на локальный адрес впн-сервера. т.е. пакеты, пришедние на 10.8.0.1 нужно направить на 192.168.3.101. но route этого не может, т.к. интерфейсы разные. может таки iptables forwarding здесь поможет?

10.09.2014 14:21 #392379

или iptables не делает форвардинг а только пропускает или не пропускает пакеты? что-то я уже совсем запутался

10.09.2014 14:52 #392381

опять я где-то не прав
в моей же таблице маршрутизации клиента есть такая строка.

"Ленивый" написал:
192.168.3.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0

т.е. маршрутизация между интерфесами должна работать.
ничего не понимаю

10.09.2014 15:52 · отредактировано #392385
"Ленивый" написал:
а вторая часть совета не прокатывает:
ip route add 10.8.0.6 via 192.168.3.101
Вы вот это прочитали?

"kostik87" написал:
ВАЖНО:
Только во втором случае вам нужно вначале добавить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.авить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.

Т.е. в начале на шлюзе прописываете первый маршрут, а затем второй:

text

ip route add 10.8.0.1 via 192.168.33.148
text

ip route add 192.168.3.0/24 via 10.8.0.1

и соответственно для другого шлюза

text

ip route add 10.8.0.6 via 192.168.3.101
text

ip route add 192.168.33.0/24 via 10.8.0.6

Ну и попробуйте tap интерфейс вместо tun.

10.09.2014 16:27 #392389

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

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

пингуемся с впн-сервером и пк за клиентом:

192.168.33.80: ping 10.8.0.1 - все ок. т.е. маршрут через роутер и впн-клиент до впн-сервера работает
10.8.0.1: ping 192.168.33.80 - вижу на 33.80 пакеты

text
src 10.8.0.1 dst 192.168.33.80 icmp echo request
src 192.168.33.80  dst 10.8.0.1 icmp echo reply

более того, пингую пк за клиентом с пк за сервером и вижу в снифере ту же фигню.

ы iptables-ах пусто и на клиенте и на сервере

text
# iptables -L
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

на клиенте нет антивирусника и выключен брендмауер. ос = winXP

почему еще могут пакеты теряться?

а на пк за сервером я тоже вижу входящие icmp пакеты

text
1298    13.133532000    192.168.33.80    192.168.3.10    ICMP    74    Echo (ping) request  id=0x0200, seq=45312/177, ttl=125 (no response found!) 
text
158    2.412619000    10.8.0.6    192.168.3.10    ICMP    98    Echo (ping) request  id=0x09b8, seq=10/2560, ttl=63 (no response found!)

но ответных он даже не пытается послать, хотя успешно пигнует 10.8.0.6

на пк за сервером выключен антивирус и бренмауер ос win8.1x64

10.09.2014 16:34 #392390

и похоже, дело не в винде. покрайней мере линуксовая тачка в сети за сервером так же не пингуется при прочих равных

10.09.2014 16:42 #392391
"Ленивый" написал:
как я понял вы предложили 2 разных решения. по первому - не дает задать такой маршрут

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

"Ленивый" написал:
а по второму - роутер как-то странно делает маршрутизацию. все что делается в веб-морде не отображается в таблице route. и я решил ее не трогать

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

"Ленивый" написал:
зато я поставил снифер на пк за клиентом и вижу, что пакеты пинга до него доходят! и генерятся обратные. только вот обратные где-то теряются по пути.
подробнее:
...

Вы же маршруты не добавили, вот и не пингуется ничего.

"Ленивый" написал:
на пк за сервером выключен антивирус и бренмауер ос win8.1x64

Это возможная причина того, что не идут ping`и. В частности брандмауер.

10.09.2014 16:43 · отредактировано #392392
"Ленивый" написал:
и похоже, дело не в винде. покрайней мере линуксовая тачка в сети за сервером так же не пингуется при прочих равных

Пока вы не создадите маршруты либо по первому либо по второму способу ничего не будет пинговаться. И всё же смените тип интерфейса на tap вместо tun.

Ну и удостоверьтесь, что на WinXP, если это ваш VPN клиент так же разрешён IP Forwarding, в любом случае он должен быть разрешён на VPN клиенте и сервере.

Вот для WIndows XP: http://support.microsoft.com/kb/315236/ru

11.09.2014 08:31 #392422
"kostik87" написал:
Что за роутер и что за веб морда, попробуйте в ручную добавить маршруты из консоли.

сейчас это Endian Firewall. в реальных условиях - может быть что угодно. причем в сети за сервером это рабочий роутер и положить его - большая беда

"kostik87" написал:
В частности брандмауер.

да, там у меня написано, что я все отключил. это первое, на что я подумал.

"kostik87" написал:
И всё же смените тип интерфейса на tap вместо tun.

а что это даст? как я понял, в этом случае у меня будет единая подсеть с обоих концов впн, например 192.168.33.0/24 и там и тут. и броадкасты полезут в туннель, что тоже не есть гуд. это в реальных условиях придется все сетки во всех филиалах и в голове перетрясать

"kostik87" написал:
что на WinXP, если это ваш VPN клиент

оси в схеме:
сеть за клиентом: windows XP
vpn-client: raspbian
сеть за сервером: windows8.1
vpn-server: debian

"kostik87" написал:
Покажите что происходит при попытке задания маршрута

уже показывал


а вторая часть совета не прокатывает:

клиент:

ip route add 192.168.3.0/24 via 10.8.0.1
RTNETLINK answers: Network is unreachable

сервер:

# ip route add 192.168.33.0/24 via 10.8.0.6
RTNETLINK answers: No such process
"kostik87" написал:
Вы же маршруты не добавили, вот и не пингуется ничего.

у меня в частности на роутере сервера есть маршруты
from 192.168.3.10 to 192.168.33.0/24 via 192.168.3.101
from 192.168.3.10 to 10.8.0.0/24 via 192.168.3.101

и аналогично на клиенте.

получается, что пинг из точки А в точку Б доходит в Б и возвращается обратно. а пинг из точки Б в точку А либо затыкается в точке А(в случае с сетью за сервером) либо теряется где-то по пути А->Б (в случае с сетью за клиентом). Я не понимаю, если он знает как послать echo request, почему echo reply не идет тем же маршрутом?

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

а еще, когда пингуется локальный адрес впн-сервера / клиента из сети за клиентом / сервером - впн-адреса 10.8.0.х не отображаются в tracert. а когда стучусь дальше за впн - tracert затыкается какраз на них. может как раз в этом проблема?

11.09.2014 09:10 #392425
"Ленивый" написал:
уже показывал
а вторая часть совета не прокатывает:
клиент:
ip route add 192.168.3.0/24 via 10.8.0.1
RTNETLINK answers: Network is unreachable 
сервер:
# ip route add 192.168.33.0/24 via 10.8.0.6
RTNETLINK answers: No such process

Уважаемый, я вам ещё раз пишу:

kostik87 написал:

Вы вот это прочитали?
kostik87 пишет:
ВАЖНО:
Только во втором случае вам нужно вначале добавить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.авить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.

Т.е. в начале на шлюзе прописываете первый маршрут, а затем второй:
ip route add 10.8.0.1 via 192.168.33.148
ip route add 192.168.3.0/24 via 10.8.0.1
и соответственно для другого шлюза
ip route add 10.8.0.6 via 192.168.3.101
ip route add 192.168.33.0/24 via 10.8.0.6
Ну и попробуйте tap интерфейс вместо tun.
"Ленивый" написал:
у меня в частности на роутере сервера есть маршруты
from 192.168.3.10 to 192.168.33.0/24 via 192.168.3.101
from 192.168.3.10 to 10.8.0.0/24 via 192.168.3.101

Это из web интерфейса? Вводите маршруты в консоли посредством iproute2 как я вам уже написал, оставьте в покое вы этот web интерфейс. Если там есть конечно iproute2.

"Ленивый" написал:

почему маршрут не добавляется?

Потому, что вы не читаете то, что я вам написал:

kostik87 написал:

Вы вот это прочитали?
kostik87 пишет:
ВАЖНО:
Только во втором случае вам нужно вначале добавить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.авить маршруты до участников VPN сети через IP адреса участников в локальной сети, а потом прописывать маршруты до локальных сетей, т.е. во втором случае на шлюзе создаёте в начале второй маршрут, а затем первый.

Т.е. в начале на шлюзе прописываете первый маршрут, а затем второй:
ip route add 10.8.0.1 via 192.168.33.148
ip route add 192.168.3.0/24 via 10.8.0.1
и соответственно для другого шлюза
ip route add 10.8.0.6 via 192.168.3.101
ip route add 192.168.33.0/24 via 10.8.0.6
Ну и попробуйте tap интерфейс вместо tun.

Можно для начала сделать проще, просто на VPN клиенте создаёте маршрут

text

ip route add 192.168.3.0/24 via 10.8.0.1

На VPN сервере

text

ip route add 192.168.33.0/24 via 10.8.0.6

Всё, пробуете с VPN клиента пинговать локальный IP адрес сервера:

text

ping 192.168.3.101

А с VPN клиента пробуете пинговать локальый IP адрес клиента:

text

ping 192.168.33.148

Всё, пинги должны идти.

Теперь на роуетрах прокладываете маршруты до локальных сетей за VPN сервером и VPN клиентом через локальный IP адрес VPN сервера и VPN клиента, готово., это как раз первый способ:

text

ip route add 192.168.3.0/24 via 192.168.33.148

и

text

ip route add 192.168.33.0/24 via 192.168.3.101

Ну или реализуйте второй способ сразу целиком на шлюзах.

Ну или наймите системного администратора, который вам пропишет указанные маршруты.

11.09.2014 09:39 #392430

так, стоп. маршруты которые вначале этот, потом тот нужно писать на роутере или на vpn-сервере / клиенте?

11.09.2014 09:57 · отредактировано #392434
"Ленивый" написал:
так, стоп. маршруты которые вначале этот, потом тот нужно писать на роутере или на vpn-сервере / клиенте?

Прочитайте вот это сообщение openvpn сеть за....(маршрутизация) ещё раз, там два способа и там указано где какой и где прописывать маршруты и вот в этом сообщении openvpn сеть за....(маршрутизация) тоже указано где прописывать маршруты.

В предыдущем сообщении я вам предложил для начала проложить маршрут между участниками VPN канала до их локальных сетей и проверить что идёт ping между их локальными интерфейсами.

Ещё раз прочитайте всё внимательно и разберётесь. Не пропустите комментарий после слова "ВАЖНО".

Если для вас всё это сложно то обратитесь к специалисту, который может придти к вам и настроить маршрутизацию.

При добавлении маршрута учитывайте то, что до всех участников добавляемого маршрута должны быть уже проложены маршруты либо они видны напрямую и всё получится. Прочитайте ещё раз указанные сообщения и постарайтесь понять почему добавляются эти маршруты и именно в такой последовательности, во втором способе нужно поменять очерёдность добавления маршрутов, об этом я вам написал после слова "ВАЖНО:".

11.09.2014 15:27 #392481

А где в серверном конфиге опция client-to-client ?, которая как раз и разрешает маршрутизацию между подсетями.

12.09.2014 08:18 #392508
"JonnyBekoff" написал:
А где в серверном конфиге опция client-to-client ?, которая как раз и разрешает маршрутизацию между подсетями.

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

12.09.2014 08:40 #392511

Дело здесь не в маршрутизации, в iptables в FORWARD нужно разрешить tun0, например:

text

$IPTABLES -A FORWARD -i tun0 -j ACCEPT
$IPTABLES -A FORWARD -o tun0 -j ACCEPT
Войдите или зарегистрируйтесь, чтобы ответить.