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

[Призрак]

Дома у меня организовано подключение к серверу, по служебной необходимости. Сервер OpenVPN, организован на Debian 8. Адрес у него серый, 192.168.60.1, адрес тапочка 192.168.25.1. Адрес моей домашней машины 192.168.11.12, адрес шлюза на домашней машине 192.168.11.1. Адрес тапочка на домашней машине 192.168.25.5. Удаленная операционная система Windows Server 2008 R2, серый адрес 192.168.10.1, адрес тапочка 192.168.25.2. В информации во вложении указано, что, когда, почем, зачем, где подключено. К сожалению, конфигурацию сервера предоставить не могу, только после физического доступа к серверу.

Собственно, вот проблема. Указана она, в основном, во вложении, где пинг и трассировка. Сразу же после подключения клиента я наблюдаю такую картину - трассировка ломится чёрт те куда, на белый провайдера, только через некоторое время начинает идти пинг, трассировка идёт куда надо, то есть подключение происходит не сразу к удалённой машине. После этого пинг обрывается, Это нормально или же это проблема? Я слышал о проблемах с Windows Server 2008 R2, но как это всё можно исправить? Бывают также обрывы связи, по непонятной причине. При этом на клиенте, 192.168.10.1, отсутствует пинг до 192.168.60.1, при этом трассировка ломится к чёрту на рога, куда - то через провайдера, в далёкое пешее. Вообще странно. Может быть мне по согласованию с начальством как нибудь перестроить существующую схему на работе?

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

Code Select Expand

dev tap
proto tcp

Уже здесь можно начинать тушить свет. TAP - это L2, т.е. эквивалент патч-корда проще говоря, в такой туннель тупо идет все широковещание, со всеми вытекающими.

TCP как транспорт - это прежде всего очень сильный оверхед, особенно если внутри тоже TCP и каналы далеки от идеала.

Зачем так сделано? Переделайте на TUN и UDP.

[Призрак]

Зачем так сделано лучше задать вопрос системным администраторам, которые наворотили это самое до меня. Я согласен с Вами, что схема несовершенна, тем более, связь очень медленная. Но как это всё теперь следует переделать? Нужно поставить основной сервер на шлюзе в административном корпусе и всё подключать именно к нему? А как же там адреса будут, они ведь будут выдаваться автоматически? И TAP адаптеров уже не надо будет? Я серьёзно прошу у коллег совета.

Но, наверное, придётся добавить следующее (это для того, чтобы всё работало с главного филиала) на сервере:

route 192.168.10.0 255.255.255.0

push "route 192.168.20.0 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"

А в ccd для клиента (на сервере)

iroute 192.168.10.0 255.255.255.0

Всё верно?

И ещё у меня важный вопрос. Я имею уже сгенерированные сертификаты сервера на другом сервере. Мне можно конфигурационный файл и сертификаты оттуда перенести на сервер административного корпуса? Или придётся генерировать всё заново? Ключи для клиентов из дома у меня с паролями, это я про клиентские.

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

Зачем так сделано лучше задать вопрос системным администраторам, которые наворотили это самое до меня. Я согласен с Вами, что схема несовершенна, тем более, связь очень медленная. Но как это всё теперь следует переделать? Нужно поставить основной сервер на шлюзе в административном корпусе и всё подключать именно к нему? А как же там адреса будут, они ведь будут выдаваться автоматически? И TAP адаптеров уже не надо будет? Я серьёзно прошу у коллег совета.

Для начала заменить tap на tun и tcp на udp, маршрутизация у вас вроде бы прописана правильно (на первый взгляд) и поломаться ничего не должно.

Хотя бы протокол для начала измените.

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

сё верно?

На первый взгляд - да.

И ещё у меня важный вопрос. Я имею уже сгенерированные сертификаты сервера на другом сервере. Мне можно конфигурационный файл и сертификаты оттуда перенести на сервер административного корпуса?

Можно. Также следует перенести CA - ту директорию в которой вы первоначально генерировали сертификаты, со всеми ключами и служебными файлами.

[Призрак]

Сделал всё по этой статье

