Ну да. И прелесть VPN в том, что достаточно победить этот геморрой
в одном месте - на сервере с широким каналом (чтобы хватало всем
клиентам). А далее - запускаешь на стороне клиента готовое
приложение (я подключался со смартфона, через готовый клиент
OpenVPN3) и работал на рабочем столе ПК через RealVNC Viewer (на ПК
стоял TighVNC). И к этому же ПК, подключался и подрядчик, по
необходимости. Достаточно было передать ему файл конфигурации VPN
со встроенными ключами. В своё время выбрал эллиптические кривые как наиболее эффективные по слухам в Интернет (своего анализа скорости работы и криптостойкости не делал).
Вот пример конфигурации клиента:
dev tun #Настраиваем туннель к серверу
ncp-disable #Не согласовывать шифрование, подключаться с шифрованием строго как указано в конфигурации
proto tcp-client #Роль устройства в протоколе TCP - клиент
nobind #Использовать динамический IP и порт, назначаемый сервером (на сервере поднят DHCP)
remote office.net 1194 #Публичный адрес сервера и порт для подключения
resolv-retry infinite #Не прекращать попытки соединения (полезно, если связь падает надолго)
ifconfig 10.0.254.3 10.0.254.1 #Когда лень настраивать DHCP на сервере, каждому клиенту IP и подсеть задаётся вручную в конфигурационном файле.
route 10.0.0.0 255.255.255.0 #Подсеть сервера (если нужен доступ к серверу или к узлам в его подесети)
route 10.0.1.0 255.255.255.0 #Подсеть удалённого хоста, к которому нужен доступ через сервер от этого клиента
ping 5 #Период проверки связи
ping-restart 60 #Перезапуск, если в течение минуты не было ни одного успешно принятого ответа
tls-client #Тип узла, к которому относится данная конфигурация
#Дальше не могу прокомментировать - не разбираюсь.
remote-cert-tls server
ecdh-curve secp384r1
auth SHA384
auth-nocache
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
persist-key
#CN=remoteaccess2
<ca>
-----BEGIN CERTIFICATE-----
Тут сертификат сервера
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
Тут сертификат клиента
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
Тут закрытый ключ
-----END ENCRYPTED PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
Тут ключ авторизации
-----END OpenVPN Static key V1-----
</tls-auth>
По идее, можно было настроить нормально DHCP на сервере, чтобы каждому клиенту раздавались нужные IP и маршруты. Но там была привязка к какой-то штуке, которую не захотел поднимать и настравать. Если не требуется менять IP и подсети клиентам, то можно сделать как я, задав IP и маршруты прямо в конфигурационных файлах клиентов. Если же сервер и подсети нормально администрируются, то стоит поднять полноценную службу DHCP с привязкой к авторизации клиентов. Помню, нюанс был в том, чтобы опознать клиента и после, назначить ему конфигурацию. Наверное, нужно было прописывать клиентов на сервере, чего я делать не стал, задав IP и подсети в конфигурациях жёстко.
Nikolay_Po (19.08.2024 13:23, просмотров: 118) ответил SciFi на Это всего лишь означает, что кто-то другой должен заниматься этими
белыми айпи и геморроем, с этим связанным. "Облачные сервисы iot"?