LINUX.ORG.RU
решено Форум — Admin  

OpenVPN. Соединение двух сетей

 , ,


2

2

В целях самообразование играюсь с OpenVPN и в данном случае хочу попробовать соединить две локальные сети, т.е. чтобы каждый из хостов одной сети видел (мог пинговать) все остальные хосты.

Ситуация следующая. Есть две локальные сети 10.129.0.0/16 (состоит из двух хостов 10.129.20.80 и 10.129.18.182) и 10.135.0.0/16 (тоже состоит из двух хостов 10.135.28.233 и 10.135.32.170).

Хост 10.129.18.182 имеет постоянный внешний IP 37.139.10.10, потому здесь я запустил OpenVPN в режиме сервера:

# openvpn --ifconfig 10.8.0.1 10.8.0.2 --dev tun --secret /etc/openvpn/secret.key 0 --route 10.135.0.0 255.255.0.0 --verb 7

инструкция '--route' добавила локальный маршрут на сеть 10.135.0.0 через tun0 интерфейс.

На 10.135.28.233 я запустил OpenVPN в режиме клиента и подключаюсь к внешнему адресу сервера 10.129.18.182:

# openvpn --ifconfig 10.8.0.2 10.8.0.1 --dev tun --secret /etc/openvpn/secret.key 1 --remote 37.139.10.10 --route 10.129.0.0 255.255.0.0 --verb 7

Чтобы сервера 10.129.18.182 и 10.135.28.233 видели всю сеть я добавляю правила на них:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -P FORWARD ACCEPT
# iptables -t nat -s 10.8.0.0/24 -A POSTROUTING -o eth1 -j MASQUERADE

В конечном итоге сервера 10.129.18.182 и 10.135.28.233 видят все хосты в сетях.

Для того, чтобы 10.129.20.80 видел сеть 10.135.0.0/16 я добавляю для него новый маршрут:

# route add -net 10.135.0.0 netmask 255.255.0.0 gw 10.129.18.182

А для того, чтобы 10.135.32.170 видел сеть 10.129.0.0/16:

# route add -net 10.129.0.0 netmask 255.255.0.0 gw 10.135.28.233

И собственно проблема. Для того, чтобы 10.135.28.233 и 10.129.18.182 пересылали трафик на необходимую сеть я добавляю правило маршрутизации на 10.135.28.233:

# iptables -t nat -s 10.129.0.0/16 -A POSTROUTING -o tun0 -j MASQUERADE

А на 10.129.18.182 следующее:

# iptables -t nat -s 10.135.0.0/16 -A POSTROUTING -o tun0 -j MASQUERADE

И вот тут ничего не происходит: 10.129.20.80 так и не видит сеть 10.135.0.0/16, а 10.135.32.170 не видит сеть 10.129.0.0/16.

Похоже, что я не шарю и потому прошу о помощи.

P.S. Возможно эта картинка поможет понять то, что я хочу http://i.imgur.com/vVaiwlM.jpg

P.P.S. Для тестирования всего этого я использую хостинг Digital Ocean, если это важно.

★★★★★

Последнее исправление: ipeacocks (всего исправлений: 2)

Ответ на: комментарий от edyard

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

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

На пальцах:
route 10.135.0.0 255.255.0.0 добавит в таблицу роутинга сеть 10.135.0.0 через например tun0, но есть нюанс - клиентов у нас может быть много и вот какому из них отправлять пакет? Вот для этого и существует iroute у клиента в ccd. Т.е. когда со стороны сервера мы отправляем пакет для 10.135 от попадает на tun0 а дальше уже рулит сам ovpn какому именно клиенту отправить этот пакет.
Также и обратная ситуация, сервер отправляет push "route 10.129.0.0 255.255.0.0 клиенту что бы он знал о сети сервера.

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

Ну у меня и так был один клиент с ключем PSK.

Поменял как вы рекомендовали, конфиг сервера (10.129.18.182):

# Port and protocol
port 1194
proto udp

# Emulated network interface
dev tun