https://interface31.ru/tech_it/2011/09/organizaciya-vpn-kanalov-mezhdu-ofisami.html

Всё получилось, но есть одно но. Я создал сервер и двух клиентов. Сгенерировал для них ключи, как указано в статье и ccd, как указано в статье. Конфиги во вложении. Сервер прекрасно пингует клиента, клиент прекрасно пингует сервер. Но клиент клиента почему - то не пингует ни в какую (client1-client2 client2-client1). Наверное, по этой причине был выбран tap?

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

Наличие или отсутствие пинга ровно ни о чем не говорит. Те же пользовательские системы Windows, начиная с Vistа, по умолчанию не отвечают на пинги. Далее надо смотреть на прохождение ICMP по всем участкам канала связи. Но опять таки должен быть смысл.

Для чего именно вы настроили связь клиент-клиент? Вот и проверяйте в первую очередь доступность нужного сервиса.

[Призрак]

Ну начнём с того, что брандмауэры я пока все отключил, службу маршрутизации настроил везде. Как я уже говорил, пинг идёт от клиентов к серверу, но не идёт от клиента к клиенту. А почему вы думаете, что связь между этими клиентами (шлюзами) настраивать не нужно? У нас есть рабочее место сотрудника библиотеки. Он должен подключаться к серверу библиотеки, который находится за одним из шлюзов и имеет адрес. К тому же, например, я сижу на одном из серверов, за шлюзом, мне нужно подключиться срочно к другому серверу, по RDP за шлюзом. Как это сделать в данном случае? Подключение пройдёт, если сервер находится за шлюзом с сервером OpenVpn, в другой подсети? Вот и гадай, на кофейной гуще, почему, зачем и как. Маршруты я смотрел, там есть только маршруты от клиентов (шлюзов) к серверу и от сервера к клиентам (шлюзам). Но между клиентами (шлюзами) нет маршрутов. Я пытался сделать так:

Это на втором шлюзе.

route add -p 192.168.1.0 mask 255.255.255.0 192.168.1.1
route add -p 192.168.1.0 mask 255.255.255.0 10.0.8.2

Это на первом шлюзе.

route add -p 192.168.2.0 mask 255.255.255.0 192.168.2.1
route add -p 192.168.2.0 mask 255.255.255.0 10.0.8.3

Всё к бестолку. Или вы всё же считаете, что не должны они между собой сообщаться? Тогда почему?

[Призрак]

Маршруты перепутал, не так написал. На самом деле они такие

Это на втором шлюзе.

route add -p 192.168.1.0 mask 255.255.255.0 192.168.2.1
route add -p 192.168.1.0 mask 255.255.255.0 10.0.8.3

Это на первом шлюзе.

route add -p 192.168.2.0 mask 255.255.255.0 192.168.1.1
route add -p 192.168.2.0 mask 255.255.255.0 10.0.8.2

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

Что означают эти адреса и сети я, наверное, должен догадаться... Где мой хрустальный шар?

[Призрак]

Эх, опять тут надо мной откровенно издеваются. А конфигурация, что я вам послал во вложении, ничего вам не говорит? Есть сервер, серый адрес 192.168.0.1, есть клиент 1, адрес 192.168.1.1, есть клиент 2, адрес 192.168.2.1. Клиент 1 и клиент 2 между собой связи не имеют. Теперь как?

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

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

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

[ival]

Это на втором шлюзе.

route add -p 192.168.1.0 mask 255.255.255.0 192.168.2.1
route add -p 192.168.1.0 mask 255.255.255.0 10.0.8.3

Это на первом шлюзе.

route add -p 192.168.2.0 mask 255.255.255.0 192.168.1.1
route add -p 192.168.2.0 mask 255.255.255.0 10.0.8.2

Чем обусловлено создание в одну и туже сеть двух маршрутов?

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

Копипастой из статьи, только там маршруты были на разных узлах, первый из которых шлюз, второй - OpenVPN сервер.

[ival]

Копипастой из статьи, только там маршруты были на разных узлах, первый из которых шлюз, второй - OpenVPN сервер.

Ну тогда скорее всего это и есть основная проблема.

