Нужно около NAS'а смотреть пакеты tcpdump'ом. Либо вместо NAS поставить сервер с Linux и там запустить tcpdump, либо между кинетиком и NAS'ом поставить управялемый свич с зеркалированием порта.

он и получает свой локальный ip адрес

По dhcp от кинетика или это про адрес, получаемы NAS'ом от openvpn-сервера?

спасибо за ответ

nas к кинетику в локалке без проблем , там ip постоянный

это про адрес, получаемы NAS’ом от openvpn-сервера?

nas без проблем получает локальный адрес в ovpn сервере , я вижу их и в логах на сервере , да и nas врать не будет. И пакеты даже ходят, допустим если я до nas попытась с мобилы достучаться по общему с ним ovpn. тут чтото банальное простое (( наверняка кинетик не пускает трафф . может это правило на сервере ovpn мешает?!

iptables -A INPUT -p icmp –icmp-type echo-request -j REJECT

я так прячусь что у меня ovpn стоит

повторюсь - стоит мне отключить ovpn на кинетике, nas сразу доступен по своему ovpn

Тут надо чуть больше золота, как минимум в виде логов ovpn как с nas так и кинетик. Но лучше конфиги двух серверов и двух клиентов.

Но вебморда не открывается (( в чем может быть проблема ?

Многие nas не дают доступ к морде не из своей локаки.

здравствуйте уважаемый ANC вы мне как то очень помогли

вот конфиг сервера который отвечает за доступ с кинетика

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.9.0.0 255.255.255.0
push "dhcp-option DNS 91.142.136.100"
push "dhcp-option DNS 91.142.137.100"
push "dhcp-option DNS 75.88.8.8"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 1.1.1.1"
keepalive 10 120
ncp-disable
cipher BF-CBC
client-to-client
client-config-dir /etc/openvpn/client
user nobody
group nogroup
persist-key
persist-tun
duplicate-cn
status openvpn-status.log
verb 3
crl-verify crl.pem

конфиг его же клиента «роутер»

fconfig-push 10.9.0.6 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
push "dhcp-option DNS 288.120.247.2"
client-config-dir /etc/openvpn/client
keepalive 10 120
ncp-disable
cipher BF-CBC
client-to-client
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

ifconfig-push 10.8.0.2 255.255.255.0

Уточню, если поднят только на nas на какой ip вы с другого клиента сервера nas обращаетесь к вэбу nas ?

обращаюсь на этот 10.8.0.2 и все работает в локалке через 192.168.1.70 , точно такжже все работает

Многие nas не дают доступ к морде не из своей локаки.

тут дело не только в самой вебморде , там в докере есть некоторый сервис тоже по веб. но доступ и туда и туда по одному ип адресу , только разные порты

обращаюсь на этот 10.8.0.2 и все работает в локалке через 192.168.1.70 , точно такжже все работает

Уточним локалка где nas 192.168.1.0/24 ip nas 192.168.1.70

тут дело не только в самой вебморде , там в докере есть некоторый сервис тоже по веб. но доступ и туда и туда по одному ип адресу , только разные порты

Ну вот, начинается, теперь еще есть и где-то докер. давайте описывайте все, а не по частям.


PS Упс ступил, тунель в тунеле, классическое же, возможно понизить mtu or mssfix прописать на клиентах.

Уточним локалка где nas 192.168.1.0/24 ip nas 192.168.1.70 да , все верно Ну вот, начинается, теперь еще есть и где-то докер. давайте описывайте все, а не по частям.

хорошо , давайте докер не причем , просто доступ к nas

Упс ступил, тунель в тунеле, классическое же, возможно понизить mtu or mssfix прописать.

а вот тут по подробнее плиз , эти данные мне ни о чем не говорят. и где их прописать ?

хорошо , давайте докер не причем , просто доступ к nas

Ходим по кругу, начнем с nas.

а вот тут по подробнее плиз , эти данные мне ни о чем не говорят. и где их прописать ?

В конфиге клиента параметр mtu. Можно прописать mtu-test и через минут пять соединения в логе увидите что предложили.

Ходим по кругу, начнем с nas.

докер тут непричем , считайте что его нет, я его привел в пример, чтобы было понятно ,что дело не в самой веб морде NAS

В конфиге клиента параметр mtu

вот конфиг , а какой поставить ?

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 191.67.222.123 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher BF-CBC
#setenv opt block-outside-dns
key-direction 1
verb 3

Можно прописать mtu-test и через минут пять соединения в логе увидите что предложили

понял , сейчас попробую

опцию mtu-test в конфиге клиента подключил , но вот логи получить не удается((( Сначала думал проблема в правах на папку , но даже в папке /tmp логи не создаются.

status openvpn-status.log
verb 3
log-append /tmp/openvpn.log

а файл лога status openvpn-status.log спокойно создается и живет в папке /etc/openvpn/

я что подумал , может им нельзя на одинковом порту сидеть ? раз один в другом живет ?! я про 1194 ? може стделать разными ?

Пальцем в небо, если это последняя строка то перевод строки поставьте

У вас же кинетик и нас клиенты, так что порт тут не причем.

думаю шлюзВПН тут совсем не причем , сейчас на винду что за кинетиком на котором поднят ВПН, поставил второй ВПН , и спокойно шарюсь по инету… видимо дело в портах вебморды nas. по тому как если я из локалки на него стучуть , он мне сразу ее открывает на 5001 порту

поставил второй ВПН , и спокойно шарюсь по инету…

Так у вас в конфиге второго сервера redirect-gateway нэма, только сеть ovpn 10.8.0.0/24, вы уж поясните полностью как это он по инету шариться?

Так у вас в конфиге второго сервера redirect-gateway нэма

а redirect-gateway в клиентском конфиге проставлен

Новые данные )) Описанная мной задачка полностью решается - все пингуется и открывается , если я роутеру даю клиентские ключи того же сервера , что и в NASe ну естественно сами ключи разные. Так что настройки роуетра здесь не причем. В принципе и так жить можно, но надо както найти причину ((

Вот сейчас все не понял. Давайте хоть схемку, а то много меняем и нам не понятно.

сейчас набросаю , спасибо , что помогаете разобраться

схема вот примерно так , но в любом случае , 10.8.0.5 пингуется из вне при любых раскладах. НО полноценно открывается если только я отключу из цепи впн 10.9.0.0

Сервер ovpn 10.8.0.0 согласно схемы тоже находиться в локалке вместе с nas и кинетиком 192.168.1.0/24 ? Или я ошибся ?

Может я не точно нарисовал , но все сервара находятся отдельно, это же VPSки. Когда vpn трафик 10.8.0.0 идет напрямую через роутер ( без транзита через 10.9.0.0) клиент 10.8.0.5 доступен для юзеров 10.8.0.Х . Но стоит пустить трафик для 10.8.0.5 транзитом через 10.9.0.0, доходят только ping 10.8.0.5 а по факту он недоступен. схема

Описанная мной задачка полностью решается - все пингуется и открывается , если я на роутере поднимаю ВПН клиента для серфа не 10. 9.0.Х а тот же 10.8.0.Х, но с другим ip. я попадаю на NAS -клиент 10.8.0.5 без проблем

поставил OVPN на другой сервер вместо 10.9.0.0. все заработало без доп настроек , как разберусь почему напишу обязательно. Спасибо большое ANC что помогаете разбираться

продолжаю наблюдение )

итак я поставил дефолтный 10.8.0.0 и NAS стал виден , но простых путей мы не ищем и я решил вновь сменить подсеть на 10.9.0.0 сменил в конфиге, в iptables, в общем все завелось . инет через шлюз ходит , но вот волшебство перестал откликаться NAS !! как такое может быть? ведь их подсети никак не пересекаются это же независимые туннели ?! ?! совершенно разные сервера наконец !? вот привожу кусочек лога

Wed Apr  8 21:52:26 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Apr  8 21:52:26 2020 TUN/TAP device tun1 opened
Wed Apr  8 21:52:26 2020 TUN/TAP TX queue length set to 100
Wed Apr  8 21:52:26 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Apr  8 21:52:26 2020 /sbin/ip link set dev tun1 up mtu 1500
Wed Apr  8 21:52:26 2020 /sbin/ip addr add dev tun1 10.9.0.1/24 broadcast 10.9.0.255
Wed Apr  8 21:52:26 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET
Wed Apr  8 21:52:26 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Apr  8 21:52:26 2020 TCP/UDP: Socket bind failed on local address [AF_INET]198.67.232.123:1194: Address already in use
Wed Apr  8 21:52:26 2020 Exiting due to fatal error
Wed Apr  8 21:52:26 2020 Closing TUN/TAP interface
Wed Apr  8 21:52:26 2020 /sbin/ip addr del dev tun1 10.9.0.1/24

ip addr :

root@ih1629050:/etc/openvpn/server# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    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 group default qlen 1000
    link/ether 52:12:00:ae:d8:83 brd ff:ff:ff:ff:ff:ff
    inet 198.67.232.123/20 brd 198.67.233.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe90::5012:rf:feae:d853/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.9.0.1/24 brd 10.9.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe90::f16e:62bf:82tf:5f1b/64 scope link flags 800
       valid_lft forever preferred_lft forever

Wed Apr 8 21:52:26 2020 TCP/UDP: Socket bind failed on local address [AF_INET]198.67.232.123:1194: Address already in use
Address already in use

Вам перевести?

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

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

хорошо , начнем с простого . Вопрос. как запустить (пересзапустить) ovpn?! Предвижу ответы :

systemctl restart –now openvpn-server@server.service

systemctl restart openvpn

service openvpn restart

/etc/init.d/openvpn restart

все это не перезапускает конфиг файл с ноовыми директивами. помогает только полный ребут сервера

killall openvpn
openvpn --config /path-to-config/configname

killall openvpn

-bash: kill: openvpn: arguments must be process or job IDs

попробвал найти процесс и убить через него

pidof openvpn

killall «ID opevpn»

/etc/init.d/openvpn stop

таким образом получилось остановить но запустить потом без ребута не получилось

а не стартует заново вот почему :

Options error: --dh fails with 'dh.pem': No such file or directory
Options error: --ca fails with 'ca.crt': No such file or directory
Options error: --cert fails with 'server.crt': No such file or directory
Thu Apr  9 23:18:38 2020 WARNING: cannot stat file 'server.key': No such file or directory (errno=2)
Options error: --key fails with 'server.key': No such file or directory
Options error: --crl-verify fails with 'crl.pem': No such file or directory
Thu Apr  9 23:18:38 2020 WARNING: cannot stat file 'tc.key': No such file or directory (errno=2)
Options error: --tls-crypt fails with 'tc.key': No such file or directory
Options error: Please correct these errors.
Use --help for more information.

1. Хм, а на сервере какая ОС?

2. C

--dh fails with 'dh.pem': No such file or directory

и т.д., виноват не обратил внимание, я по привычке пишу полные пути в конфиге, но это не обязательно. Запускайте из директории где ключи/конфиг лежат или можно указать в отдельном параметре openvpn --cd /path-to-config --config /path-to-config/configname

Запускайте из директории где ключи/конфиг лежат или можно указать в отдельном параметре openvpn –cd /path-to-config –config /path-to-config/configname

1. у меня debian9
2. делаю так - предварительно убиваю процесс как описал выше , далее выполняю команду выше, все запускается , логи корректные , даже есть дата и время вначале строк( смотрю их в scp). НО при выполнении этой команды терминал подвисает , и если его закрыть процесс умирает и все соединения разваливаются

У меня также есть deb9 с ovpn. Вот кроме того, что как писал выше, в конфигах(поддерживаю и tcp и udp) прописаны полные пути к ключам не вижу проблем.
Только что протестировал. Все робит. Не понятно почему у вас на deb9 выдало

-bash: kill: openvpn: arguments must be process or job IDs

Сдается мне копипаста была кривой. Руками наберите.
Мой реальный пример на текущий момент

root@debian9:~# killall openvpn
root@debian9:~# uname -a
Linux debian9 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64 GNU/Linux
root@debian9:~# openvpn --config /etc/openvpn/server-udp.conf

смотрю их в scp

С этого места и поподробнее, у вас что терминала нет?

Забыл указать что /etc/openvpn/server-udp.conf это симлинк на /etc/openvpn/server/openvpn-udp.conf

Linux ih1629050 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Apr 10 12:10:03 2020 from 213.87.158.142
root@ih1629050:~# killall openvpn
-bash: killall: command not found
root@ih1629050:~# killall openvpn
-bash: killall: command not found
root 

нет код не кривой я и руками писал и так и сяк .

С этого места и поподробнее, у вас что терминала нет?

терминал конечно есть просто терминал для команд , а scp для просмотра и копирования файлов , там удобнее

Забыл указать что /etc/openvpn/server-udp.conf это симлинк на /etc/openvpn/server/openvpn-udp.conf

я это понял .

Мне кажется вы все-таки не договариваете
Ваши посты

killall openvpn
-bash: kill: openvpn: arguments must be process or job IDs

и

root@ih1629050:~# killall openvpn
-bash: killall: command not found

ну реально не сходятся.
Похоже что вы приводите «на угад» выхлопы с разных серверов/устройств.

смысл недоговаривать , время свое тратить и ваше, зачем ?

Using username "root".
root@89.46.241.69's password:
Linux telegramm 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Apr  7 12:22:19 2020 from 213.87.158.142
root@telegramm:~# killall openvpn
-bash: killall: command not found
root@telegramm:~# kill openvpn
-bash: kill: openvpn: arguments must be process or job IDs
root@telegramm:~#

Ну да ладно, просто ребутнуть сервер не страшно. Тем более это единожды , при настройке. Ещё хотел у вас спросить ,есть ли преимущества в ipv6 перед ip4?! Настроил ipv6, все штатно работает , но надо ли ?! Ещё и не известно пока заведется ли на win7 у клиента (версия ip4 работает) . Что посоветуете?

killall идет в psmisc Но собстно его наличие не обязательно можно и kill использовать, можно инит скриптами опустить. Смысл только в том что бы опустить ovpn и запустить вручную.

есть ли преимущества в ipv6 перед ip4

Зависит от того чего достигнуть хотим. Например клиентам белый адрес отдать. Но насколько клиентам это надо решать вам.

сегодня наконец закончилась эпопея с поиском перезагрузки , самое обидное , я его указывал здесь же (( но видимо ччтото упустил из вида очень надеюсь комуто пригодится

systemctl restart openvpn-server@server.service

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

systemctl restart openvpn-server@server.service

В данном случае вы указываете конкретный сервис. А серверов может быть больше одного. Собственно как и клиентов.
Один из личных примеров на deb9
openvpn@server-udp.service
openvpn@server-tcp.service
openvpn-client@CLIENTNAME.service
Фактически как конфиг назовете так и будет называться. Так что вы привели частный случай используемый у вас, но это не значит что у всех будет так же.

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

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

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