Проблемы с OpenVPN, медленное подключение к клиентам, обрывы связи

[Призрак]

Я сейчас вдребезги расшибу всё. Вот конфиги.

Сервер

Code Select Expand

proto udp
port 1200
dev tun
tls-server
topology subnet
route-method exe
route-delay 5
dev-node OpenVPN
server 10.8.0.0 255.255.255.0
route-gateway 10.8.0.1
client-config-dir "C:\\Program Files\\OpenVPN\\ccd"
ca  "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt" 
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\server.crt" 
key  "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\server.key" 
dh "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\dh2048.pem"
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.128.0 255.255.255.0"
route 192.168.20.0 255.255.255.0
route 192.168.30.0 255.255.255.0
route 192.168.50.0 255.255.255.0
route 192.168.60.0 255.255.255.0
cipher AES-256-CBC
comp-lzo
verb 5
keepalive 5 15

Клиент

Code Select Expand

dev tun
proto udp
port 1200
remote XX.XXX.217.202
tls-client
remote-cert-tls server
route-method exe
route-delay 5
pull
ca "C:\\Program Files\\OpenVPN\\keys\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\keys\\kr46.crt"
key "C:\\Program Files\\OpenVPN\\keys\\kr46.key"
cipher AES-256-CBC
comp-lzo
verb 5
auth-nocache
keepalive 5 15
ccd

Code Select Expand

ifconfig-push 10.8.0.2 255.255.255.0
push "route 192.168.30.0 255.255.255.0"
push "route 192.168.50.0 255.255.255.0"
push "route 192.168.60.0 255.255.255.0"
iroute 192.168.20.0 255.255.255.0

Логи сервера и клиента во вложении. В данном случае ip адрес клиента 192.168.20.1

С клиента на сервер идёт связь, а вот с сервера на клиента ни в какую. Я уже не знаю, что предпринять.

Вот когда я вручную добавляю маршруты, тогда всё заводится. А так ни в какую.

[Призрак]

Вот логи

[Призрак]

route 192.168.20.0 255.255.255.0 10.8.0.2
route 192.168.30.0 255.255.255.0 10.8.0.3
route 192.168.50.0 255.255.255.0 10.8.0.5
route 192.168.60.0 255.255.255.0 10.8.0.6

И да, я прошу прощения за эту самодеятельность! Дело в том, что если я так не укажу, то не работает почему - то связь. То есть я пытаюсь пинговать и подключаться к отдельному узлу с сервера, ни в какую. Только после того, как я ставлю явно адреса, то всё начинает работать. Может быть, всё дело в Traffic Inspector.

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

[Призрак]

И ещё нашёл я одну проблему. Дело в том, что у нас есть traffic inspector, я уже говорил. Вот лог, как будто он всё время перезагружается, перезапускается, почему, мне неизвестно. Дело в том, что так себя ведут именно проблемные хосты, это 192.168.30.0 и 192.168.20.0, как раз у меня там установлена Hyper-V и на ней крутятся эти машины. Такая проблема только там. Мне кажется, здесь собака зарыта, но мне непонятно, почему Traffic Inspector так себя ведёт, пока непонятно.

[Уваров А.С.]

Дело в том, что если я так не укажу, то не работает почему - то связь.

Значит у вас не работает маршрутизация внутри VPN сети, либо неправильно настроена. В итоге у вас снова каша из маршрутов, поэтому не удивляетесь, что там рвет, а там отваливается.

не кажется, здесь собака зарыта, но мне непонятно, почему Traffic Inspector так себя ведёт, пока непонятно.

В поддержку Трафика обращались?

[Призрак]

Значит у вас не работает маршрутизация внутри VPN сети, либо неправильно настроена. В итоге у вас снова каша из маршрутов, поэтому не удивляетесь, что там рвет, а там отваливается.

