Как настроить маршрутизацию VPN-соединений?

Question

[Falseclock]

+-------- CLIENT --------+     +-------- ROUTER -------+     +----VPN SERVER -----+
| local: 192.168.100.102 | ==> | LAN: 192.168.100.0/24 |     | LAN: 172.16.0.0/24 |
+------------------------+     | VPN local: 10.8.0.6   | ==> | IP: 172.16.0.5     |
                               | VPN remote: 10.8.0.5  |     | VPN: 10.8.0.1      |
                               +------ VPN CLIENT -----+     +--------------------+
                                                                       |
                                                                       |
                                                                       |
                                                             +------ SHARE -------+
                                                             | LAN: 172.16.0.0/24 |
                                                             | IP: 172.16.0.4     |
                                                             +--------------------+

Все машины клиентской сети сети имеют прозрачный VPN до сервера через роутер.

Клиент (192.168.100.102) может пинговать внутренний IP VPN сервера, но не может пинговать другие адреса из этой сети (например 172.16.0.4).

Лог с клиентской машины

D:\>ping 172.16.0.5

Pinging 172.16.0.5 with 32 bytes of data:
Reply from 172.16.0.5: bytes=32 time=19ms TTL=62
Reply from 172.16.0.5: bytes=32 time=11ms TTL=62
Reply from 172.16.0.5: bytes=32 time=9ms TTL=62
Reply from 172.16.0.5: bytes=32 time=10ms TTL=62

Ping statistics for 172.16.0.5:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 19ms, Average = 12ms

D:\>ping 172.16.0.4

Pinging 172.16.0.4 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 172.16.0.4:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

D:\>tracert -d 172.16.0.5

Tracing route to 172.16.0.5 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.200.1
  2     2 ms     1 ms    <1 ms  192.168.100.1
  3     8 ms    10 ms     8 ms  172.16.0.5

Trace complete.

D:\>tracert -d 172.16.0.4

Tracing route to 172.16.0.4 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.200.1
  2    34 ms     3 ms     1 ms  192.168.100.1
  3    18 ms    18 ms    17 ms  10.8.0.1
  4     *        *        *     Request timed out.
  5  ^C
D:\>

В тоже время сам роутер может достучаться до любой машины сети 172.16.0.0/24. Но в двух случаях роутинг разный.

Лог с роутера

root@vt-gw0:~# traceroute 172.16.0.5
traceroute to 172.16.0.5 (172.16.0.5), 30 hops max, 38 byte packets
 1  172.16.0.5 (172.16.0.5)  3.592 ms  2.815 ms  2.808 ms
root@vt-gw0:~# traceroute 172.16.0.4
traceroute to 172.16.0.4 (172.16.0.4), 30 hops max, 38 byte packets
 1  10.8.0.1 (10.8.0.1)  11.759 ms  8.433 ms  4.442 ms
 2  172.16.0.4 (172.16.0.4)  3.630 ms  2.962 ms  2.387 ms
root@vt-gw0:~#
root@vt-gw0:~# ping 172.16.0.5
PING 172.16.0.5 (172.16.0.5): 56 data bytes
64 bytes from 172.16.0.5: seq=0 ttl=64 time=9.557 ms
64 bytes from 172.16.0.5: seq=1 ttl=64 time=4.015 ms

--- 172.16.0.5 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 4.015/6.786/9.557 ms
root@vt-gw0:~# ping 172.16.0.4
PING 172.16.0.4 (172.16.0.4): 56 data bytes
64 bytes from 172.16.0.4: seq=0 ttl=63 time=14.421 ms
64 bytes from 172.16.0.4: seq=1 ttl=63 time=4.235 ms

--- 172.16.0.4 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 4.235/9.328/14.421 ms

root@vt-gw0:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
172.16.0.0      10.8.0.5        255.255.255.252 UG    0      0        0 tun1
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun1
172.16.0.0      10.8.0.5        255.255.255.0   UG    0      0        0 tun1
192.168.10.0    10.8.0.5        255.255.255.0   UG    0      0        0 tun1
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 vlan2
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 vlan2
root@vt-gw0:~# ip route list
10.8.0.5 dev tun1  proto kernel  scope link  src 10.8.0.6
192.168.100.0/24 dev br0  proto kernel  scope link  src 192.168.100.1
10.8.0.0/24 via 10.8.0.5 dev tun1
172.16.0.0/24 via 10.8.0.5 dev tun1
192.168.10.0/24 via 10.8.0.5 dev tun1
192.168.10.0/24 dev vlan2  proto kernel  scope link  src 192.168.10.79
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
127.0.0.0/8 dev lo  scope link
default via 192.168.10.1 dev vlan2

Что бы такое сделать, чтобы клиентские машины видели IP адреса со всей сети 172.16.0.0/24, а не только адрес VPN сервера?

Answer 1

[kodi]

@Falseclock
на Share машинах VPN-server прописан в качестве основного шлюза или нет?
или на Share машина прописан маршрута до сети 192.168.100.0/24?

Comments

[Falseclock]

@kodi

мне не нужно чтобы SHARE видела клиентскую сеть.
РОУТЕР видит SHARE
VPN сервер видит SHARE
клиент видит VPN SERVER