# Server's certificates/key
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret

# Diffie-Hellman key
dh dh2048.pem

# OpenVPN client's address pool
server 10.8.0.0 255.255.255.0

# Persist list of IPs and client's names
ifconfig-pool-persist ipp.txt

client-config-dir ccd

route 10.135.0.0 255.255.0.0

# With this option we can use one key/cert
# on many clients at the same time
duplicate-cn

# All traffic from clients goes to vpn interface
# push "redirect-gateway def1 bypass-dhcp"

# Push DNS-settings to client
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# Timeouts
# default 10 120
keepalive 50 200

# TLS authentication secret
tls-auth ta.key 0 # This file is secret
key-direction 0

# Minimal TLS version for connection
tls-version-min 1.2

# TLS cipheres. We are using only most secure ones.
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256

# Encryption algorithm for traffic
cipher AES-256-CBC

# HMAC auth
auth SHA256

# Traffic commpression
comp-lzo

# Redusing daemon's privileges after initialization.
user nobody
group nogroup

# Persistence of client's interface/key 
# after server restarting
persist-key
persist-tun

# Logging parameters
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
# No more than 20 the same messages
mute 20

В /etc/openvpn/ccd следующее:

# cat /etc/openvpn/ccd/client1

iroute 10.135.0.0 255.255.0.0
push "route 10.129.0.0 255.255.0.0"

Маршруты на сервере (10.129.18.182):

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         37.139.10.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        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.14.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
10.129.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth1
10.135.0.0      10.8.0.2        255.255.0.0     UG    0      0        0 tun0
37.139.10.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Конфиг клиента ovpn (10.135.28.233):

client
dev tun

proto udp
remote 37.139.10.10 1194

resolv-retry infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

tls-version-min 1.2

tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256

remote-cert-tls server

cipher AES-256-CBC
auth SHA256
# 0 is on server and 1 on client
key-direction 1

comp-lzo

verb 4
mute 20

# script-security 2
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
....
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
....
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

После старта OpenVPN маршруты на клиенте (10.135.28.233): 

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         138.68.96.1     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        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.19.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
10.129.0.0      10.8.0.5        255.255.0.0     UG    0      0        0 tun0
10.135.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth1
37.139.10.10    138.68.96.1     255.255.255.255 UGH   0      0        0 eth0
138.68.96.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0

Для сервера и клиента активированы такие правила Netfilter:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -P FORWARD ACCEPT
# iptables -t nat -s 10.8.0.0/24 -A POSTROUTING -o eth1 -j MASQUERADE

Благодаря чему клиент и сервер могут пинговать всех, но узлы с подсети клиента и узлы с подсети сервера, как и раньше, видят только свою сеть. Т.е. ничего и не поменялось.

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

Предполагаю другие правила iptables, ведь у вас белый ip и там наверняка есть что-то еще.
Посмотрите tcpdump как на клиенте так и на сервере, станет понятно.

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

Проблема вся в том, что когда я добавляю новый маршрут на 10.135.32.170 (узел из-под сети клиента):

# route add -net 10.129.0.0 netmask 255.255.0.0 gw 10.135.28.233

И пингую примером 10.129.20.80 (узел из подсети сервера):

# ping 10.129.20.80

И потом смотрю tcpdump-ом на 10.135.28.233 на предмет icmp-пакетов:

# tcpdump -i eth1 -n -nn -ttt 'ip proto \icmp'

То ничего и нет. Т.е. оно выходит, что и пакеты через 10.135.28.233 не проходят. Не понимаю в чем проблема.

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

Ну вот такое:

