OpenVPN и Asus RT-AC51U

rze

но на расшаренные папки клиентов не заходит. Что и куда добавить? )

Вы по ип обратитесь к шаре. Типа Пуск-> Выполнить -> \xxx.xxx.xxx.xxx

да, так и делал

из доп.офиса заходит на сенс и по 10.7.7.1 и по 192.168.1.1 Пк в сети не пингует, хотя на вебморды серверов сети лезет.
А из главного офиса 192.168.2.* не пингует и не доступен

pigbrother

подскажите, из главного офиса (192.168.1.) не видно сеть доп. офиса(192.168.2.).

1. iroute для 192.168.2.0/24 в client specific overrides указан?
2. На pfSense правило вида

IPv4 * LAN net * 192.168.2.0/24 * * none

создано?

rze

@pigbrother:

подскажите, из главного офиса (192.168.1.) не видно сеть доп. офиса(192.168.2.).

1. iroute для 192.168.2.0/24 в client specific overrides указан?
2. На pfSense правило вида

IPv4 * LAN net * 192.168.2.0/24 * * none

создано?

Прописал и то и то, результата нет

где то, что то я не так делаю…

pigbrother

Проверяйте настройки.
Asus и pfSense при поднятом туннеле должны иметь маршруты в сети друг друга.
На pfSense маршруты смотреть тут:
Diagnostics: Routing tables

Возможно в Asus маршрут нужно добавить вручную.

rze

@pigbrother:

Проверяйте настройки.
Asus и pfSense при поднятом туннеле должны иметь маршруты в сети друг друга.
На pfSense маршруты смотреть тут:
Diagnostics: Routing tables

да да, как раз мониторю таблицу маршрутизации.
маршрута к 192.168.2.* там нет, и я не знаю куда и что прописать

rze

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

1 - таблица сервера http://i.imgur.com/c4N3kTk.png
2 - таблица клиента http://i.imgur.com/RLQydVB.png

p.s. добился путем добавления route 192.168.2.0 255.255.255.0; push "route 192.168.1.0 255.255.255.0" в Advanced на сервере. Client Specific Override пуст.

Что еще сделать мне?

rze

Все сделал, все получилось

Итоговый вариант в конфиге сервера

route 192.168.2.0 255.255.255.0; push "route 192.168.1.0 255.255.255.0"; push "route 192.168.2.0 255.255.255.0"

в Client Specific Override

iroute 192.168.2.0 255.255.255.0

Спасибо за помощь :)

werter

Рекомендую в настр. сервера в Адвансед добавить :

sndbuf 100000;
rcvbuf 100000;
push "sndbuf 100000";
push "rcvbuf 100000";

rze

@werter:

Рекомендую в настр. сервера в Адвансед добавить :

sndbuf 100000;
rcvbuf 100000;
push "sndbuf 100000";
push "rcvbuf 100000";

Спасибо, добавил

rze

Апну темку
Сменили провайдера и на сервере и на клиенте, перестал подключаться впн. ( и с роутера, и с пк через клиент)
Конфиги не менялись (исключая ip). При этом с телефона и домашнего компа, другого провайдера, подключается.
На роутере в логах спамится строчка```
Aug 9 12:04:36 openvpn-cli[697]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

В клиенте лог```
Fri Aug 05 08:35:08 2016 OpenVPN 2.3.11 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Fri Aug 05 08:35:08 2016 Windows version 6.1 (Windows 7) 64bit
Fri Aug 05 08:35:08 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.09
Fri Aug 05 08:35:09 2016 Control Channel Authentication: using 'бла-бла-бла-tls.key' as a OpenVPN static key file
Fri Aug 05 08:35:09 2016 UDPv4 link local (bound): [undef]
Fri Aug 05 08:35:09 2016 UDPv4 link remote: [AF_INET]Айпи:Порт
Fri Aug 05 08:36:09 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Aug 05 08:36:09 2016 TLS Error: TLS handshake failed
Fri Aug 05 08:36:09 2016 SIGUSR1[soft,tls-error] received, process restarting
Fri Aug 05 08:36:11 2016 UDPv4 link local (bound): [undef]
Fri Aug 05 08:36:11 2016 UDPv4 link remote: [AF_INET]Айпи:Порт

pigbrother

TLS key negotiation failed to occur within 60 seconds

Наиболее общая ошибка, говорящая о невозможности начать соединение (о недоступности IP или порта OVPN-сервера).

https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html

