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

Что в iptables ?

«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 такой-то, роуты такие-то.

На 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

Что такое client2 это шлюз по умолчанию в сети 10.20.4.0/24?

Да.

посмотрите что говорит tcpdump на $LAN_IFACE у клиента2, пакеты с него улетают?

Так, посмотрел 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

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

1. Да 2. Опечатка, там 10.20.3.10

По первому пункту, посмотрите тем же tcpdump на 10.20.4.4 к нему пакеты вообще прилетают?

Да, есть пакеты с 10.20.3.10.

А ответов нет? Тогда смотрите fw на клиенте в смысле 10.20.4.4.

Угу, нет ответов. А таблицы пустые на 10.20.4.4.

Чудес не бывает. покажите с него:
ip r
ip a
iptables-save
и выхлоп tcpdump например при пинге с 10.20.3.10

# 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?

Т.е. хотите сказать, что 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»

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

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

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

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

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

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

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

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

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

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

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

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

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

1. «10.20.0.0/4 » - надеюсь там было «10.20.0.0/16 »
2. Но они пингуються при этом с клиента1?

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

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

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

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

Да, нужен доступ с 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.

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

Не уверен, но всё может быть.

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

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

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

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

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

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

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

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

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

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

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

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

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

Благодарю за объяснение!

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

В качестве роутера будет выступать 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.
Надеюсь мысль ясна.

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