Всем привет. Может быть кто-то сталкивался с подобной проблемой? Каким образом на сервере OpenVPN, который работает на CentOS, можно изолировать клиентов друг от друга? Топология — subnet, интерфейс tun0 находится в зоне trusted на firewalld. Можно, конечно, переместить tun0 в другую зону, но тогда клиенты OpenVPN перестанут видеть не только друг друга, но и, например, сеть, в которой находится eth0 самого сервера CentOS.

P.S. Смена топологии и использование client-to-client в конфиге неприменимо в моем случае.

Добрый день. Может быть кто-то сможет натолкнуть на мысль, каким образом можно побороть проблему прав доступа.

Есть сервер на CentOS, к которому монтируется шара с Windows Server с помощью fstab.

//10.20.30.40/share /mnt/share cifs credentials=/root/.smbclient,file_mode=0755,dir_mode=0755,nounix 0 0

Этот же каталог является ChrootDirectory для SFTP, внутри которого находятся подкаталоги %u, которые являются local_root для пользователей.

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

fatal: bad ownership or modes for chroot directory

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

Всем добрый день. Прошу помочь любителей кальмаров. Есть Squid 3.5.20, работающий на CentOS 7. Сервер является членом AD, настроена авторизация пользователей. Все было прекрасно до позавчерашнего дня. Сначала у пользователей перестали открываться некоторые сайты, потом перестали открываться почти все сайты.

Самое подозрительное, что нашел в cache.log:

negotiate_kerberos_auth.cc(180): pid=1562 :2022/04/13 15:51:52| negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. Cannot find key for HTTP/te-gw02-m.main.domain.ru@MAIN.DOMAIN.RU kvno 4 in keytab

access.log полон сообщений:

TCP_DENIED/407 4254 CONNECT api.msn.com:443 - HIER_NONE/- text/html

Никаких изменений в AD в учетной записи, связанной с keytab-файлом, не было. Я пробовал генерировать его заново, подкладывать, но результат тот же. Пробовал восстанавливать сервер из бэкапа. Тоже не помогло.

Чувствую, это как-то связано с kvno 4 и атрибутом msDS-KeyVersionNumber, равный 3.

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

Имеется CentOS 7 с поднятым OpenVPN. Приведу конфиг сервера и клиента.

local 192.168.205.210
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/issued/vpn-server.crt
key keys/private/vpn-server.key
dh keys/dh.pem
remote-cert-tls client
tls-auth keys/ta.key 0
server 192.168.148.0 255.255.252.0
#ifconfig-pool-persist ipp.txt
duplicate-cn
keepalive 10 120
max-clients 750
client-to-client
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 0
mute 20
daemon
mode server
tls-server
comp-lzo

management localhost 1195

username-as-common-name
plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so /etc/openvpn/auth/ldap.conf

push "dhcp-option DOMAIN xxx.xxxxx.ru"

push "route 192.168.200.0 255.255.248.0"
push "route 192.168.72.0 255.255.254.0"
push "route 192.168.100.0 255.255.255.0"

push "dhcp-option DNS 192.168.200.2"
push "dhcp-option DNS 192.168.200.4"
push "dhcp-option DNS 192.168.72.4"
push "dhcp-option DNS 192.168.72.8"
push "dhcp-option DNS 192.168.100.4"

client
resolv-retry infinite
nobind
remote xxx.xxxxx.ru 1194
proto udp
dev tun
comp-lzo
ca ca.crt
cert client1.crt
key client1.key
remote-cert-tls server
tls-client
tls-auth ta.key 1
float
keepalive 10 120
persist-key
persist-tun
auth-nocache
auth-user-pass
verb 0

Нагрузка на сервер — несколько сотен человек, клиенты разнообразные, включая Windows, Linux, MacOS, Android, iOS etc.

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

OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options

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