А почему сервер vpn в статье поднимается отдельно от шлюза? Не лучше ли поднимать его на шлюзе? В принципе это уменьшит количество маршрутов, а в простых сетях вообще ограничится только одним маршрутом по умолчанию.

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

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

[Призрак]

Если долго мучиться, что нибудь получится. Во вложении вся необходимая информация. В документе я выделил красным, собственно, то, чего и хотел добиться. То есть, если я сижу на шлюзе, мне надо подключиться к другому шлюзу, который не сервер (от клиента к клиенту), тогда мне надо прописать такие маршруты. Теперь у меня ещё вопросы.

1. В рамках существующей инфраструктуры, могу ли я подготовить сервер в административном корпусе, как tun? Это не будет мешать существующим сетям, которые подключены как tap?

2. Мне посоветовали скопировать папку с ключами. Проблема лишь в том, что сервер, как и ключи, изначально билдились на линуксе, а теперь будет копироваться на Windows, с присвоением бывшему серверу статуса клиента. Не будет ли в этом проблемы?

[Призрак]

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

Ну да, ну да. Можно подумать, что всё так просто и даже профессиональный системный администратор никогда не машет бубном. Всегда есть проблемы, нелогичные, которые возникают неожиданно, но не по вине самого системного администратора. Проблемы бывают и по вине разработчиков программного обеспечения, как ни странно. Например, пытаешься удалить или исправить программу на сервере, а она тебе пишет "не установлен Net Framework 2.0", хотя как на самом деле он установлен. Или при переустановке с удивлением обнаруживаешь, что программа требует права на ключ реестра, хотя при самой первой установке, со всеми обновлениями оси, она его не потребовала. Да, вы угадали, это всеми обожаемый прокси сервер traffic inspector, во всей красе. Российская, кстати, разработка. Администраторы его очень любят, сомневаться не приходится.

Что же касается маршрутизации, это очень обидное для меня замечание. Минимальные знания у меня есть, я это изучал, на минимальном уровне. Таблица маршрутизации состоит из адреса, маски подсети, основного шлюза, интерфейса и метрики маршрута. По таблице можно узнать, куда идут пакеты. Если бы я совсем был тупым, я бы вообще не смог настроить никакую сеть. Не смог бы ввести в эксплуатацию OpenVPN сервер, когда это было необходимо. Установить и настроить новый шлюз, когда сломался сервер. Да что там...

Вы посмотрите внимательно, в моих вложениях, выделены красным маршруты, он работают. А те, что указаны в статье, не работают, проверено. Мелкие ошибки часто вводят в заблуждение новичков. Ну и что, что у меня на VMWare всё, нет это полностью имитирует рабочую сеть. Не буду же я бегать по филиалам, к тому же, тут нужны отдельные белые адреса, кто мне их выделит, это дорогое удовольствие.

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

Например, пытаешься удалить или исправить программу на сервере, а она тебе пишет "не установлен Net Framework 2.0", хотя как на самом деле он установлен. Или при переустановке с удивлением обнаруживаешь, что программа требует права на ключ реестра, хотя при самой первой установке, со всеми обновлениями оси, она его не потребовала. Да, вы угадали, это всеми обожаемый прокси сервер traffic inspector, во всей красе.

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

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

Начнем с того, что схема, которую вы нарисовали, не соответствует вашему же описанию. К тому же содержит много лишнего, что запутывает понимание. Ладно, нарисую вашу схему за вас.

Как я понял, у нас есть три сети: нулевая, первая и вторая. В ней есть три клиента, с адресами заканчивающимися на двойку, но это абсолютно неважно. Есть три шлюза, "единички", которые вторым концом глядят в интернет. В данной схеме он эмулируется одиннадцатой сетью и тоже нас абсолютно не интересует. Они же участники VPN-сети. Нулевой шлюз - сервер, первый и второй  - клиенты.

Что немного напрягает, так это DNS в 11-й сети, т.е. за пределами локальной сети. Если это сделано в целях упрощения моделирования, то ОК (вместо реального сервера используем заглушку от VMWare). В реальной жизни так делать нельзя. В доменной сети свой контроллер должен быть в каждом сайте, чтобы при обрыве связи между сайтами вы не остались у разбитого корыта.

