http://i019.radikal.ru/1103/df/704d3a0a2a9c.png
На рисунке выше - схематично то что есть.
Вопросы:
1) можно ли сделать так что бы виртуалка на сервере и клиенты openvpn видели друг-друга (все порты и прочее без NAT)
2) являются ли venet интерфейсы виртуалки полноценными интерфейсами? заметил что у них нету мак-адресов.

На данный момент развешиваю нужные порты на 10.0.0.1 и делаю через него NAT на адреса 192.168.0.0 но это не удобно (много портов на разных виртуалках). Как сделать это всё прозрачнее (что бы для клиентов VPN виртуалки были доступны как "хосты")?

• openVPN и openVZ,shadow_alone, 04:58 , 23-Мрт-11
  • openVPN и openVZ,md0, 11:57 , 23-Мрт-11
• openVPN и openVZ,sHaggY_caT, 12:24 , 23-Мрт-11
  • openVPN и openVZ,md0, 15:36 , 23-Мрт-11
    • openVPN и openVZ,md0, 15:54 , 23-Мрт-11
    • openVPN и openVZ,md0, 16:24 , 23-Мрт-11

А зачем NAT то делать?

маршруты правильно пропишите на клиентах и на хостах и пусть сеть 10.0.0.0/24 видит сеть 192.168.0.0/24 и наоборот.
Делов то.

> А зачем NAT то делать?
> маршруты правильно пропишите на клиентах и на хостах и пусть сеть 10.0.0.0/24
> видит сеть 192.168.0.0/24 и наоборот.
> Делов то.

а правильно - как?
vpn соединение, как я понимаю, это p-t-p соединение.
Ethernet adapter openvpn:
   IPv4 Address. . . . . . . . . . . : 10.0.0.6
   Subnet Mask . . . . . . . . . . . : 255.255.255.252
   Default Gateway . . . . . . . . . :

А на сервере:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.0.1  P-t-P:10.0.0.2  Mask:255.255.255.255

Я тут теряюсь куда и чего роутить :(

>[оверквотинг удален]
> На рисунке выше - схематично то что есть.
> Вопросы:
> 1) можно ли сделать так что бы виртуалка на сервере и клиенты
> openvpn видели друг-друга (все порты и прочее без NAT)
> 2) являются ли venet интерфейсы виртуалки полноценными интерфейсами? заметил что у них
> нету мак-адресов.
> На данный момент развешиваю нужные порты на 10.0.0.1 и делаю через него
> NAT на адреса 192.168.0.0 но это не удобно (много портов на
> разных виртуалках). Как сделать это всё прозрачнее (что бы для клиентов
> VPN виртуалки были доступны как "хосты")?

У нас несколько VPN-серверов в OpenVZ-контейнерах(кстати, тоже посоветовала бы не держать сервис не в контейнере,из соображений security и правильной нарезки ресурсов, не стоит никакой софт ставить на ноду).

Ключевые моменты:

1) у контейнера должны быть права доступа к сетевому стеку, и нужен tun/tap-девайс, дырка в /dev/, для доступа к tun/tup драйверу

Вот что должно быть в конфиге контейнера:

DEVICES="c:10:200:rw "
CAPABILITY="NET_ADMIN:on "

Либо ставьте через vzctl(8)

На контейнер нужно пробросить (IPtables DNAT) порт OpenVPN

2) клиенты через NAT работают превосходно, если у сервера публичный IP, или проброшен порт, как обычно у нас.

3) пример конфига сервера:
dev tun
proto udp
keepalive 10 120
comp-lzo
log /var/log/openvpn.log
status /var/log/openvpn/openvpn-status.log
verb 3

link-mtu <индивидуально>
mssfix  <индивидуально>
fragment <индивидуально>

server <VPN NETWORK> 255.255.0.0
up /usr/sbin/rc.route_add_wrapper.sh
#Конфигурационная директория для клиентов
client-config-dir /etc/openvpn/ccd

tls-server

port <port>

tls-auth /etc/openvpn/keys/ta.key 0
#ifconfig-pool-persist /etc/openvpn/ipp.txt
dh /etc/openvpn/keys/dh1024.pem

ca /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/<host>.crt
key /etc/openvpn/keys/<host>.key

Пример клиента(UNIX, под виндой аналогично):

dev tun
proto udp
keepalive 10 120
comp-lzo
log /var/log/openvpn.log
status /var/log/openvpn/openvpn-status.log
verb 3                                                                                                    
#link-mtu      
<индивидуально>                                                                          

link-mtu <индивидуально>                                                                                            

mssfix <индивидуально>                                                                          
fragment <индивидуально>                                                                          

resolv-retry infinite
nobind
client
tls-client
tls-auth /etc/openvpn/keys/ta.key 1
remote <host> <port>

ca /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/<host>.crt
key /etc/openvpn/keys/<host>.key

4) добавляем роуты на сервере скриптом:

cat /usr/sbin/rc.route_add_wrapper.sh
#!/bin/bash

/usr/sbin/rc.route_add.sh start <VPN NETWORK> 255.255.0.0
sleep 2
/etc/init.d/firewall restart

5) для каждого клиента так же добавляем роуты, но в конфиге на сервере, например:

cat /etc/openvpn/ccd/<host>
#Прописываем клиентские подсети на сервере

iroute

#Прописываем подсети для клиента

push "route <NET1> 255.255.255.0"
push "route <NET2> 255.255.255.0"
push "route <NET3> 255.255.255.0"

#Прописываем роут на OpenVPN сеть
push "route <VPN NET> 255.255.0.0"

#Передаем удаленным сетям маршруты в нашу
push "dhcp-option DNS <LAN DNS>"
#работает только в оффтопике

сделал чуть извращённо.
можно ли дать доступ клиентам openvpn сети так что бы они видел друг-друга?
поднял в контейнере openvpn клиента. подключился.
клиент имеет 10.0.0.6
контейнер - 10.0.0.42
сервер - 10.0.0.1
как сделать так что бы траффик между клиентом и контейнером гонялся без преград?
я правильно понимаю что openvpn поднимает p-t-p соединение и клиент и контейнер совсем не в одной сети (как кажется из похожести IP адресов)?

>[оверквотинг удален]
> можно ли дать доступ клиентам openvpn сети так что бы они видел
> друг-друга?
> поднял в контейнере openvpn клиента. подключился.
> клиент имеет 10.0.0.6
> контейнер - 10.0.0.42
> сервер - 10.0.0.1
> как сделать так что бы траффик между клиентом и контейнером гонялся без
> преград?
> я правильно понимаю что openvpn поднимает p-t-p соединение и клиент и контейнер
> совсем не в одной сети (как кажется из похожести IP адресов)?

ЗЫ. Если я с клиента пингую 10.0.0.1 то всё пингуется.
а если с сервера пингую 10.0.0.6 - то нет. в чём проблема?

не сочтите за спам :)

добавил в конфиг сервера client-to-client опцию.
теперь клиент (10.0.0.6) пингует контейнер (10.0.0.42) а вот в обратную сторону пинг не идёт :(
контейнер на debian.