# tcpdump -i eth1 -n -nn -ttt 'ip proto \icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
00:00:00.000000 IP 10.135.32.170 > 10.129.20.80: ICMP echo request, id 14778, seq 12, length 64
00:00:00.999789 IP 10.135.32.170 > 10.129.20.80: ICMP echo request, id 14778, seq 13, length 64
00:00:01.000004 IP 10.135.32.170 > 10.129.20.80: ICMP echo request, id 14778, seq 14, length 64
00:00:01.000956 IP 10.135.32.170 > 10.129.20.80: ICMP echo request, id 14778, seq 15, length 64
00:00:00.999865 IP 10.135.32.170 > 10.129.20.80: ICMP echo request, id 14778, seq 19, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
ipeacocks ★★★★★
() автор топика
Последнее исправление: ipeacocks (всего исправлений: 1)
Ответ на: комментарий от anc

Это 10.135.32.170:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         138.68.96.1     0.0.0.0         UG    0      0        0 eth0
10.19.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
10.129.0.0      10.135.28.233   255.255.0.0     UG    0      0        0 eth1
10.135.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth1
138.68.96.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0
ipeacocks ★★★★★
() автор топика
Последнее исправление: ipeacocks (всего исправлений: 1)
Ответ на: комментарий от ipeacocks

Запутался с сетями. (на всякий случай удалил комент)
Чуть проще: если с 10.135.32.170 пинг отправить на 10.135.28.233 он доходит?
Далее с 10.135.32.170 пинг отправить на 10.129.20.80 то на 10.135.28.233 виден? Если да, то с какого интерфейса потом улетает? Или вообще не улетает?

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

Чуть проще: если с 10.135.32.170 пинг отправить на 10.135.28.233 он доходит?

Да, все отлично.

Далее с 10.135.32.170 пинг отправить на 10.129.20.80 то на 10.135.28.233 виден?

Нет, пинги не идут. И более того, на 10.135.28.233 tcpdump ничего не видит. Проверял на 10.135.28.233 следующей командой:

# tcpdump -i eth1 -n -nn -ttt 'ip proto \icmp'

Т.е. похоже, что роут почему-то неверно добавлен. Но почему?

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

Нет, пинги не идут. И более того, на 10.135.28.233 tcpdump ничего не видит. Проверял на 10.135.28.233 следующей командой:

Я правильно понял что при пинге с 10.135.32.170 icmp уходит, но до 10.135.28.233 не доходит?
А на роутере 138.68.96.1 (надеюсь не ошибся) не к нему ли прилетает? Не понятно почему но все-таки.
ЗЫ И еще посмотрите ip r s table all вдруг что-то из таблиц есть

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

Я правильно понял что при пинге с 10.135.32.170 icmp уходит, но до 10.135.28.233 не доходит?

Нет. Внутри каждой из локальных сетей пакеты ходят нормально. Впн-клиент и сервер (10.135.28.233 и 10.129.18.182 соответсвенно) тоже видят все хосты.А на роутере

138.68.96.1 (надеюсь не ошибся) не к нему ли прилетает?

Суть в том, что роутер на стороне хостера и я проверить это не могу. Но опять, же исходя из правил роутинга

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         138.68.96.1     0.0.0.0         UG    0      0        0 eth0
10.19.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
10.129.0.0      10.135.28.233   255.255.0.0     UG    0      0        0 eth1
10.135.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth1
138.68.96.0     0.0.0.0         255.255.240.0   U     0      0        0 eth0

Оно таки должно всё идти на 10.135.28.233.

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

Да все ведь чисто.

