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

OpenVPN и проблема с маршрутизацией между сетями


0

0 

Сначала попробую нарисовать структуру сети:

   -------                                     -------
  |       | 10.10.106.6    VPN    10.10.106.5 |       |
  |*client|-----------------------------------|*server|
  |       |                                   |       |
   -------                                     -------
      | 173.1.6.1                                 |173.1.5.247
      |                                           |
      | 173.1.6.2                                 |173.1.5.1
   -------                                     -------
  |       |                                   |       |
  |       |                                   |       |
  |       |                                   |       |
   -------                                     -------

Нужно сделать так, чтобы компы из сети 173.1.6.0/24 могли видеть сеть 173.1.5.0/24 и наоборот, естественно.

Что имею на данный момент:
впн работает (конфиги будут ниже);
с компьютера *client сеть 173.1.5 пингуется нормально, а вот например пропинговать такой коммандой уже не получается: 
ping -I 173.1.6.1 173.1.5.1

===================   Настройки сервера   ===========================
Конфиг openvpn на *server:
port 1196
proto udp
dev tun
ca extusersvpn/ca.crt
cert extusersvpn/extusersvpn.crt
key extusersvpn/extusersvpn.key
dh extusersvpn/dh1024.pem
auth-user-pass-verify ./extusersvpn-auth.py via-env
server 10.10.106.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 173.1.5.0 255.255.255.0"
client-config-dir ccd
route 10.10.106.0 255.255.255.252
route 173.1.6.0 255.255.255.0
client-to-client   #на всякий случай включил, хоть и не надо
keepalive 10 120
comp-lzo
user ovpnuser
group ovpngroup
persist-key
persist-tun
status openvpn-status.log
verb 3

cat /etc/openvpn/ccd/client
route 173.1.6.0 255.255.255.0

/sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.106.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.10.106.0     10.10.106.2     255.255.255.252 UG    0      0        0 tun0
real-network    0.0.0.0         255.255.255.248 U     0      0        0 eth0
173.1.5.0       0.0.0.0         255.255.255.0   U     0      0        0 br0
173.1.6.0       10.10.106.2     255.255.255.0   UG    0      0        0 tun0
10.10.106.0     10.10.106.2     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         gateway-ip      0.0.0.0         UG    0      0        0 eth0

iptables -vnL
Chain INPUT (policy DROP 81 packets, 25783 bytes)
 pkts bytes target     prot opt in     out     source               destination
 6729  398K ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
 154M  105G bad_tcp_packets  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 148M  104G ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
5572K  659M INTIF      0    --  br0    *       0.0.0.0/0            0.0.0.0/0
 144K   15M EXTIF      0    --  eth0   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  tap0   *       0.0.0.0/0            0.0.0.0/0
   14  4008 ACCEPT     0    --  tun0   *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 56M packets, 30G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 163M packets, 129G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain EXTIF (1 references)
 pkts bytes target     prot opt in     out     source               destination
50055 2953K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
  103  7927 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194
   88  3696 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1196
53373 3637K ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8

Chain INTIF (1 references)
 pkts bytes target     prot opt in     out     source               destination
5572K  659M ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain bad_tcp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination

С сервера 10.10.106.6 пингуется, а 173.1.6.1 - нет.

===================   Настройки клиента   ===========================
Конфиг openvpn на *client (фактически стандартный конфиг):
client
dev tun
proto udp
remote my-openvpn-server-ip 1196
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
auth-user-pass passwd
comp-lzo
verb 3

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
client-ip       0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.10.106.5     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
173.1.5.0       10.10.106.5     255.255.255.0   UG    0      0        0 tun0
173.1.6.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.10.106.0     10.10.106.5     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 ppp0

ping 173.1.5.1
PING 173.1.5.1 (173.1.5.1) 56(84) bytes of data.
64 bytes from 173.1.5.1: icmp_seq=1 ttl=62 time=126 ms
64 bytes from 173.1.5.1: icmp_seq=2 ttl=62 time=111 ms
64 bytes from 173.1.5.1: icmp_seq=3 ttl=62 time=66.5 ms
--- 173.1.5.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 66.584/101.737/126.994/25.638 ms

ping -I 173.1.6.1 173.1.5.1
как я уже говорил не проходит

traceroute и tracepath:
[root@omicron:/etc]$ traceroute 173.1.5.1
traceroute to 173.1.5.1 (173.1.5.1), 30 hops max, 40 byte packets
 1  10.10.106.1 (10.10.106.1)  152.162 ms  199.129 ms  200.120 ms
 2  173.1.5.1 (173.1.5.1)  246.107 ms  247.101 ms  289.089 ms
