"То ли я дурак, то ли лыжи не едут". В общем дело оказалось не в лыжах. Попытка установить OpenVPN на телефон помогла разобраться в чём проблема - неправильно указано имя TLS-ключа.
Ziptar, другой, стараюсь порты и ip-адреса не светить в сети. Порты в настройках совпадают, это точно. В показанных тут настройках ip tables забыл поменять )
Перед сервером роутера нет, он сам является шлюзом, интернет в него напрямую приходит.
Ziptar, прикол в том, что на сервере в логах вообще нет ничего в момент подключения, то есть до него соединение не доходит вообще. Порт на сервере открыт, проверял. На клиенте проброс на роутере сделал этого порта и отключил брандмауэр - всё равно не работает.
Логи с более высокой детализацией не вставить, ругается на превышение количества символов.
# Try to preserve some state across restarts.
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
cert user.crt
key user.key
ns-cert-type server
tls-auth ta.key 1
auth SHA512
tls-version-min 1.2
;cipher x
cipher AES-128-CBC
comp-lzo
verb 5
log /var/log/openvpn.log
# Silence repeating messages
;mute 20
Сервер
spoiler
local 94.xxx.xxx.xxx
port 88888
;proto tcp
proto udp
;dev tap
dev tun1
;dev-node MyTap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
Ziptar, да уже неважно, всё равно делаю сервер на другом шлюзе. Столкнулся с проблемой - клиент не подключается:
spoiler
Wed Mar 18 19:52:41 2020 MANAGEMENT: >STATE:1584550361,WAIT,,,,,,
Wed Mar 18 19:53:41 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Mar 18 19:53:41 2020 TLS Error: TLS handshake failed
На сервере в iptables прописал
-A INPUT -p udp -m udp --dport 64991-j ACCEPT (64991 - порт OpenVPN на сервере)
но соединения всё равно нет. Или я что-то не так делаю?
Хм, идея возникла такая - а может ли тот шлюз, который щас клиент, быть сервером для этих самых удаленных пользователей? У меня к нему по крайней мере есть удаленный доступ по ssh
Он тоже шлюз по умолчанию, смотрит в интернет и имеет два белых ip
Сертификаты генерить придётся для каждого, потом каждому индивидуально настраивать, через что-то типа ammy или tw... печально.
Да, в рабочей сети сервер с OpenVPN является шлюзом по умолчанию, смотрит в интернет, и имеет белый IP.
Ну, придётся всё таки ехать, потому что связи с шлюзом нет почему-то. Не пойму в чём дело, даже с локальной машины ssh недоступен, Could not connect to '192.168.0.1' (port 22): Connection failed. Пинги ходят
Не подскажете, куда смотреть? Щас всё равно туда поеду, а новую тему поднимать не хочется
А если всё таки на основном? Чтобы поднимать новый, надо ехать в офис, что не совсем удобно. Просто пушить маршруты у клиентов во внутреннюю сеть? Сертификать можно использовать один? Не будет ли конфликта при использовании роутеров у клиентов? (ну к примеру у нескольких клиентов могут быть свои подсети за роутером одинаковые, и адреса машин одинаковые)
Порт используется не стандартный. Но, как уже говорил - на других машинах абсолютно те же настройки, и всё подключается. Снаружи, в пассивном режиме - тоже
ky0, вы мне эту ссылку уже давали. Там столько советов написано, что непонятно, какой из них действующий, а какой из разряда "ну попробуй вот так, не получится, значит не прокатило".
Примерная схема. На данный момент получается что интерфейс по умолчанию - eth1, через него идёт и веб-траффик, и туннель. eth0 по сути простаивает. Нужно чтобы весь веб-траффик шёл через один интерфейс, а туннель через другой. В идеале бы конечно как-то ещё отделить входящий траффик к астеру, но это уже необязательно.
ky0, если я со второго шлюза обращаюсь по внешнему IP - адрес недоступен. Как я предполагаю, потому что пакет приходит с одного интерфейса (внешнего), а отправляется по второму, через туннель. Как заставить туннель использовать определённый интерфейс?
Здесь этот вопрос обсуждался, но я так и зашёл в тупик с настройками. Собственно вы мне и советовали. Но я пробовал способы описанные в статье по ссылке, в результате только хуже стало, и эксперименты пришлось свернуть - удалённый сервер на одном из этапов вообще стал недоступен, пришлось скидывать всё до дефолтных настроек.
UPD. Причём очень желательно отделить так траффик на обоих шлюзах - так чтобы телефония и туннель использовали один канал, а интернет - другой. Сложность ещё в том, что сервер телефонии использует и обычный входящий траффик (не через туннель), от sip-провайдера.
iddqda, а можно более подробно? Я уже пробовал заворачивать туннель (телефония работает через него) на нужный интерфейс, но столкнулся с проблемой ассиметричности. Как заставить туннель использовать определённый интерфейс?
В ссылке которую дали воды столько, что уже непонятно, где рабочие советы, а где из разряда "ну попробуй, может так прокатит".
Ведь есть же наверняка рабочая схема, как отделить один траффик от другого, так чтобы телефония не глючила
iddqda, сервисы в сети сервисов... вы меня путаете.
Есть шлюз. Внутри сети есть сервер телефонии. Мне нужно чтобы обычный трафик из сети шёл по одному каналу, а трафик телефонии - по другому, дабы не было провисаний связи. Можете подсказать, как это сделать? И да, серевер телефонии использует ещё и туннель, через оный к телефонии подключается офис в другом городе.
Набрал в браузере toster.ru. Я всё правильно сделал?
Это маршрут по умолчанию, у меня ещё есть туннель, и по хорошему некоторые сервисы нужно пускать по другому каналу. Например ту же телефонию отделить от основного канала.
res2001, у старого и у нового шлюза адреса остались те же самые - 192.168.0.1 у серверного и 192.168.1.1 у клиентского. Шлюз и VPN сервер это одна и та же машина. Так же как VPN клиент является ещё и шлюзом в своей сети. Так как у нового шлюза ip адрес внутри своей сети такой же как у старого, менять у машин шлюз по умолчанию не требуется.
По сути сейчас вся загвоздка в том, что почему-то из сети клиента недоступна сеть сервера. Сам шлюз/сервер (192.168.0.1) доступен, а сеть за ним - нет, несмотря на вышеприведённые настройки iptables и вроде бы правильные маршруты.