# iptables -L -n -v
Chain INPUT (policy ACCEPT 299 packets, 25665 bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Chain OUTPUT (policy ACCEPT 478 packets, 61124 bytes)
 pkts bytes target     prot opt in     out     source               destination         

# iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 18 packets, 1010 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 18 packets, 1010 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1 packets, 84 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1 packets, 84 bytes)
 pkts bytes target     prot opt in     out     source               destination
ipeacocks ★★★★★
() автор топика
Ответ на: комментарий от anc

ЗЫ И еще посмотрите ip r s table all вдруг что-то из таблиц есть

Да вроде в порядке всё:

# ip r s table all
default via 138.68.96.1 dev eth0 onlink 
10.19.0.0/16 dev eth0  proto kernel  scope link  src 10.19.0.6 
10.129.0.0/16 via 10.135.28.233 dev eth1 
10.135.0.0/16 dev eth1  proto kernel  scope link  src 10.135.32.170 
138.68.96.0/20 dev eth0  proto kernel  scope link  src 138.68.107.174 
broadcast 10.19.0.0 dev eth0  table local  proto kernel  scope link  src 10.19.0.6 
local 10.19.0.6 dev eth0  table local  proto kernel  scope host  src 10.19.0.6 
broadcast 10.19.255.255 dev eth0  table local  proto kernel  scope link  src 10.19.0.6 
broadcast 10.135.0.0 dev eth1  table local  proto kernel  scope link  src 10.135.32.170 
local 10.135.32.170 dev eth1  table local  proto kernel  scope host  src 10.135.32.170 
broadcast 10.135.255.255 dev eth1  table local  proto kernel  scope link  src 10.135.32.170 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 138.68.96.0 dev eth0  table local  proto kernel  scope link  src 138.68.107.174 
local 138.68.107.174 dev eth0  table local  proto kernel  scope host  src 138.68.107.174 
broadcast 138.68.111.255 dev eth0  table local  proto kernel  scope link  src 138.68.107.174 
fe80::/64 dev eth0  proto kernel  metric 256  pref medium
fe80::/64 dev eth1  proto kernel  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 pref medium
local ::1 dev lo  table local  proto none  metric 0  pref medium
local fe80::8f3:a6ff:feb3:f591 dev lo  table local  proto none  metric 0  pref medium
local fe80::38f0:1bff:fe84:6552 dev lo  table local  proto none  metric 0  pref medium
ff00::/8 dev eth0  table local  metric 256  pref medium
ff00::/8 dev eth1  table local  metric 256  pref medium
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101 pref medium
ipeacocks ★★★★★
() автор топика
Ответ на: комментарий от ipeacocks

Перечитал сначала, уж простите за слепоту. У вас это на хостинге а не реальная сеть. Тут возможны нюансы. Что-то в чем-то? В смысле виртуалка в виртуалке или как сделано?

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

Перечитал сначала, уж простите за слепоту.

Да ничего. Куча цифр, я думал это читать вообще никто не будет.)

У вас это на хостинге а не реальная сеть.

Да, это хостинг DigitalOcean https://www.digitalocean.com/. Для этих тестов я создал 2 виртуалки в Амстердаме (10.129.18.182 и 10.129.20.80) и 2 в Франкфурте (10.135.28.233 и 10.135.32.170). Тут есть опция приватной сети http://i.imgur.com/TWPi6SD.png, т.е. то что в одной локации превращается в одну локалку.

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

Ничего подобного не пользовал. Уж сорри. Так что скорее предполагаю дропы на уровне ДО. Могу быть конечно не прав. Но вроде по всему что было представлено выше вами, прям уж явных косяков не вижу.

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

Тут вопрос не в блокируется, а в создании вирт сети. Неа, не подскажу. В том плане мне оно не надо, у меня реальные сети объединены.
Вы написали в «целях самообразования», на современной технике это протестировать можно на локалхосте с виртуалками. ovpn достаточно прост, так что даже на реальных задачах несложно поднять, а уж мануалов по нему просто море. Вы правильно подошли к вопросу с минимализации. Так что не думаю, что у вас с таким подходом возникнут вопросы даже на реальной задаче.

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

И еще в вашем случае можно замаскарадить адрес с клиента, тоже наверное заработает. Клиента это который 170

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)

Тебе по-моему не tun нужен, а tap, если ещё не сказали.

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

Там проблема была из-за странностей в работе локальной сети Digitalocean. Когда я ставил гейтвеем для одной ноды, другую ноду этой же сети, то пакеты почему-то терялись. Я попробовал тоже самое в локальной сети, которая была создана посредством Virtualbox - и все у меня получилось.

Автор, пробуй с «dev tap», ибо есть существенная разница между ним и «dev tun».

c tap опенвпн жаловался на невозможность добавления роутов.

ipeacocks ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin