LINUX.ORG.RU
ФорумAdmin

Объединение локалок через OpenVPN

 , ,


0

1
client 1 <----> OpenVPN server <----> client 2
10.20.3.10      10.20.3.0/24          10.20.3.6
    |                                     |
    v                                     v
192.168.2.0/24                      10.20.4.0/24 <---> 10.20.0.0/24

Как мог нарисовал структуру сети.

client2 на внутреннем интерфейсе имеет адрес из 10.20.4.0/24, но ему доступна подсеть 10.20.0.0/24.

Цель: client1 должен видеть подсети 10.20.4.0/24 и 10.20.0.0/24.

Настройки сервера

push "route 10.20.0.0 255.255.0.0"
push "route 192.168.2.0 255.255.255.0"

route 10.20.0.0 255.255.255.0
route 10.20.4.0 255.255.255.0
route 192.168.2.0 255.255.255.0

ccd/client1

iroute 192.168.2.0 255.255.255.0

ccd/client2

iroute 10.20.0.0 255.255.255.0
iroute 10.20.4.0 255.255.255.0

С такими настройками client1 из подсети 10.20.4.0/24 видит только client2, всё остальное недоступно, маршрут прерывается на 10.20.3.6.

Чую, что что-то не так с маршрутами на client2, но разобраться не могу. Может, кто с подобным сталкивался?

★★★★★

«push „route 10.20.0.0 255.255.0.0“ не самая лучшая идея, хотя работать должно из-за того что сети с большей маской, но всетаки что мешало для openvpn сети взять например 10.21.0.0/24 ?
Что такое client2 это шлюз по умолчанию в сети 10.20.4.0/24 ? Если нет тот как минимум клиенты сети 10.20.4.0/24 должны знать что пакеты для 192.168.2.0/24 слать на него.
Лучше чуть по подробнее нарисуйте структуру второго клиента, типа интерфейс такой-то ip такой-то, роуты такие-то.

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

На client1 нет ничего, на client2 два правила:

-A FORWARD -p all -i $LAN_IFACE -o $VPN_IFACE -j ACCEPT
-A FORWARD -p all -o $LAN_IFACE -i $VPN_IFACE -j ACCEPT
vvn_black ★★★★★
() автор топика
Ответ на: комментарий от anc

Так, посмотрел tcpdump на client2, делаю с client1 traceroute 10.20.4.4 или пробую по ssh коннект, пакеты идут в одну сторону:

IP 10.20.3.10.43356 > 10.20.4.4.33452: UDP, length 32
IP 10.20.3.10.56606 > 10.20.4.4.ssh

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

1. Что такое 10.20.4.4 ? Какой-то клиент в локалке 10.20.4.0/24?
2. 10.20.3.34 - это же согласно схеме не client1

anc ★★★★★
()
Ответ на: комментарий от anc
# ip r
default via 10.20.4.1 dev eth0 
10.20.0.0/16 dev eth0  proto kernel  scope link  src 10.20.4.4 

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 32:33:37:66:32:39 brd ff:ff:ff:ff:ff:ff
    inet 10.20.4.4/16 brd 10.20.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::3033:37ff:fe66:3239/64 scope link 
       valid_lft forever preferred_lft forever

15:31:17.141592 IP 10.20.3.10 > 10.20.4.4: ICMP echo request, id 15645, seq 99, length 64
15:31:18.141479 IP 10.20.3.10 > 10.20.4.4: ICMP echo request, id 15645, seq 100, length 64

Т.е. хотите сказать, что 10.20.4.4 не знает маршрута до 10.20.3.10?

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

Т.е. хотите сказать, что 10.20.4.4 не знает маршрута до 10.20.3.10?

Да, не знает, и не может получить mac для адреса 10.20.3.10. Смотрите внимательней tcpdump там arp запросы без ответа будут. Да и arp -an тоже, понятно будет.
10.20.0.0/16 dev eth0 proto kernel scope link src 10.20.4.4
Вернемся к моему первому ответу «но всетаки что мешало для openvpn сети взять например 10.21.0.0/24»

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

PS btw а вот из 192.168.2.0/24 все должно работать нормально.

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

Вернемся к моему первому ответу «но всетаки что мешало для openvpn сети взять например 10.21.0.0/24»

Я думаю, 90% ответов на такой вопрос, так было задолго до того, как возникла задача ))

