LINUX.ORG.RU

История изменений

Исправление no-dashi, (текущая версия) :

1. Опция «remote» у клиента - это имя/адрес сервера. Писать надо FQDN сервера

2. У клиента не задействована опция pull

3. Указыват cipher нет необходимости, клиент с сервером сами договорятся

4. На сервере лучше использовать CCD (+ подложить отдельный файл для каждого клиента). Это позволит более гибко конфигурировать клиентов, например маршрутизировать клиентские подсети при необходимости.

5. dev сделай tun.

6. client-to-client как правило не нужен.В любом случае всё пойдёт через сервер, но в случае tun без client-to-client можно в iptables на хосте управлять межклиентскими маршрутами.

7. У клиента лучше сделать ping такие же как у сервера

8. У сервера лучше прописать заранее «push route ...» на адрес локалки. И у клиента не забыть написать pull (см. пункт 2)

Во пример с моего сервера:

# cat /etc/openvpn/uvpnserver.conf
proto udp
mode server
port 1194
dev tun3

persist-tun
persist-key
persist-local-ip
persist-remote-ip

topology subnet
float

push "ping 60"
push "ping-restart 120"
keepalive 10 60

tls-server
ca /etc/openvpn/host-keys/cacert.pem
dh /etc/openvpn/host-keys/dh1024.pem
crl-verify /etc/openvpn/host-keys/crl.pem
cert /etc/openvpn/host-keys/vpn.crt
key /etc/openvpn/host-keys/vpn.key
client-config-dir /etc/openvpn/udp-client-config
ccd-exclusive

server 192.168.64.64 255.255.255.192

comp-lzo
tun-mtu 1500

И пример ccd-шки для клиента:

# cat /etc/openvpn/udp-client-config/dell 
ifconfig-push 192.168.64.66 255.255.255.192
iroute 192.168.66.2
iroute 192.19.168.101.0 255.255.255.0
В данном случае клиент это ноутбук с собственной локалкой на loopback bridge - правда, на сервере в данном случае не хватает опций
route 192.168.66.2 255.255.255.255
route 192.168.101.0 255.255.255.0
но у меня их отсутствие компенсируется кваггой с OSPF.

Исходная версия no-dashi, :

1. Опция «remote» у клиента - это имя/адрес сервера. Писать надо FQDN сервера

2. У клиента не задействована опция pull

3. Указыват cipher нет необходимости, клиент с сервером сами договорятся

4. На сервере лучше использовать CCD (+ подложить отдельный файл для каждого клиента). Это позволит более гибко конфигурировать клиентов, например маршрутизировать клиентские подсети при необходимости.

5. dev сделай tun.

6. client-to-client как правило не нужен. И вообще, либо tap, либо tun + client-to-client. В любом случае всё пойдёт через сервер, но в случае tun без client-to-client можно в iptables на хосте управлять межклиентскими маршрутами.

7. У клиента лучше сделать ping такие же как у сервера

8. У сервера лучше прописать заранее «push route ...» на адрес локалки. И у клиента не забыть написать pull (см. пункт 2)

Во пример с моего сервера:

# cat /etc/openvpn/uvpnserver.conf
proto udp
mode server
port 1194
dev tun3

persist-tun
persist-key
persist-local-ip
persist-remote-ip

topology subnet
float

push "ping 60"
push "ping-restart 120"
keepalive 10 60

tls-server
ca /etc/openvpn/host-keys/cacert.pem
dh /etc/openvpn/host-keys/dh1024.pem
crl-verify /etc/openvpn/host-keys/crl.pem
cert /etc/openvpn/host-keys/vpn.crt
key /etc/openvpn/host-keys/vpn.key
client-config-dir /etc/openvpn/udp-client-config
ccd-exclusive

server 192.168.64.64 255.255.255.192

comp-lzo
tun-mtu 1500

И пример ccd-шки для клиента:

# cat /etc/openvpn/udp-client-config/dell 
ifconfig-push 192.168.64.66 255.255.255.192
iroute 192.168.66.2
iroute 192.19.168.101.0 255.255.255.0
В данном случае клиент это ноутбук с собственной локалкой на loopback bridge - правда, на сервере в данном случае не хватает опций
route 192.168.66.2 255.255.255.255
route 192.168.101.0 255.255.255.0
но у меня их отсутствие компенсируется кваггой с OSPF.