Убедитесь, что OVPN-сервер привязан к правильному интерфейсу, что для этого интерфейса и порта создано на WAN правило, что провайдер действительно дает "белый" IP и не блокирует нужный порт.

Проверить, к примеру можно так - перевести сервер в TCP (UDP так не протестировать) и проверить снаружи этот IP:порт телнетом или nmap, этим, например, сервисом
http://hideme.ru/ports/
Указав свой порт.

werter

Сменили провайдера и на сервере

1. У вас теперь серый ип на WAN
2. Провайдер блокирует порты.

rze

@pigbrother:

Убедитесь, что OVPN-сервер привязан к правильному интерфейсу, что для этого интерфейса и порта создано на WAN правило, что провайдер действительно дает "белый" IP и не блокирует нужный порт.

Проверить, к примеру можно так - перевести сервер в TCP (UDP так не протестировать) и проверить снаружи этот IP:порт телнетом или nmap, этим, например, сервисом
http://hideme.ru/ports/
Указав свой порт.

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

PORT      STATE SERVICE
****/tcp open  unknown
Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

Перевел в tcp сервер, лог клиента```
Tue Aug 09 16:12:52 2016 OpenVPN 2.3.11 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Tue Aug 09 16:12:52 2016 Windows version 6.1 (Windows 7) 32bit
Tue Aug 09 16:12:52 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09
Tue Aug 09 16:12:52 2016 Control Channel Authentication: using 'блабла-tls.key' as a OpenVPN static key file
Tue Aug 09 16:12:52 2016 Attempting to establish TCP connection with [AF_INET]Ип:порт [nonblock]
Tue Aug 09 16:13:02 2016 TCP: connect to [AF_INET]Ип:порт failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)
Tue Aug 09 16:13:17 2016 TCP: connect to [AF_INET]Ип:порт failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)
Tue Aug 09 16:13:32 2016 TCP: connect to [AF_INET]Ип:порт failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)
Tue Aug 09 16:13:47 2016 TCP: connect to [AF_INET]Ип:порт failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

а роутер так же строчку

NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

pigbrother

NOTE: the current –script-security setting may allow this configuration to call user-defined scripts

Это на поднятие туннеля не влияет.

Конфиг на WIN7 верный? Запускаете клиента от администратора?

rze

Лог с телефона, все подключается и работает
http://i.imgur.com/vWCFfdo.png

@werter:

Сменили провайдера и на сервере

1. У вас теперь серый ип на WAN
2. Провайдер блокирует порты.

На сервере белый статичный
эм, как то тогда частично блокируют, "своих" не пускают, а чужие пожалуйста.

Я так понимаю затык у провайдера, вопросы к ним? ))
Сделал отдельным сообщением, вдруг пропустили

Конфиг на WIN7 верный? Запускаете клиента от администратора?

Верный, нет, завтра от админа запущу, как то даже выпало из головы.

pigbrother

Заодно для теста отключите на WIN7 брандмауэр и тп Касперских, убедитесь также, что запущена служба DHCP-клиент.

rze

@pigbrother:

Заодно для теста отключите на WIN7 брандмауэр и тп Касперских, убедитесь также, что запущена служба DHCP-клиент.

Попробовал, на двух компах из той сети. Логи те же. Но и изначально думал, что не поможет, ибо что же тогда мешало подключиться к роутеру? Думаю надо обращаться к провайдеру.
P.S. попробовал сменить порт. история та же

rze

Апну темку мб кому пригодится
Сегодня дошли руки посидел поковырялся. Все оказалось просто. Достаточно было мне было заглянуть в лог фаервола и увидеть там что клиент долбится не с внешнего адреса, а с адреса вида 10.205.. отключил Block private networks and loopback addresses и Block bogon networks в настройках WAN и все заработало ))

werter

2 rze
Доброе.
Рекомендую для вашего роутера эту прошивку - https://bitbucket.org/padavan/rt-n56u/downloads
Стабильнее , свежее, больше возможностей - https://bitbucket.org/padavan/rt-n56u/wiki/browse/RU

pigbrother

Сегодня дошли руки посидел поковырялся. Все оказалось просто. Достаточно было мне было заглянуть в лог фаервола и увидеть там что клиент долбится не с внешнего адреса, а с адреса вида 10.205..

Спишем это на особенности работы конкретного провайдера.
Обычно серые адреса не видны на WAN-интерфейсе, предположу, что и OVPN-сервер pf и проблемный клиент обслуживаются одним провайдером.