И да, вы абсолютно правы, везде arp-запросы без ответа, я их не увидел потому что перестарался с фильтром вывода tcpdump. Как и то, что 192.168.2.0/24 доступна с 10.20.4.4.

Смена подсети openvpn решит проблему?

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

Смена подсети openvpn решит проблему?

В варианте который мы обсуждаем - да.
Но будут и еще подводные камни которые я уже вижу :) Хотя возможно вас они не коснуться. :)

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

Но будут и еще подводные камни которые я уже вижу :)

Спасибо большое за помощь. Попробовал сменить подсеть vpn, вся 10.20.4.0/24 стала доступна клиенту 1. ))

А можно что-то сделать чтобы client1 видел 10.20.0.0/24? Для меня сложность в том, что могу только пинговать машины этой сети, изнутри посмотреть не смогу.

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

А можно что-то сделать чтобы client1 видел 10.20.0.0/24? Для меня сложность в том, что могу только пинговать машины этой сети, изнутри посмотреть не смогу.

Не распарсил. Поясните «изнутри посмотреть не смогу.» что это значит?

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

У меня нет доступа ни к одной из машин подсети 10.20.0.0/4 ни физически ни по ssh. Могу только пинговать пару адресов. Сейчас пинги до них не проходят.

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

Успел набрать до исправления. :)

Могу только пинговать пару адресов. Сейчас пинги до них не проходят.

Вангую. Винда?

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

Блин, у меня уже похоже перегрев, пропускаю цифры...

Да, нужен доступ с client1 не только к 10.20.4.0/24, а и как минимум к 10.20.0.0/24, может и ко всему диапазону 10.20.0.0/16.

В том то и дело, что с client1 не пингуется ничего, кроме 10.20.4.0/24, да и тот только после смены подсети vpn.

К 10.20.0.0/16 есть доступ с client2.

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

Измените везде на 10.20.0.0/16 (я по сервер ovpn).

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

У винды fw по умолчанию запрещает доступы от не локальных сетей. Так же этим может заниматься антивирь на ней.

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

У винды fw по умолчанию запрещает доступы от не локальных сетей. Так же этим может заниматься антивирь на ней.

Особо не помогла смена маски в настройках vpn.

Т.е. то что проходит с 10.20.4.0/24 вполе себе может лочиться с 10.21.3.10?

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

Давайте начнем сначала. У вас все-таки сетка /16 как мы увидели выше. Почему вы настойчиво пишите про /24 ?

Т.е. то что проходит с 10.20.4.0/24 вполе себе может лочиться с 10.21.3.10?

Оно не приходит с 10.20.4.0/24, оно приходит с 10.20.0.0/16 что является локальной сетью.

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

Почему вы настойчиво пишите про /24 ?

Потому что цель, которой пытаюсь достичь, чтобы были доступны пара машин из 10.20.4.0/24 и пара из 10.20.0.0/24, и да согласен, логично, я наверное излишне упростил для себя и вас запутал. Там все-таки 10.20.0.0/16.

Спрошу иначе, то что нет ответа когда пингуем с хостов вне 10.20.0.0/16 - это вполне предсказуемо, если там винда с настройками по умолчанию или антивирь, я правильно понял?

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

Спрошу иначе, то что нет ответа когда пингуем с хостов вне 10.20.0.0/16 - это вполне предсказуемо, если там винда с настройками по умолчанию или антивирь, я правильно понял?

Да. Именно так и есть. Т.е. вам не будет «счастья» при объединении двух разных вин компов из разных сетей если не внесете изменения на них самих. Но есть еще костыльный вариант в виде NAT. Тогда работать будет без перестройки всяких gpo и т.п. Но минус в том что все обращения будут от ip роутера.

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

В качестве роутера будет выступать client2?

Нет. Вы же хотите что бы из/в сетей 10.20.0.0/16 192.168.2.0/24 10.21.3.0/24 народ ходил. так что прийдется везде делать.
Вот прилетает вам пакет от 10.20.4.4 к 192.168.2.123 надо будет замаскарадить его 192.168.2.1? или наоборот от 192.168.2.123 к 10.20.4.4 замаскарадить 10.20.4.1.
Надеюсь мысль ясна.

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

Но честно говоря, правильнее вин компы починить через всякие gpo что бы они пускали трафик. А то это все костыле строение получается.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.