Едем дальше. Так как все VPN-сервера/клиенты у нас шлюзы, то никакой маршрутизации в сети прописывать не надо, все пакеты и так придут на шлюз. А вот дальше есть варианты.

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

Поэтому логично заставить разруливать все маршруты сам OpenVPN.

В конфиге сервера:

Code Select Expand

route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
Это создаст маршруты для "чужих сетей" в туннель, и передаст им маршрут в туннель для "своей сети".

Знать кто есть кто нам необязательно, достаточно передать пакет на tun-интерфейс.

Чтобы OpenVPN дальше понял куда доставлять пакет, в ccd клиентов укажем:

Для первого клиента

Code Select Expand

iroute 192.168.1.0 255.255.255.0
Для второго клиента

Code Select Expand

iroute 192.168.2.0 255.255.255.0
Эти команды будут создавать внутренний маршрут для доставки пакетов этих сетей на внутренний OVPN-адрес

Больше не нужно ничего. Запускаем и радуемся. Центр видит сети за клиентами, клиенты видят центр.

Но друг-друга клиенты видеть не будут. Потому что шлюз два знает только маршрут в нулевую сеть, но не знает в первую. То же самое и с первым шлюзом. Поэтому в ccd добавляем роуты:

Для первого клиента

Code Select Expand

push "route 192.168.2.0 255.255.255.0"
Для второго клиента

Code Select Expand

push "route 192.168.1.0 255.255.255.0"
Это создаст маршруты для указанных сетей в туннель, а там OpenVPN уже сам разберется кому доставлять пакет.

Почему в ccd, а не конфиг сервера? Потому что для нулевой сети (за сервером) мы передаем маршрут всем, а для конкретной сети - не всем, иначе  местами получится ерунда.

[Призрак]

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

Я использую версию 2.0.0.644. Она была выпущена 17.10.2011. Последняя версия Windows Server 2008 R2 была выпущена 22.02.2011. Так что на тот момент Windows Server 2008 R2 не была устаревшей, как и Traffic Inspector не был устаревшим. Значит, что должна быть ещё совместимость. А если есть ошибки, то тут как раз проблема разработчика. Потому - что повторюсь, на тот момент серверная 2008 ось была актуальна. Вы сами попробуйте на виртуальной машине. А мне пришлось на реальном сервере исправлять.

[Призрак]

Что немного напрягает, так это DNS в 11-й сети, т.е. за пределами локальной сети. Если это сделано в целях упрощения моделирования, то ОК (вместо реального сервера используем заглушку от VMWare). В реальной жизни так делать нельзя. В доменной сети свой контроллер должен быть в каждом сайте, чтобы при обрыве связи между сайтами вы не остались у разбитого корыта.

Это же просто виртуальный полигон, без Active Directory. Естественно, в боевой сети всё будет и никак иначе. Это просто эксперимент. Не буду же я, согласитесь, проводить эксперименты на боевом сервере?

Можно узнать, где вы рисуете сети? Visio? Да. я не художник, к сожалению. Поэтому у меня плохо получаются схемы.

В который раз убеждаюсь, что меня консультирует высококлассный специалист. После ваших пояснений всё получилось, клиенты стали пинговать друг друга, видеть. Кроме того, я понял истинное назначение папки ccd. В случае чего мне не надо лезть на клиентов, а просто прописать маршруты в ccd. Это будет гораздо быстрее и надёжнее, чем запутаться окончательно. Я вообще в недоумении, почему мои предшественники использовали тапки, ведь на каждой же машине пришлось расписывать маршруты, я просто в ужасе.

Непонятным остался только один вопрос - как перенести ключи с debian и могу ли я сделать его клиентом?

[Призрак]

Только обрадовался, что дома получилось, замутил на сервере, пытаюсь подключиться из дома, ни в какую. На той стороне брандмауэры отключены, traffic inspector отключен брандмауэр, всё к бестолку. На самом сервере OpenVPN запускается, интерфейс поднимается. Не знаю что и гадать. Дома микротик, брандмауэр выключал. Тоже к бестолку. UDP, видать, не работает.

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

