Помогите пожалуйста разобраться с маршрутизацией (openvpn)

ip_forward

Клиентский компьютер имеет адрес в локальной сети 192.168.0.65. По идее, с сервера должн проходить ping 192.168.0.65, но не проходит

с сервера клиент даже по локалке не пингуется, я правильно понял?

192.168.0.0/24 via 192.168.11.2 dev tun0

может из-за этого?

ip_forward

Как со стороны сервера, так и клиента:

cat /proc/sys/net/ipv4/ip_forward
1

с сервера клиент даже по локалке не пингуется, я правильно понял?

Клиентский vpn ip (192.168.11.2) со стороны сервера пингуется нормально. Как и со стороны клиента в сторону сервера.

Не пингуется ip клиента в его локальной сети (192.168.0.65)

так потому что у тебя правило все пакеты клиентской сети заворачивать в ВиПиЭнную

так потому что у тебя правило все пакеты клиентской сети заворачивать в ВиПиЭнную

Вы не правильно поняли.

192.168.0.0/24 via 192.168.11.2 dev tun0

Этот маршрут на стороне сервера

Ну тогда тупняк, да. Либо fw режет либо вообще какой андроид либо совокупно, т.к. пакеты очевидно доставляются куда надо.

UPD. Еще и в обратную сторону, клиент может не знать куда отвечать. т.е. 0/0 у 0.65 может быть 0.1, а не 11.2

Вот я делаю пинг 192.168.0.65, пакет попадает в ядро, оно смотрит попадает ли он под какое-нибудь правило из таблицы маршрутов, он попадает под правило 192.168.0.0/24 – ядро и шлет его в интерфейс tun0

Вот я делаю пинг 192.168.0.65, пакет попадает в ядро, оно смотрит попадает ли он под какое-нибудь правило из таблицы маршрутов, он попадает под правило 192.168.0.0/24 – ядро и шлет его в интерфейс tun0

Так и должно быть. На стороне сервера

Я запускал tcpdump на стороне клиента:

tcpdump -i tun0 src 192.168.11.1
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
16:33:24.306246 IP 192.168.11.1 > c65: ICMP echo request, id 40689, seq 1, length 64
16:33:25.342006 IP 192.168.11.1 > c65: ICMP echo request, id 40689, seq 2, length 64

Т.е. пинги на IP VPN клиента идут нормально. Ответы так же.

Но если, со стороны сервера: ping 192.168.0.65, то tcpdump (на стороне клиента ни чего не видит)

Ну тогда тупняк, да. Либо fw режет либо вообще какой андроид либо совокупно, т.к. пакеты очевидно доставляются куда надо.

На сервере Debian 10. iptables пустой. Все разрешено.

На стороне клиента Fedora 37. Так же все разрешено.

UPD. Еще и в обратную сторону, клиент может не знать куда отвечать. т.е. 0/0 у 0.65 может быть 0.1, а не 11.2

Пока наплевать знает ли клиент куда отвечать. Нужно хотя бы увидеть, на стороне клиента, что пакеты приходят.

Я вижу что: какая-то засада на маршруте сервера.

Так и должно быть. Со стороны сервера

Да с чего бы? В VPN-ную сеть надо отправлять пакеты, попадающие под маску VPN-нной сети, а пакеты попадающие под маску физической сети – в физический интерфейс – будет тебе пинг с сервера до клиента по реальному адресу

Смотри как у меня:

$ ip route
default via 10.0.0.1 dev eth0 onlink 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.102 
10.8.3.0/24 via 10.8.3.21 dev tun0 
10.8.3.21 dev tun0 proto kernel scope link src 10.8.3.22 

10.0.0.0/24 – физическая

10.8.3.0/24 – виртуальная

И все пингуется и все работает

Да с чего бы? В VPN-ную сеть надо отправлять пакеты, попадающие под маску VPN-нной сети, а пакеты попадающие под маску физической сети – в физический интерфейс – будет тебе пинг с сервера до клиента по реальному адресу

Это как?