клиент НЕ видит SHARE

[kodi]

@Falseclock Вы так и не ответили на вопрос про основной шлюз.

>"мне не нужно чтобы SHARE видела клиентскую сеть. "
Это и есть Ваша базовая ошибка, если Share не будет видеть клиентскую сеть, то как она будет ей отвечать? ;) У Вас как раз и получается, что пакеты в одну сторону ходят, а обратно нет. Результат - нет связи.

[Falseclock]

@kodi
сейчас попробую потестировать с роутингом, правда точно как нужно не имею понятия, но попробую.

а как тогда интернет работает? я сижу за DMZ зоной и пингу гугл. Гугл отвечает не мне же конкретно, а роутеру, где в пакете есть маркер кто кому слал и как обратно отвечать... в итоге пакет ко мне возвращается

[kodi]

@Falseclock попытайтесь все же ответить на поставленный ранее мною вопрос "на Share машинах VPN-server прописан в качестве основного шлюза или нет?"

[Falseclock]

@kodi, нет. SHARE одним интерфейсом смотрят наружу, а другим внутрь.

[kodi]

@Falseclock ааа, т.е. тогда все верно. какая ОС там?
сделайте tracert или traceroute на 172.16.0.4 до 192.168.100.102 и покажите результат

[Falseclock]

@kodi
везде стоит *nix
на SHARE сделал роутинг
route add -net 192.168.100.0 netmask 255.255.255.0 gw 172.16.0.5

теперь клиентские машины видят (пингуют) SHARE! Алилуйя!

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

root@ns2:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 89.218.18.81 0.0.0.0 UG 0 0 0 eth0
89.218.18.80 0.0.0.0 255.255.255.248 U 0 0 0 eth0
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.100.0 172.16.0.5 255.255.255.0 UG 0 0 0 eth1
root@ns2:~# traceroute -d 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
1 172.16.0.5 (172.16.0.5) 0.603 ms 0.563 ms 0.525 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C

[Сергей]

Я бы не стал так делать. Писать маршруты у клиентов не спортивно.
Маршрутами должен рулить шлюз. Пишите на нем.
Так же VPN сам по себе маршрутизатор, обычно сервер VPN строит свои маршруты.

[Falseclock]

@bk0011m а на клиентах никто и не прописывает маршруты

[Сергей]

@Falseclock Ок. Я думал SHARE это клиенты. Раз там есть свой шлюз, и маршрут на нем, то тогда респект.
Вопрос, а какой у вас софт, или железка в качестве VPN?

[Falseclock]

@bk0011m
Сервер HP DL380
на нем крутится гипервизор Citrix XenServer
в качестве VPN сервера - Debian + OpenVPN

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

[Сергей]

@Falseclock OpenVPN сам строит маршруты, которые берет из своих настроек.
На сервере в конфиге должны быть записи типа:

push "route 192.168.100.0 255.255.255.0"
push "route 172.16.0.0 255.255.255.0"

[Falseclock]

@bk0011m

Да, спасибо. Все уже есть. Работает как надо.
push "route 192.168.100.0 255.255.255.0" # Office1
push "route 192.168.10.0 255.255.255.0" # Office2
push "route 172.16.0.0 255.255.255.0" # SHARES

route 192.168.100.0 255.255.255.0 # Office
route 192.168.10.0 255.255.255.0 # Home

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

Правда пока сами SHARE не видят клиентскую сеть. Другими словами SYN соединение CLIENT -> SHARE работает, а вот SYN SHARE -> CLIENT пока не хочет. Вроде бы пока и не надо, но думаю как приспичит - разберусь.

[kodi]

@Falseclock
т.е. с 192.168.100.102 пингует 172.16.0.4, а наоборот нет?
фаерволлы включены?
про PUSH Вы пишите, это OpenVPN? Это к чему?

[Falseclock]

@kodi

да, так и есть, с 192.168.100.102 пингует 172.16.0.4, а наоборот нет

PUSH да, по OpenVPN. Выше уточняли

[Falseclock]

@kodi, @bk0011m, спасибо. Вроде все заработало. Пинг в обе стороны заработал. Обнулил все iptables и все заработало.

[kodi]

@Falseclock удачи, обращайтесь.

Answer 2

[Сергей]

Наверняка ведь есть файрвол, значит надо разрешить на рутере хождение с 192.168.100.0/24 на 172.16.0.0/24
Возможно и на VPN SERVER тоже. Если там файрвол есть
Так же в настройках VPN SERVER надо указать что сеть 192.168.100.0/24 находится на внешнем интерфейсе. Так же нужно дать на эту сеть маршрут через ROUTER.
И на ROUTER сделать тоже самое. Должны быть описаны обе сети и быть до них маршруты.

Comments

[Falseclock]

Спасибо. К сожалению я не сетевик, больше программер. С сетями на Вы.

мне главное чтобы клиенты на роутере могли видеть подсеть 172.16.0.0.24

На роутере я так понимаю iptables -A FORWARD -s 192.168.100.0/24 -d 172.16.0.0/24 -j ACCEPT
???

не помогает