Я использую версию 2.0.0.644. Она была выпущена 17.10.2011. Последняя версия Windows Server 2008 R2 была выпущена 22.02.2011. Так что на тот момент Windows Server 2008 R2 не была устаревшей, как и Traffic Inspector не был устаревшим.

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

Можно узнать, где вы рисуете сети? Visio?

Да, Visio.

Это же просто виртуальный полигон, без Active Directory. Естественно, в боевой сети всё будет и никак иначе. Это просто эксперимент. Не буду же я, согласитесь, проводить эксперименты на боевом сервере?

Ну так я и сказал: если это полигон - то все нормально, в реальной жизни так делать не надо. Мало ли кто еще будет читать эту тему и какие выводы он для себя сделает.

Непонятным остался только один вопрос - как перенести ключи с debian и могу ли я сделать его клиентом?

Просто скопируйте и все. Затем разместите это все в папке вашего экземпляра easy-rsa с перезаписью существующих файлов, только не сделайте потом:

Code Select Expand

clean-all
build-ca
Потому что этим вы затрете существующий CA и все ключи придется выпускать заново.

На Debian просто удалите конфигурацию сервера и добавьте конфигурацию клиента. OpenVPN может одновременно быть и тем, и другим.

Не знаю что и гадать. Дома микротик, брандмауэр выключал. Тоже к бестолку. UDP, видать, не работает.

А это похоже, что где-то не проходит UDP, в принципе можно задать вопросы провайдеру. Они обязаны соблюдать сетевой нейтралитет, т.е. пропускать через себя любой трафик, без ограничения по его типу. Хотя это может быть и не на его стороне. В противном случае переходите на протокол TCP, с TUN он вполне нормально работает, широковещания нет, хотя производительность будет несколько ниже, чем на UDP.

[Призрак]

А tap он ведь по tcp и работает по умолчанию? Вот у нас все подключения, вероятно, на tcp, потому - что tap. Таким образом, я подозреваю, что udp у нас действительно блокируется, потому - что рабочий стол проходит, там же tcp порт, а на debian там установлен, как и везде, tap.

Самое смешное, что я проверяю через 2ip порты, они закрыты, но трафик ходит. Что это вообще такое.

Как мне тогда перестроить конфиги, чтобы они работали по tcp? Я проблвал менять на сервере, там ок, а вот на клиенте ошибка.

Ага, в двух конфигурационных файлах на сервере адреса портов совпадают! Может ли быть то, что порт занят, к нему не идёт подключение? Порт изменить?

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

Рекомендуемый транспорт для OpenVPN - UDP, вне зависимости от типа туннеля. В конфигах меняется одна единственная строчка, но во всех, и серверных и клиентских.

Code Select Expand

proto udp / proto tcp

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

Ага, в двух конфигурационных файлах на сервере адреса портов совпадают!

Это как так? У вас два экземпляра OpenVPN запущено на одном хосте?

[Призрак]

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

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

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

[Призрак]

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

Я всё сделал, на центральном шлюзе, при этом мне удалось подключиться из дома! Как оказалось, было дело вовсе не в провайдере, а в номере порта, я выставил его в 1200, оставил udp. Правда, пришлось немного повозиться с маршрутами, чтобы оно заработало, но стоило того (я сменил свою домашнюю сеть на 12.0, так как оказалось, что 11.0 есть на работе). Подключается всё мгновенно, со свистом. Осталось только всё остальное перевести, но это уже дело техники.

Теперь я все настройки могу производить через клиентские файлы ccd, не залезая в сами шлюзы и не прописывая там маршруты, которые ведут чёрт те куда, чёрт те зачем были вообще сделаны, тем более на tap. Если кому - то нужны мои вложенные файлы, (ну, разумеется, кроме позорной схемы), пусть используют на здоровье, мне не жалко.

[Призрак]

Ещё будет вопрос. Я могу использовать openvpn-install-2.4.7-i603? Он у меня нормально работает, на одном из серверов. Кроме того, устанавливая операционную систему на шлюзе и настраивая её я столкнулся с неожиданной и весьма досадной проблемой, во вложении. Оперативная память? Или что-то другое?

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