Я уже привёл конфигурационные файлы. Сделал всё так, как Вы мне сказали, в предыдущих постах. Что ещё привести? Кстати, я сегодня зашёл, в великой злобе обнаружил, что опять нет связи! У меня такое чувство, что бешеный OpenVPN почему - то сбрасывает маршруты на сервере, постоянно. В бешенстве я сделал так, как на снимке экрана, убрав это из конфигурационных файлов (во вложении). Вот Вы говорите, не удивляйтесь, я Вам ведь всё приводил, снова и снова. И, если надо, по Вашему запросу приведу снова.

Кстати, если Вы сомневаетесь, то соберите виртуальный полигон, по моей информации и попробуйте. У Вас будет всё точно так же, как у меня, я уверен.

В поддержку Трафика обращались?

Да, написал обращение.

[Призрак]

Ещё раз, для верности

Сервер

Code Select Expand

proto udp
port 1200
dev tun
tls-server
topology subnet
route-method exe
route-delay 5
dev-node OpenVPN
server 10.8.0.0 255.255.255.0
route-gateway 10.8.0.1
client-config-dir "C:\\Program Files\\OpenVPN\\ccd"
ca  "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt" 
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\server.crt" 
key  "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\server.key" 
dh "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\dh2048.pem"
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.128.0 255.255.255.0"
cipher AES-256-CBC
comp-lzo
verb 5
keepalive 5 15

ccd

Code Select Expand

ifconfig-push 10.8.0.2 255.255.255.0
push "route 192.168.30.0 255.255.255.0"
push "route 192.168.50.0 255.255.255.0"
push "route 192.168.60.0 255.255.255.0"
iroute 192.168.20.0 255.255.255.0

Клиент

Code Select Expand

dev tun
proto udp
port 1200
remote XX.XXX.217.202
tls-client
remote-cert-tls server
route-method exe
route-delay 5
pull
ca "C:\\Program Files\\OpenVPN\\keys\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\keys\\kr46.crt"
key "C:\\Program Files\\OpenVPN\\keys\\kr46.key"
cipher AES-256-CBC
comp-lzo
verb 5
auth-nocache
keepalive 5 15


[Призрак]

Вот, хочу сказать, что пушает он исправно маршруты, они на соседних машинах работают, не отключаясь. А вот, собственно, команда route почему - то работает плохо. То есть, через некоторое время что-то уничтожает маршруты. Может быть, всё дело в виртуальных сетевых картах? На моём виртуальном полигоне так же, кстати. Он построен на vmware workstation. На работе у нас vsphere 6.5, на машине виртуальной развёрнут сервер OpenVPN. Не оттуда ли ноги растут?

[Уваров А.С.]

Не оттуда ли ноги растут?

Ну а нам то откуда знать? Кстати, у вас какое образование? Что-то мне подсказывает, что не техническое. Это ни в коем случае не выпад в вашу сторону, но у технарей еще со студенческой скамьи приобретается особый, инженерный, подход к диагностике и исправлению неисправностей.

Сделал всё так, как Вы мне сказали, в предыдущих постах.

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

Я к тому, что это не догма, можно сделать так, можно иначе. Вы еще спрашивали по поводу той статьи, почему там сделано так, а я рекомендовал иначе. Это как раз тот случай, когда к верному ответу ведут несколько решений.

[Призрак]

Ну а нам то откуда знать? Кстати, у вас какое образование? Что-то мне подсказывает, что не техническое. Это ни в коем случае не выпад в вашу сторону, но у технарей еще со студенческой скамьи приобретается особый, инженерный, подход к диагностике и исправлению неисправностей.

Да, изначально не техническое, это верно. Я не считаю это выпадом с вашей стороны, вопрос вполне справедливый и нормальный. Но далее я прошёл переподготовку в Пермском РМЦПК по теме "организация и обслуживание компьютерных серей майкрософт". Если нужно доказательство, то я могу прислать скан документа. Естественно, для того, чтобы не быть голословным. И ранее я ещё работал техником.

А что делать то, если журналы почти ничего не показывают? Кстати, заметил прелюбопытнейшую вещь - после того, как я маршруты прописал вручную, из Traffic Inspector исчезли сообщения о циклической перезагрузке, это на удаленном шлюзе, не на сервере. Маршруты прописал на сервере.

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

Тут я с вами полностью согласен. Если нужно нарисовать полную схему сети, я её нарисую, как на моём месте работы.

Я к тому, что это не догма, можно сделать так, можно иначе. Вы еще спрашивали по поводу той статьи, почему там сделано так, а я рекомендовал иначе. Это как раз тот случай, когда к верному ответу ведут несколько решений.

Да, это так. Но хотя бы в общих чертах можно узнать, чем отличаются эти самые решения? Вот вы указали правильный вариант, просто он работает не совсем корректно, может быть, из-за виртуальных карт, может быть, из-за Traffic Inspector, может быть, из-за чего - то другого.

И вы же ведь прекрасный специалист по электронике, должны знать, что чудес не бывает, как в электронике, так и в ит. Если в блоке питания что-то к примеру сломалось, то он работать не будет весь, приходится искать, где и что поломалось. Знавал я человека, который сильно ругался, что горит предохранитель в блоке питания "я ведь его заменил, какого он не работает?". Я ему сказал, проверяй обвязку, он на меня посмотрел сумасшедшим взглядом. Пришлось ремонтировать самому.

Так же и тут. Я не хочу сказать плохо в сторону производителя программ. Но ведь их пишут программисты, люди, которым свойственно ошибаться. Где - то что-то не дописали, где - то что-то вырезали лишнее. Кроме того, выясняется, к примеру, что программу писали совсем для другой конфигурации, не тестируя на другом железе. Ведь Traffic Inspector 2.0.0.644 должен корректно работать на Windows Server 2008 R2, а вот досада, тут и Hyper-V и Vsphere. Естественно, в идеале программисты должны тестировать программные продукты на совместимость, выпуская патчи и исправления, а получается так, что они просто выпускают новую версию, требуют за неё бабки, которые в учебном заведении тратят на какую - то аккредитацию, которая нужна учёбе, как зайцу подсвечник, вот и весь сказ. Тут бизнес, ничего личного.

[Уваров А.С.]

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

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

Кстати, заметил прелюбопытнейшую вещь - после того, как я маршруты прописал вручную, из Traffic Inspector исчезли сообщения о циклической перезагрузке, это на удаленном шлюзе, не на сервере.

А это уже что-то из области фантастики, причем ненаучной. Либо вы неправильно интерпретировали события и их причинно-следственную связь. В любом случае нужно разбираться.

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

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

[Призрак]

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

Да, эта идея не нова. Так работают и сыщики, и следователи, и судебные медики. Да ещё много кто. Но и в ИТ и в электронике бывают такие понятия, как эпизодические отказы. Ну, скажем, у вас блок питания работает нормально, а потом начинает барахлить. Что это? А причиной может быть элементарная трещина в плате. То же самое в ИТ. Пакеты идут нормально, потом затык и начинается ругань. А почему так происходит? Да потому - что дело может быть буквально в кабеле, в свитче, в котором беременные конденсаторы, в поломанной оперативной памяти, в дефектном жёстком диске, где головка заскочила на дефектный участок.

А это уже что-то из области фантастики, причем ненаучной. Либо вы неправильно интерпретировали события и их причинно-следственную связь. В любом случае нужно разбираться.

Проверил всё снова, да, сопоставил, циклический перезапуск исчез. Не берусь судить точно, не знаю что это, но так, как я добавил маршруты вручную это решило проблему. Связь больше не обрывается, работает более менее стабильно.

Кстати, вчера пришлось выехать в один из корпусов, там traffic inspector "положил" сетевой интерфейс, причём внешний, с ошибкой "устройство не опознаёт команду ioctl_open_adapter", судя по тому, что в сети мало информации по этой ошибке, она эпизодическая, что самое подлое. Так что лучше ничего не трогать лишний раз.

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

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

 
Кроме того, некий клоун, который возомнил себя неслабым ИТ специалистом (догадайтесь, кто это), выдвинул инициативу о замене зарубежного программного обеспечения российским. Это тоже создаст проблемы в будущем, при этом проблемы достаточно серьёзные.