OpenVPN - маршрутизация

Если сеть за сервером openvpn твоя и допускает произвольные ip-адреса, то никакого маскарадинга и, скорее всего, вообще iptables, не надо. Ну если на сервере forward режется, то нужно открыть.

А так в общем случае только на openvpn-сервере нужна строка

push "route 192.168.21.0 255.255.255.0"

(это, если я правильно понял, что 192.168.21.0 — та сеть за сервером).

Конфиг сервера:

local 192.168.21.30
port 1194
proto udp
dev tun0
tun-mtu 1500
ca /etc/openvpn/.key/ca.crt
cert /etc/openvpn/.key/server.crt
key /etc/openvpn/.key/server.key
dh /etc/openvpn/.key/dh2048.pem
server 10.10.25.0 255.255.255.0
daemon
mode server
tls-server
ifconfig-pool-persist /etc/openvpn/ip.sv
client-to-client
push "route 192.168.21.0 255.255.255.0"
client-config-dir ccd
keepalive 10 120
tls-auth /etc/openvpn/.tls/ta.key 0
cipher AES-256-CBC
auth SHA512
comp-lzo
max-clients 20
user openvpn
group openvpn
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 5
mute 20

Форвардинг включен? В цепочке FORWARD клиентская сеть выпущена во внутреннюю?

cat /proc/sys/net/ipv4/ip_forward

IPTABLES

# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Wed Dec 25 01:13:27 2013
*filter
:INPUT ACCEPT [55:5690]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [38:4890]
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Wed Dec 25 01:13:27 2013
# Generated by iptables-save v1.4.7 on Wed Dec 25 01:13:27 2013
*nat
:PREROUTING ACCEPT [33:9624]
:POSTROUTING ACCEPT [6:942]
:OUTPUT ACCEPT [6:942]
-A POSTROUTING -s 10.10.25.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Wed Dec 25 01:13:27 2013

Форвардинг включен? В цепочке FORWARD клиентская сеть выпущена во внутреннюю?

как проверить?

А на компьютерах, которые в подсети 192.168.21.0, сетевой интерфейс только один, который смотрит в эту подсеть?

И ещё посмотри, на клиенте маршрут прописался? Покажи сюда вывод route (на венде route print).

Маскарадинг, кстати, необязателен. Можно просто на основном маршрутизаторе прописать роут на 10.10.25.0 через внутренний интерфейс впн-сервера, а в iptables на последнем вкорячить iptables -I FORWARD -s 10.10.25.0/24 -d 192.168.21.0/24 -j ACCEPT, например.
Так оно и смотреться прозрачнее будет.
Ну и да, прописались ли роуты на клиентском компе? Запросто может не хватить прав, если венда.

Скорее всего где-то режется.

Ну дак определите где режется. Запускайте при влюченном на клиенте ping'е tcpdump на серверер на разных интерфейсах на перехват icmp пакетов и смотрите уходит ли icmp-echo запрос и приходт ли ответ.

Если win7. И выше, то запускать openvpn надо либо как службу, либо из контекстного меню «запустить от имени администратора». Ну и как выше писали - не забудь forward, если не заработает, то tcpdump осваивай )))

Маскарадинг, кстати, необязателен. Можно просто на основном маршрутизаторе прописать роут на 10.10.25.0 через внутренний интерфейс впн-сервера, а в iptables на последнем вкорячить iptables -I FORWARD -s 10.10.25.0/24 -d 192.168.21.0/24 -j ACCEPT, например. Так оно и смотреться прозрачнее будет. Ну и да, прописались ли роуты на клиентском компе? Запросто может не хватить прав, если венда.

При использовании маскарадинга в файле /etc/sysconfig/iptables:

:OUTPUT ACCEPT [6:942]
#-A POSTROUTING -s 10.10.25.0/24 -o eth0 -j MASQUERADE

Отключив вышеуказанный маскарадинг и использовав правила FORWARDING:

iptables -I FORWARD -s 10.10.25.0/24 -d 192.168.21.0/24 -j ACCEPT

Пинги перестают проходит до машин за сервером: Вот tcpdump:

# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
01:01:31.353176 IP 10.10.25.25 > 192.168.21.31: ICMP echo request, id 4059, seq 1214, length 64
01:01:32.361437 IP 10.10.25.25 > 192.168.21.31: ICMP echo request, id 4059, seq 1215, length 64
01:01:33.369475 IP 10.10.25.25 > 192.168.21.31: ICMP echo request, id 4059, seq 1216, length 64
01:01:34.377341 IP 10.10.25.25 > 192.168.21.31: ICMP echo request, id 4059, seq 1217, length 64

Что надо сделать для того чтобы можно было достучаться до машин за VPN сервером используя правило FORWARD?

А машины знают, куда ответ слать? Т.е., до сети 10.10.25.0 у клиентов в сети 192.168.21.0 (причём, у каждого клиента) должен быть прописан маршрут через твой сервер с поднятой службой VPN.

А машины знают, куда ответ слать? Т.е., до сети 10.10.25.0 у клиентов в сети 192.168.21.0 (причём, у каждого клиента) должен быть прописан маршрут через твой сервер с поднятой службой VPN.

мне не нужно чтобы машины за ВПН имели доступ к клиентам. Мне нужно чтобы только клиенты имели доступ к машинам за ВПН сервером.

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

А закрыть инициацию соединения от одной из сторон можно тем же айпитейблсом через фильтрацию TCP-флагов.

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

А закрыть инициацию соединения от одной из сторон можно тем же айпитейблсом через фильтрацию TCP-флагов.

Подскажите как это все настроить. Если есть возможность то распишите команды.

ВПН сервер: CentOS 6.5 Машины за ВПН сервером: CentOS 6.5 Клиент: Ubuntu 12.04/Windows 7

Заранее благодарен

Положим А — впн-клиент. Б — впн-сервер. В — комп в локалке.

А подключился к Б и получил адрес 10.10.25.25. На Б настроен форвардинг (я так понял, ты знаешь, как его настроить).

Тебе нужен доступ с А к В или с В к А?

Положим А — впн-клиент. Б — впн-сервер. В — комп в локалке.

А подключился к Б и получил адрес 10.10.25.25. На Б настроен форвардинг (я так понял, ты знаешь, как его настроить).

Тебе нужен доступ с А к В или с В к А?

мне нужен с A к B

На Б настроен форвардинг (я так понял, ты знаешь, как его настроить).

Здесь имеется ввиду использовать правило? :

iptables -I FORWARD -s 10.10.25.0/24 -d 192.168.21.0/24 -j ACCEPT

Для доступа А→В нужно три условия:
1. Указанное правило в iptables
2. Маршрут на В, получаемый клиентами (А) openvpn
3. Маршрут на основном внутреннем (В) роутере, указывающий, что сеть А маршрутизируется через OpenVPN-сервер (В → Б → А).

Является ли Б шлюзом по умолчанию для В?

Является ли Б шлюзом по умолчанию для В?

нет не является

1. Указанное правило в iptables 2. Маршрут на В, получаемый клиентами (А) openvpn

это у меня как я понимаю есть.

3. Маршрут на основном внутреннем (В) роутере, указывающий, что сеть А маршрутизируется через OpenVPN-сервер (В → Б → А).

этого у меня видать нет. У меня для В используется шлюз Роутера: TP-LINK TL-WR1043N

Как я понял мне надо на роутере добавить статичный маршрут для сети А

Тогда просьба — нарисуй сеть.

Вот сеть:

Remote User 10.10.25.57 --> VPN (10.10.25.0) --> tun0 OpenVPN Server 10.10.25.1 (LAN eth0 192.168.21.0) --> VPN (10.77.0.0) --> tun1 OpenVPN Server 10.77.0.1 (LAN eth0 10.77.77.0)

Здесь два VPN сервера. Remote User подключается к одному серверу, который в свою очередь постоянно подключен к другому VPN серверу.

Необходимо чтобы Remote User мог достукиваться до сети 10.77.77.0/24 не используя маскарадинг. Хотелось бы использовать правило форвардинга, но пока что безупешно.

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