Ещё будет вопрос. Я могу использовать openvpn-install-2.4.7-i603?

А почему нет, используйте.

Кроме того, устанавливая операционную систему на шлюзе и настраивая её я столкнулся с неожиданной и весьма досадной проблемой, во вложении.

Включаем сбор минидампов, затем качаем BlueScreenView и анализируем дампы на возможную причину сбоя.

В вашем случае падает ядро, причин может быть много, начиная от аппаратных. Но ошибка 0x00000109 часто вызывалась в свое время патченым ядром в различных сборках.

[Призрак]

Решил я провести один эксперимент, с огорчением обнаружил, что есть проблема одна. Помните я отправлял сведения по полигону? Так вот, в конфиге сервера у меня изначально было так:

Code Select Expand

route 192.168.1.0 255.255.255.0 10.8.0.2
route 192.168.2.0 255.255.255.0 10.8.0.3
Я решил сделать так, как советуете вы, то есть вот так

Code Select Expand

route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
Скопировал файл сервера, исправил, потом снова скопировал файл сервера на место, перезапускаю службу, а он мне говорит, при попытке пинговать клиентов, что превышен интервал ожидания для запроса. При этом клиенты отлично пингуют сервер. Хорошо, сервер перезагружаю, при этом опять клиенты отлично пингуют сервер, сервер клиентов опять не видит, клиенты видят сервер, но друг друга опять не видят.

Возвращаю всё на круги своя, то есть добавляю 10.8.0.2 и 10.8.0.3, перезапускаю службу. Те же яйца, вид сбоку. Но на этот раз вместо "превышен интервал ожидания для запрос"а выводится "ответ от 10.8.0.1 заданный узел недоступен". При всём этом перезапуск клиентов не даёт результата.

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

Code Select Expand

ccd client1

ifconfig-push 10.8.0.2 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route-gateway 10.8.0.1"
push "sndbuf 524288"
push "rcvbuf 524288"
iroute 192.168.1.0 255.255.255.0

Code Select Expand

ccd client2

ifconfig-push 10.8.0.3 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "route-gateway 10.8.0.1"
push "sndbuf 524288"
push "rcvbuf 524288"
iroute 192.168.2.0 255.255.255.0

Code Select Expand

server.ovpn

proto udp
port 1194
dev tun
tls-server
topology subnet
route-method exe
route-delay 5
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"
tls-auth "C:\\Program Files\\OpenVPN\\easy-rsa\\ta.key" 0
route 10.8.0.0 255.255.255.0
route 192.168.1.0 255.255.255.0 10.8.0.2
route 192.168.2.0 255.255.255.0 10.8.0.3
push "route 192.168.0.0 255.255.255.0"
cipher BF-CBC
comp-lzo
verb 1
keepalive 5 60
sndbuf 524288
rcvbuf 524288


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

Возникает вопрос: вы понимаете, что написано в ваших конфигах?

Зачем на сервере:

Code Select Expand

route 10.8.0.0 255.255.255.0
если эта сеть доступна там без маршрутизации?

Зачем эта дичь на клиентах?

Code Select Expand

push "route 10.8.0.0 255.255.255.0"
push "route-gateway 10.8.0.1"
Ясное дело, что с такими маршрутами ничего работать не будет. Выше я написал все, что вам нужно, откуда и зачем эта самодеятельность?

[Призрак]

Вы меня прямо удивляете, с каждым днём всё больше. Из статьи, вестимо, человека, которого вы нахваливали, откуда же ещё? Вот отсюда.

https://interface31.ru/tech_it/2011/09/organizaciya-vpn-kanalov-mezhdu-ofisami.html

Вы посмотрели мой полигон, сказали, что всё в порядке. Посмотрели? Почему вы сразу замечание не сделали? Беда прямо, слов нет. Эти строчки нужно убрать полностью, из всех конфигов?

Кроме того, вы, помнится, говорили, что вот эта строчка

Code Select Expand

push "route-gateway 10.8.0.1"
важна для того, чтобы всё работало. Не так? Если так, то почему её надо убрать?