[root@omicron:/etc]$ tracepath 173.1.5.1
 1:  10.10.106.6 (10.10.106.6)                              0.081ms pmtu 1500
 1:  10.10.106.1 (10.10.106.1)                            181.010ms
 1:  10.10.106.1 (10.10.106.1)                            166.009ms
 2:  173.1.5.1 (173.1.5.1)                                154.017ms reached
     Resume: pmtu 1500 hops 2 back 62

traceroute -s 173.1.6.1 173.1.5.1
traceroute to 173.1.5.1 (173.1.5.1), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
...

На файерволе все открыто:
 iptables -vnL
Chain INPUT (policy ACCEPT 22168 packets, 2928K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 19693 packets, 5470K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 19467 packets, 2506K bytes)
 pkts bytes target     prot opt in     out     source               destination


Пока решил вопрос тем, что в файере прописал правило:
iptables -t nat -A POSTROUTING -s 173.1.6.0/24 -o tun0 -j MASQUERADE
Но все же очень нужно, чтобы сетки видели друг друга.

Прошу всемогущий all помочь мне в сим вопросе.
Если нужна еще какая-то информация, скажите.
← Два канала в Интернет и распределение нагрузки
бесперебойная работа двух серверов →

Ээээ, батенька, конфиги даже не стал читать. Видимо, у вас элементарно не настроен роутинг. Я бы посоветовал срубить файрволл на время экспериментов для упрощения задачи. Возможно, машины из 173.1.5.0/24 не знают о 173.1.6.0/24. Смотрите tcpdump на сервере vpn и на пингуемой тачке.

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

>Видимо, у вас элементарно не настроен роутинг. Я бы посоветовал срубить файрволл на время экспериментов для упрощения задачи. Возможно, машины из 173.1.5.0/24 не знают о 173.1.6.0/24.

знают они всё. тем более что пингую с *client'а и *server'а с помощью ping -I, а на этих машинах роутинг настроен, можете посмотреть выводы route выше.

>Смотрите tcpdump на сервере vpn и на пингуемой тачке.

Собственно этим щас и занимаюсь, но пока безрезультатно.

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

запускаю на *client'е  ping -I 173.1.6.1 10.10.106.1
в это время tcpdump показывает следующее:
на *client:
tcpdump -i tun0 icmp
00:02:29.771010 IP 173.1.6.1 > 10.10.106.1: ICMP echo request, id 13630, seq 1, length 64
00:02:30.775673 IP 173.1.6.1 > 10.10.106.1: ICMP echo request, id 13630, seq 2, length 64
00:02:31.775673 IP 173.1.6.1 > 10.10.106.1: ICMP echo request, id 13630, seq 3, length 64
00:02:32.775683 IP 173.1.6.1 > 10.10.106.1: ICMP echo request, id 13630, seq 4, length 64

на *server'е тишина

на *client'е в выводе route -n есть следующие строки:
10.10.106.5     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
173.1.5.0       10.10.106.5     255.255.255.0   UG    0      0        0 tun0
10.10.106.0     10.10.106.5     255.255.255.0   UG    0      0        0 tun0

ведь кажеться должно же работать

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

посмотрел ща пример. Если не ошибаюсь, сказать push "route blah-blah-blah" - всё=, что подсунуть ему файл конфигурации как:

client-config-dir /etc/openvpn/configs

в нём:

iroute 192.168.0.0 255.255.248.0#это сетка, которая находится _за клиентом_.

У тебя же написано push "route <сетка за сервером>"

markevichus ★★★
() 

>push "route 173.1.5.0 255.255.255.0"
>client-config-dir ccd
>route 10.10.106.0 255.255.255.252
>route 173.1.6.0 255.255.255.0

какая-то тут мешанина совсем с роутингом. Вот пример конфига сервера, кот. косается только маршрутов.

server 192.168.127.0 255.255.255.0
client-config-dir /etc/openvpn/configs# здесь iroute ты уже видел
route 192.168.0.0       255.255.248.0#это сеть клиента

На клиенте:
remote <реальный ip сервера>

Всё, больше ничего не нужно.

markevichus ★★★
()

УРРАААА! Заработало.

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

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

Буду надеяться, что до утра не сломается =)

anti_social ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Два канала в Интернет и распределение нагрузки
Admin
бесперебойная работа двух серверов →