LINUX.ORG.RU
решено ФорумAdmin

Настройка OpenVPN


0

1

Имеется сервер с установленным openvpn. Диапазон адресов 192.168.150.0/24

Клиенты соединяются через интернет, им присваиваются ip адреса из того же диапазона.

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

mode server
tls-server
proto tcp-server
dev tap
port 1200
daemon
tls-auth /etc/openvpn/keys/ta.key 0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
client-config-dir /etc/openvpn/ccd
ifconfig 192.168.150.1 255.255.255.0
ifconfig-pool 192.168.150.3 192.168.150.5
push "route 192.168.150.0 255.255.255.0 192.168.150.1"
duplicate-cn
verb 3
cipher DES-EDE3-CBC
persist-key
log-append /var/log/openvpn.log
persist-tun
comp-lzo

Конфиг клиента

tls-client
proto tcp-client
remote " внешний ip сервера"
dev tap
port 1200
cd /etc/openvpn
pull
tls-auth /etc/openvpn/keys/ta.key 1
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
cipher DES-EDE3-CBC
log-append /var/log/openvpn.log
comp-lzo

Интерфейсы поднимаются и на сервере и на клиенте. Только пинги между ними не идут.

Форвардинг разрешен:

cat /proc/sys/net/ipv4/ip_forward

1

route -n на сервере:

192.168.150.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0

route -n на клиенте:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.150.0   192.168.150.1   255.255.255.0   UG    0      0        0 tap0
192.168.150.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Видимо что то не так с маршрутами.


1. iptables?

2. tcpdump -eni tap0 на сервере и на клиенте?

3. Почему два маршреута на 192.168.150.0/24 на клиенте? Правильный только второй

4. Зачем tap а не tun?

Nastishka ★★★★★
()

192.168.150.1 это IP сервера? Вывод на клиенте

ip route get 192.168.150.1

А вообще вот такой маршрут работать не будет

192.168.150.0 255.255.255.0 192.168.150.1

Yur4eg ★★
()

Это убери:

push "route 192.168.150.0 255.255.255.0 192.168.150.1"
uspen ★★★★★
()
Ответ на: комментарий от Nastishka

tcpdump -eni tap0 на сервере


listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:31:57.740367 56:d9:a2:f7:aa:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 256: 192.168.150.3.138 > 192.168.150.255.138: NBT UDP PACKET(138)
15:32:04.665521 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2365, seq 1, length 64
15:32:05.673024 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2365, seq 2, length 64
15:32:06.169142 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2366, seq 1, length 64
15:32:09.661034 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype ARP (0x0806), length 42: Request who-has 192.168.150.2 tell 192.168.150.3, length 28
15:32:09.661112 c2:85:91:c4:41:c4 > 56:d9:a2:f7:aa:90, ethertype ARP (0x0806), length 42: Reply 192.168.150.2 is-at c2:85:91:c4:41:c4, length 28
15:32:11.629190 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.1: ICMP echo request, id 2368, seq 1, length 64
15:32:13.877083 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2369, seq 1, length 64
15:32:16.625518 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype ARP (0x0806), length 42: Request who-has 192.168.150.1 tell 192.168.150.3, length 28
15:32:16.625575 c2:85:91:c4:41:c4 > 56:d9:a2:f7:aa:90, ethertype ARP (0x0806), length 42: Reply 192.168.150.1 is-at c2:85:91:c4:41:c4, length 28
15:32:33.113019 56:d9:a2:f7:aa:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.150.3.137 > 192.168.150.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
15:32:34.613351 56:d9:a2:f7:aa:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.150.3.137 > 192.168.150.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

на клиенте


listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:31:57.614750 56:d9:a2:f7:aa:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 256: 192.168.150.3.138 > 192.168.150.255.138: NBT UDP PACKET(138)
15:32:04.640781 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2365, seq 1, length 64
15:32:05.649186 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2365, seq 2, length 64
15:32:06.148766 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2366, seq 1, length 64
15:32:09.639107 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype ARP (0x0806), length 42: Request who-has 192.168.150.2 tell 192.168.150.3, length 28
15:32:09.647237 c2:85:91:c4:41:c4 > 56:d9:a2:f7:aa:90, ethertype ARP (0x0806), length 42: Reply 192.168.150.2 is-at c2:85:91:c4:41:c4, length 28
15:32:11.604726 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.1: ICMP echo request, id 2368, seq 1, length 64
15:32:13.856371 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype IPv4 (0x0800), length 98: 192.168.150.3 > 192.168.150.2: ICMP echo request, id 2369, seq 1, length 64
15:32:16.603112 56:d9:a2:f7:aa:90 > c2:85:91:c4:41:c4, ethertype ARP (0x0806), length 42: Request who-has 192.168.150.1 tell 192.168.150.3, length 28
15:32:16.612180 c2:85:91:c4:41:c4 > 56:d9:a2:f7:aa:90, ethertype ARP (0x0806), length 42: Reply 192.168.150.1 is-at c2:85:91:c4:41:c4, length 28
15:32:33.091033 56:d9:a2:f7:aa:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.150.3.137 > 192.168.150.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
15:32:34.590735 56:d9:a2:f7:aa:90 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 192.168.150.3.137 > 192.168.150.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Убрал первый маршрут все так же.

А что должно быть в iptables?

DigeX
() автор топика
Ответ на: комментарий от Klubkin

ifconfig на сервере:


tap0      Link encap:Ethernet  HWaddr c2:85:91:c4:41:c4  
          inet addr:192.168.150.1  Bcast:192.168.150.255  Mask:255.255.255.0
          inet6 addr: fe80::c085:91ff:fec4:41c4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:91 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:13821 (13.4 KiB)  TX bytes:636 (636.0 B)

на клиенте:


tap0      Link encap:Ethernet  HWaddr 56:d9:a2:f7:aa:90  
          inet addr:192.168.150.3  Bcast:192.168.150.255  Mask:255.255.255.0
          inet6 addr: fe80::54d9:a2ff:fef7:aa90/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:91 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:168 (168.0 B)  TX bytes:13821 (13.4 KiB)
DigeX
() автор топика
Ответ на: комментарий от Yur4eg

этот маршрут убрал, все так же.

ip route get 192.168.150.1
192.168.150.1 dev tap0  src 192.168.150.3 
    cache  mtu 1500 advmss 1460 hoplimit 64

DigeX
() автор топика
Ответ на: комментарий от DigeX

Ну сложите сами 1+1:

1. Пакеты с клиента на сервер отправляются
2. Сервер пакеты принимает
3. ARP работает

Значит проблемы уровнем выше. Файрвол (iptables)

iptables -I FORWARD 1 -j ACCEPT -i tap0 -o tap0
iptables -I INPUT 1 -j ACCEPT -i tap0
iptables -I OUTPUT 1 -j ACCEPT -o tap0

Nastishka ★★★★★
()
Ответ на: комментарий от Nastishka

Попробовал так. Не вышло. У меня на сервере настроен nat на внутреннюю сеть. То есть подсети 192.168.150.0/24 доступ и в интернет и во внутреннюю сеть открыт. Пробовал убирать, все равно пинги не идут.

DigeX
() автор топика
Ответ на: комментарий от DigeX

Странная конфигурация, почему ты пингуешь 150.2? где он там вобще висит на сервере, почему сервер на arp отвечает.

swelf
()
Ответ на: комментарий от swelf

150.2 висит на сервере. пинговал и 150.1 разницы нет. 150.2 смотрит во внутреннюю сеть. 2 сетевушки, интернет через pptp.

ip a


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:05:5d:6a:a5:67 brd ff:ff:ff:ff:ff:ff
    inet 10.101.18.41/24 brd 10.101.18.255 scope global eth0
    inet6 fe80::205:5dff:fe6a:a567/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:50:22:8c:5b:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.2/24 brd 192.168.150.255 scope global eth1
    inet6 fe80::250:22ff:fe8c:5b8c/64 scope link 
       valid_lft forever preferred_lft forever
