LINUX.ORG.RU

Сообщения naemeless

 

OpenVPN и изоляция клиентов

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

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

 , ,

naemeless
()

cifs-utils, fstab и права доступа на подкаталоги

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

Есть сервер на 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, то на подкаталоги невозможно выставить любые другие права, поскольку они наследуют права родителя при монтировании, и пользователю недоступна запись.

 , ,

naemeless
()

squid + ad

Всем добрый день. Прошу помочь любителей кальмаров. Есть 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.

 , ,

naemeless
()

OpenVPN и gateway parameter

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

Имеется 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

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

 , ,

naemeless
()

RSS подписка на новые темы