Клиент и сервер видят VPN сеть 192.168.11.0/24. Сервер может увидеть локальную сеть клиента ТОЛЬКО через клиентский компьютер VPN IP 192.168.11.2

Следовательно: все пакеты со стороны сервера на адреса 192.168.0.0/24 должны заворачиваться в tun0 и идти через 192.168.11.2

Это tcpdump запущен на стороне сервера, с сервера же пытаюсь пинговать клиентский комп по его адресу в локальной сети (192.168.0.65)

tcpdump -i tun0 dst 192.168.0.65
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
17:13:58.414614 IP 192.168.11.1 > 192.168.0.65: ICMP echo request, id 39499, seq 1, length 64
17:13:59.442069 IP 192.168.11.1 > 192.168.0.65: ICMP echo request, id 39499, seq 2, length 64

Т.е. пакеты в сеть 192.168.0.0/24 сервер заворачивает в tun0 и даже куда-то отправляет. Вот только клиент ни хрена не видит.

Сервер может увидеть локальную сеть клиента ТОЛЬКО через клиентский компьютер

а, я, видимо, неправильно понял топологию: я почему-то решил что клиент с сервером в одной локалке

ты хочешь чтоб с сервера была видна локалка клиента – тогда маскарадинг

маскардинг может и понадобится, но пока нужно хотя бы со стороны сервера достучаться до клиента по его IP из локальной сети. Т.е. ping 192.168.0.65

Вообще, лютый бред!

Скорее всего, в моей голове.

Отчаявшись решил сделать глупость: взял и прописал маршрут на одном из компьютеров (Windows 2008 R2) (10.1.1.2) локальной сети сервера:

route add 192.168.0.0 mask 255.255.255.0 192.168.11.2

И…

Нет пинги с этого Windows 2008 R2 на 192.168.0.65 пошли на половину :)

Ответ он не получает. Но VPN клиент видит посылаемые ему пакеты с 10.1.1.2

Это что за хрень такая?

Почему VPN сервер не может так же???

маскардинг может и понадобится, но пока нужно хотя бы со стороны сервера достучаться до клиента по его IP из локальной сети

без НАТа не достучишся: пакеты на стороне клиента будут дропаться

Вот у меня схожая задача на домашнем роутере решается: это рабочие локалки делаются доступными из моей домашней через VPN:

iptables -t nat -A POSTROUTING -d 192.168.0.0/16 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 172.0.0.0/8    -j MASQUERADE

В общем разобрался.

В конфиге сервера openVPN для доступа к локальной сети за клиентом (192.168.0.0/24) нужно добавить строку:

route 192.168.0.0 255.255.255.0

Теперь пакеты доходят от сервера до внутреннего (не VPN) IP клиента (192.168.0.65)

ping 192.168.0.65
PING 192.168.0.65 (192.168.0.65) 56(84) bytes of data.
64 bytes from 192.168.0.65: icmp_seq=1 ttl=64 time=46.6 ms
64 bytes from 192.168.0.65: icmp_seq=2 ttl=64 time=45.6 ms

Но на другие адреса ходить отказываются. Нужно настроить нат на клиенте:

iptables -t nat -A PREROUTING -i tun0 -j DNAT --to-destination 192.168.0.65

Можно и через MASQUERADE, но PREROUTING дает меньшую нагрузку.

Разумеется, в случае, если в iptables FORWARD не ACCEPT, нужно настроить форвардинг.

PS Подскажите, плз, как пометить тему как решенную?

Под самим постом (который наверху) для тебя будет видна ссылка [Отметить тему как решенную] – жми!

В конфиге сервера openVPN для доступа к локальной сети за клиентом (192.168.0.0/24) нужно добавить строку:

Не все решение я написал выше.

Этого мало.

Нужно посмотреть в конфиге сервера строку: client-config-dir

Допустим она имеет вид:

client-config-dir /etc/openvpn/ccd

Тогда:

echo 'iroute 192.168.0.0 255.255.255.0' > /etc/openvpn/ccd/client_name

где client_name - имя на которое генерировались сертификаты