65: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 9.9.9.9 peer 9.9.0.9/32 scope global ppp0
66: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether c2:85:91:c4:41:c4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.1/24 brd 192.168.150.255 scope global tap0
    inet6 fe80::c085:91ff:fec4:41c4/64 scope link 
       valid_lft forever preferred_lft forever
ip внешний заменил 9.9.9.9

ip r


172.20.0.217 via 10.101.18.254 dev eth0  src 10.101.18.41 
172.20.0.206 via 10.101.18.254 dev eth0  src 10.101.18.41 
9.9.0.9 via 10.101.18.254 dev eth0 
172.20.0.226 via 10.101.18.254 dev eth0  src 10.101.18.41 
172.20.0.227 via 10.101.18.254 dev eth0  src 10.101.18.41 
9.9.0.9 dev ppp0  proto kernel  scope link  src 85.234.7.102 
9.9.0.9 via 10.101.18.254 dev eth0 
9.9.2.9/30 via 10.101.18.254 dev eth0 
192.168.150.0/24 dev eth1  proto kernel  scope link  src 192.168.150.2 
192.168.150.0/24 dev tap0  proto kernel  scope link  src 192.168.150.1 
10.101.18.0/24 dev eth0  proto kernel  scope link  src 10.101.18.41 
172.20.0.0/23 via 10.101.18.254 dev eth0 
172.21.0.0/16 via 10.101.18.254 dev eth0 
172.96.0.0/12 via 10.101.18.254 dev eth0 
10.0.0.0/8 via 10.101.18.254 dev eth0 
default dev ppp0  scope link 

DigeX
() автор топика
Ответ на: комментарий от DigeX

>192.168.150.0/24 dev eth1 proto kernel scope link src 192.168.150.2

192.168.150.0/24 dev tap0 proto kernel scope link src 192.168.150.1


потому и не работает.

Я так понимаю во внутренней сети есть клиенты из сети 150.* и ты хочешь впн посадить в эту же сеть? чтобы одноранговая была, тогда тебе надо объеденить eth1 и tap0 на сервере в мост, и вроде там немного подругому настраивают в таком случае openvpn.

Либо второй вариант, повесь на tap0 адрес 149.1, впн клиентам выдай из этой же сети, и тогда роутинг прописать на клиентах, push «route 192.168.150.0 255.255.255.0 192.168.149.1»

swelf
()
Ответ на: комментарий от swelf

Понял. В таком случае пинги до 192.168.149.1 идут.

После добавления пинги до 192.168.150.2 тоже идут route add -net 192.168.150.0 netmask 255.255.255.0 gw 192.168.149.1

Только компы внутри сети, например 192.168.150.149 не идут. Дело в iptables? Если да подскажи пожалуйста как настроить.

DigeX
() автор топика
Ответ на: комментарий от DigeX

Разобрался добавил правило

iptables -A FORWARD -s 192.168.149.0/24 -j ACCEPT

Теперь есть доступ во внутреннюю сеть. Спасибо всем.

DigeX
() автор топика

Еще вопрос. Можно ли как то увеличить скорость передачи файлов через vpn держится около 1 мб/сек при физически возможной ~2 мб/сек.

К примеру через sftp скорость 1.8 мб/сек.

Пробовал менять:

proto udp

comp-lzo отключать сжатие

результат почти одна и та же скорость.

Конфигурация железа не так плоха celeron 1200, htop показывает во время передачи ~50% загрузка cpu

DigeX
() автор топика
Ответ на: комментарий от DigeX

к примеру отключить шифрование, должно не так нагибать сервер. и собствено да, лучше оставить udp

x0r ★★★★★
()
Ответ на: комментарий от x0r

Интересно, почему у клиентов под виндой скорость подключения на интерфейсе 10 Мбит/сек. Есть какой то параметр отвечающий за скорость? Или 100 мб openvpn не поддерживает.

DigeX
() автор топика
Ответ на: комментарий от DigeX

я могу ошибаться, но openvpn поддерживает скорость, сколько выжмет сервер, т.е. винда пишет циферки, а на самом деле сколько получится

x0r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.