Настройка VPN-сервера (OpenVPN) в CentOS/RHEL 7
Содержание
OpenVPN — свободная реализация технологии Виртуальной Частной Сети (VPN) с открытым исходным кодом для создания зашифрованных каналов типа точка-точка или сервер-клиенты между компьютерами. Она позволяет устанавливать соединения между компьютерами, находящимися за NAT-firewall, без необходимости изменения их настроек.
Подключаем репозиторий EPEL
Для того чтобы установить OpenVPN – необходимо подключить EPEL-репозиторий (Extra Packages for Enterprise Linux):
$ yum -y install epel-release
Устанавливаем OpenVPN
$ yum -y install openvpn
Настраиваем OpenVPN в простейшем варианте
Прежде всего доведём OpenVPN до рабочего состояния, а потом уже накрутим необходимые «навороты». Нам понадобится личный ключ, сертификат и сертификат центра сертификации. Как их создать – можно прочитать в этой статье.
$ cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn $ chcon -u system_u /etc/openvpn/server.conf $ nano -w /etc/openvpn/server.conf port 1194 proto udp dev tun ca /etc/pki/tls/certs/sub.class1.server.ca.pem cert /etc/pki/tls/certs/vpn.example.com.crt key /etc/pki/tls/private/vpn.example.com.key dh dh2048.pem server 10.8.0.0 255.255.255.0 push "route 10.8.0.0 255.255.255.0" keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status /var/log/openvpn-status.log verb 3 # Username and Password authentication. client-cert-not-required plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn $ nano -w /etc/pam.d/openvpn auth required pam_unix.so shadow nodelay account required pam_unix.so $ chcon -u system_u /etc/pam.d/openvpn $ touch /var/log/openvpn-status.log $ restorecon -v /var/log/openvpn-status.log $ openssl dhparam -out /etc/openvpn/dh2048.pem 2048 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time ...
Некоторые OpenVPN-клиенты не умеют работать по UDP, как например OpenVPN-клиент в роутерах MikroTik, в этом случае, вместо строки proto udp
нужно написать proto tcp
. Авторизацию в этом конфигурационном файле мы включили по системным пользователям. Т.е. для подключения, в настройках клиента нужно будет указать логин и пароль уже существующего пользователя.
Настраиваем firewall
$ firewall-cmd --permanent --zone=public --add-service=openvpn $ firewall-cmd --permanent --zone=public --add-port=1194/tcp $ firewall-cmd --reload
Первая строка разрешит подключаться к OpenVPN-серверу по протоколу UDP, вторая по TCP.
Пробный запуск OpenVPN-сервера
Теперь, запустим наш OpenVPN-сервер и попробуем к нему подключиться:
$ cd /etc/openvpn $ openvpn server.conf Sat Nov 22 22:00:23 2014 OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 14 2014 Sat Nov 22 22:00:23 2014 PLUGIN_INIT: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so '[/usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY Sat Nov 22 22:00:23 2014 Diffie-Hellman initialized with 2048 bit key Sat Nov 22 22:00:23 2014 WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate Sat Nov 22 22:00:23 2014 Socket Buffers: R=[212992->131072] S=[212992->131072] Sat Nov 22 22:00:23 2014 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=eth0 HWADDR=00:16:3e:00:00:dc Sat Nov 22 22:00:23 2014 TUN/TAP device tun0 opened Sat Nov 22 22:00:23 2014 TUN/TAP TX queue length set to 100 Sat Nov 22 22:00:23 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Sat Nov 22 22:00:23 2014 /usr/sbin/ip link set dev tun0 up mtu 1500 Sat Nov 22 22:00:23 2014 /usr/sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2 Sat Nov 22 22:00:23 2014 /usr/sbin/ip route add 10.8.0.0/24 via 10.8.0.2 Sat Nov 22 22:00:23 2014 GID set to nobody Sat Nov 22 22:00:23 2014 UID set to nobody Sat Nov 22 22:00:23 2014 UDPv4 link local (bound): [undef] Sat Nov 22 22:00:23 2014 UDPv4 link remote: [undef] Sat Nov 22 22:00:23 2014 MULTI: multi_init called, r=256 v=256 Sat Nov 22 22:00:23 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0 Sat Nov 22 22:00:23 2014 IFCONFIG POOL LIST Sat Nov 22 22:00:23 2014 Initialization Sequence Completed
OpenVPN-клиент на CentOS 7
$ cp /usr/share/doc/openvpn-*/sample/sample-config-files/client.conf /etc/openvpn $ chcon -u system_u /etc/openvpn/client.conf $ nano -w /etc/openvpn/client.conf client dev tun proto udp remote vpn.example.com 1194 resolv-retry infinite nobind ;user nobody ;group nobody persist-key persist-tun status /var/log/openvpn-status.log ca /etc/pki/tls/certs/ca-bundle.crt ;cert client.crt ;key client.key ;ns-cert-type server comp-lzo verb 3 auth-user-pass credentials.txt $ nano -w /etc/openvpn/credentials.txt username password $ chmod 0600 /etc/openvpn/credentials.txt $ chcon -u system_u /etc/openvpn/credentials.txt $ touch /var/log/openvpn-status.log $ restorecon -v /var/log/openvpn-status.log $ cd /etc/openvpn $ openvpn client.conf Sat Nov 22 22:57:37 2014 OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 14 2014 Sat Nov 22 22:57:37 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Sat Nov 22 22:57:37 2014 Socket Buffers: R=[212992->131072] S=[212992->131072] Sat Nov 22 22:57:37 2014 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Sat Nov 22 22:57:37 2014 UDPv4 link local: [undef] Sat Nov 22 22:57:37 2014 UDPv4 link remote: [AF_INET]192.168.0.1:1194 Sat Nov 22 22:57:38 2014 TLS: Initial packet from [AF_INET]192.168.0.1:1194, sid=0dc4cf7c d2ea1086 Sat Nov 22 22:57:38 2014 VERIFY OK: depth=2, C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority Sat Nov 22 22:57:38 2014 VERIFY OK: depth=1, C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 1 Primary Intermediate Server CA Sat Nov 22 22:57:38 2014 VERIFY OK: depth=0, C=RU, CN=vpn.example.com, emailAddress=hostmaster@example.com Sat Nov 22 22:57:38 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Nov 22 22:57:38 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sat Nov 22 22:57:38 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Nov 22 22:57:38 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sat Nov 22 22:57:38 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Sat Nov 22 22:57:38 2014 [vpn.example.com] Peer Connection Initiated with [AF_INET]192.168.0.1:1194 Sat Nov 22 22:57:40 2014 SENT CONTROL [vpn.example.com]: 'PUSH_REQUEST' (status=1) Sat Nov 22 22:57:40 2014 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.14 10.8.0.13' Sat Nov 22 22:57:40 2014 OPTIONS IMPORT: timers and/or timeouts modified Sat Nov 22 22:57:40 2014 OPTIONS IMPORT: --ifconfig/up options modified Sat Nov 22 22:57:40 2014 OPTIONS IMPORT: route options modified Sat Nov 22 22:57:40 2014 ROUTE_GATEWAY 192.168.255.1/255.255.255.0 IFACE=ens160 HWADDR=00:50:56:02:02:01 Sat Nov 22 22:57:40 2014 TUN/TAP device tun0 opened Sat Nov 22 22:57:40 2014 TUN/TAP TX queue length set to 100 Sat Nov 22 22:57:40 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Sat Nov 22 22:57:40 2014 /usr/sbin/ip link set dev tun0 up mtu 1500 Sat Nov 22 22:57:40 2014 /usr/sbin/ip addr add dev tun0 local 10.8.0.14 peer 10.8.0.13 Sat Nov 22 22:57:40 2014 /usr/sbin/ip route add 10.8.0.0/24 via 10.8.0.13 Sat Nov 22 22:57:40 2014 /usr/sbin/ip route add 10.8.0.1/32 via 10.8.0.13 Sat Nov 22 22:57:40 2014 Initialization Sequence Completed
В клиентском конфиге у меня есть строка:
ca /etc/pki/tls/certs/ca-bundle.crt
она означает что для проверки серверного SSL-сертификата я использую системные доверенные корневые сертификаты. Если у вас на OpenVPN-сервере используется какой-нибудь самоподписанный сертификат, то на клиентскую сторону необходимо будет скопировать сертификат центра сертификации и указать его в конфигурационном файле клиента, в строкеca
.
А строки «user nobody
» и «group nobody
» мы закомментировали из-за того, что если их оставить, то после завершения VPN-соединения, у клиента OpenVPN не хватит прав на то чтобы «убрать за собой». Он оставит маршруты и DNS-сервера изменёнными.
После успешного соединения, в логе на сервере мы видим следующее:
Sat Nov 22 23:02:52 2014 192.168.255.100:45852 TLS: Initial packet from [AF_INET]192.168.255.100:45852, sid=ea90195b 352f0a5b Sat Nov 22 23:02:53 2014 192.168.255.100:45852 PLUGIN_CALL: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0 Sat Nov 22 23:02:53 2014 192.168.255.100:45852 TLS: Username/Password authentication succeeded for username 'root' Sat Nov 22 23:02:53 2014 192.168.255.100:45852 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Nov 22 23:02:53 2014 192.168.255.100:45852 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sat Nov 22 23:02:53 2014 192.168.255.100:45852 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Nov 22 23:02:53 2014 192.168.255.100:45852 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sat Nov 22 23:02:53 2014 192.168.255.100:45852 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA Sat Nov 22 23:02:53 2014 192.168.255.100:45852 [] Peer Connection Initiated with [AF_INET]192.168.255.100:45852 Sat Nov 22 23:02:53 2014 192.168.255.100:45852 MULTI_sva: pool returned IPv4=10.8.0.22, IPv6=(Not enabled) Sat Nov 22 23:02:53 2014 192.168.255.100:45852 MULTI: Learn: 10.8.0.22 -> 192.168.0.100:45852 Sat Nov 22 23:02:53 2014 192.168.255.100:45852 MULTI: primary virtual IP for 192.168.0.100:45852: 10.8.0.22 Sat Nov 22 23:02:55 2014 192.168.255.100:45852 PUSH: Received control message: 'PUSH_REQUEST' Sat Nov 22 23:02:55 2014 192.168.255.100:45852 send_push_reply(): safe_cap=940 Sat Nov 22 23:02:55 2014 192.168.255.100:45852 SENT CONTROL [UNDEF]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.22 10.8.0.21' (status=1)
Имейте в виду, если в конфиг клиента прописать строку auth-nocache
при авторизации по логину и паролю, то после реконнекта логин с паролем не будет прочитан из файла, а их нужно будет ввести в консоли.
Клиент с сервером соединились, попробуем с клиентской стороны пропинговать IP-адрес сервера:
$ ping 10.8.0.1 -c 4 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. 64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=55.1 ms 64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=56.3 ms 64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=62.0 ms 64 bytes from 10.8.0.1: icmp_seq=4 ttl=64 time=58.2 ms --- 10.8.0.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 55.178/57.961/62.078/2.622 ms
Как видим, всё пингуется. Значит настройки и клиента, и сервера у нас корректные. Но лучше такими настройками не пользоваться, т.к. на клиентской стороне, в файле, у нас находятся системные имя пользователя и пароль в открытом виде. Использовать подобное можно непродолжительное время, только во время первоначальной настройки.
Настройка маскарадинга на серверной стороне
Для того чтобы клиенты выходили в мир через наш VPN, мы на стороне сервера должны настроить маскарадинг и проброс маршрута по умолчанию на клиента (имейте в виду, желательно пробросить ещё и DNS-сервер). Для этого сделаем следующее:
$ firewall-cmd --permanent --zone=trusted --add-interface=tun0 $ firewall-cmd --permanent --zone=trusted --add-masquerade $ firewall-cmd --reload $ nano -w /etc/openvpn/server.conf push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 10.8.0.1" $ cd /etc/openvpn $ openvpn server.conf
Имейте в виду, линуксовый клиент с настройками по умолчанию не меняет свои DNS-сервера при подключении к OpenVPN, чтобы это изменить сделайте на клиенте следующее:
$ mkdir /etc/openvpn/scripts/ $ restorecon -v /etc/openvpn/scripts/ $ cp -p /usr/share/doc/openvpn-*/contrib/pull-resolv-conf/client.{up,down} /etc/openvpn/scripts/ $ chmod a+x /etc/openvpn/scripts/client.{up,down} $ restorecon -v /etc/openvpn/scripts/client.{up,down} $ nano -w /etc/openvpn/client.conf up /etc/openvpn/scripts/client.up down /etc/openvpn/scripts/client.down script-security 2
Но, так же, имейте в виду, что если вы проталкиваете внешний адрес OpenVPN-сервера в качестве DNS, обращение к нему будет идти с внешнего адреса клиента. А если проталкиваете внутренний IP-адрес OpenVPN-сервера, то может возникнуть такая проблема, что локальный DNS-сервер не слушает 53-й порт на этом адресе. Если адрес появляется в системе после того как локальный DNS-сервер уже запущен – необходимо выполнить команду systemctl reload named-chroot.service
для того чтобы DNS-сервер прибиндился к появившимся в системе IP-адресам. Чтобы это автоматизировать, сделаем на сервере следующее:
$ nano -w /etc/openvpn/scripts/named-reload.sh #!/bin/sh /usr/bin/systemctl reload named-chroot.service $ chmod a+x /etc/openvpn/scripts/named-reload.sh $ restorecon -v /etc/openvpn/scripts/named-reload.sh $ nano -w /etc/openvpn/server.conf ;user nobody ;group nobody up /etc/openvpn/scripts/named-reload.sh down /etc/openvpn/scripts/named-reload.sh script-security 2
Настраиваем автозапуск OpenVPN
То как мы запускали OpenVPN годится только для тестов. Подготовим OpenVPN к нормальному запуску:
$ systemctl enable openvpn@server.service ln -s '/usr/lib/systemd/system/openvpn@.service' '/etc/systemd/system/multi-user.target.wants/openvpn@server.service'
Описатель server
означает что используется конфигурационный файл с именем server.conf
в папке /etc/openvpn
, в случае клиента, нужно выполнить следующую команду:
$ systemctl enable openvpn@client.service ln -s '/usr/lib/systemd/system/openvpn@.service' '/etc/systemd/system/multi-user.target.wants/openvpn@client.service'
Вообще можно запускать несколько разных сервисов OpenVPN на одной машине, главное чтобы были разные конфигурационные файлы, и чтобы не использовались одни и теже порты и IP-адреса.
Попробуем запустить OpenVPN-сервер:
$ systemctl start openvpn@server.service Job for openvpn@server.service failed. See 'systemctl status openvpn@server.service' and 'journalctl -xn' for details.
Как видим, сервис не запустился. Посмотрим из-за чего:
$ systemctl status openvpn@server.service openvpn@server.service - OpenVPN Robust And Highly Flexible Tunneling Application On server Loaded: loaded (/usr/lib/systemd/system/openvpn@.service; enabled) Active: failed (Result: exit-code) since Sun 2014-11-23 02:00:54 MSK; 8s ago Process: 20948 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=1/FAILURE) Nov 23 02:00:54 example.com openvpn[20948]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Nov 23 02:00:54 example.com openvpn[20948]: /usr/sbin/ip link set dev tun0 up mtu 1500 Nov 23 02:00:54 example.com openvpn[20948]: /usr/sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2 Nov 23 02:00:54 example.com openvpn[20948]: /etc/openvpn/scripts/named-reload.sh tun0 1500 1542 10.8.0.1 10.8.0.2 init Nov 23 02:00:54 example.com openvpn[20948]: /etc/openvpn/scripts/named-reload.sh: line 2: /usr/bin/systemctl: Permission denied Nov 23 02:00:54 example.com openvpn[20948]: WARNING: Failed running command (--up/--down): external program exited with error status: 126 Nov 23 02:00:54 example.com openvpn[20948]: Exiting due to fatal error Nov 23 02:00:54 example.com systemd[1]: openvpn@server.service: control process exited, code=exited status=1 Nov 23 02:00:54 example.com systemd[1]: Failed to start OpenVPN Robust And Highly Flexible Tunneling Application On server. Nov 23 02:00:54 example.com systemd[1]: Unit openvpn@server.service entered failed state.
Ага, интересно. Заглянем ещё в лог SELinux:
$ cat /var/log/audit/audit.log | grep AVC type=AVC msg=audit(1416697254.641:18838): avc: denied { execute } for pid=20955 comm="named-reload.sh" name="systemctl" dev="dm-1" ino=33597892 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file type=AVC msg=audit(1416697254.641:18839): avc: denied { getattr } for pid=20955 comm="named-reload.sh" path="/usr/bin/systemctl" dev="dm-1" ino=33597892 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file type=AVC msg=audit(1416697254.641:18840): avc: denied { getattr } for pid=20955 comm="named-reload.sh" path="/usr/bin/systemctl" dev="dm-1" ino=33597892 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file
Круть. Не хватает прав у OpenVPN на запуск скрипта. Дадим ему эти права и попробуем запустить сервис ещё раз:
$ setsebool -P openvpn_run_unconfined on $ systemctl start openvpn@server.service $ systemctl status openvpn@server.service openvpn@server.service - OpenVPN Robust And Highly Flexible Tunneling Application On server Loaded: loaded (/usr/lib/systemd/system/openvpn@.service; enabled) Active: active (running) since Sun 2014-11-23 03:44:12 MSK; 3s ago Process: 22125 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=0/SUCCESS) Main PID: 22140 (openvpn) CGroup: /system.slice/system-openvpn.slice/openvpn@server.service ├─22126 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --cd /etc/openvpn/ --config server.conf └─22140 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --cd /etc/openvpn/ --config server.conf Nov 23 03:44:12 example.com openvpn[22125]: /etc/openvpn/scripts/named-reload.sh tun0 1500 1542 10.8.0.1 10.8.0.2 init Nov 23 03:44:12 example.com openvpn[22125]: /usr/sbin/ip route add 10.8.0.0/24 via 10.8.0.2 Nov 23 03:44:12 example.com openvpn[22140]: UDPv4 link local (bound): [undef] Nov 23 03:44:12 example.com openvpn[22140]: UDPv4 link remote: [undef] Nov 23 03:44:12 example.com openvpn[22140]: MULTI: multi_init called, r=256 v=256 Nov 23 03:44:12 example.com openvpn[22140]: IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0 Nov 23 03:44:12 example.com openvpn[22140]: IFCONFIG POOL LIST Nov 23 03:44:12 example.com openvpn[22140]: Initialization Sequence Completed Nov 23 03:44:12 example.com systemd[1]: Started OpenVPN Robust And Highly Flexible Tunneling Application On server.
Теперь сервис запустился без ошибок.
А чуть позже я дополню пост описанием работы OpenVPN с сертификатами.
Петр Мамонтов
31.12.2014 - 16:37
Круто написано. Возник вопрос, можно как-нибудь избавиться от firewall-cmd —zone=trusted —add-interface=tun0?
Попробовал сделать так для доступа к samba:
firewall-cmd —permanent —zone=public —add-interface=tun0
firewall-cmd —permanent —add-service=samba
firewall-cmd —reload
Но не сработало. И сопутствующий вопрос, где можно посмотреть лог того что банит firewall-cmd (искал в /var/log, но там не нашел)? Чтобы разобраться детальнее с правилами, а не разрешать все сразу.
Wakko
31.12.2014 - 16:51
Может попробовать написать:
$ firewall-cmd —permanent —zone=public —add-service=samba
?
А лога как такового по умолчанию у firewall-cmd – нет. firewall-cmd – это по сути, просто обёртка над старым iptables’ом. Т.е. нужно сначала создать правило, мол логируем то-то и то-то, а потом уже глядеть что там в логах получилось. Можно попробовать написать что-нибудь типа:
$ firewall-cmd —add-rich-rule=’rule service name=samba log level=info’
А потом посмотреть что в логах появляется.
PS. А masquerade делаете?
Петр Мамонтов
01.01.2015 - 13:36
Использую обычный форвардинг между интерфейсами через net.ipv4.ip_forward = 1. Попробовал явно указать зону public, но это ничего не дало, так как она зона по умолчанию и все интерфейсы у меня в ней. rich-rule тоже не дал эффекта, хоть полное логирование включай и снимай еще дампы. Но я решил, пойди чуть другим путем, все таки запихнуть tun0 в trusted и запретить исходящие соединения на интерфейсе, который смотрит в локалку. Насколько понял это нетривиальная задача для FirewallD, так как не встречал ее в статьях о нем. Буду курить подробнее man. И конечно есть еще пара выходов DMZ и ACL на сетевом оборудовании.
P.S.: С праздниками вас.
Петр Мамонтов
01.01.2015 - 13:52
Дополню немного, так как коммент нельзя править, «запретить исходящие соединения на интерфейсе» — хотел этим сказать, что кроме запрета еще и разрешить на нужные адреса и порты серверов. Так как не нравится мне идея полностью открытой локалку, для пользователей извне с их завирусованными машинами и червями.
роман
04.03.2015 - 04:29
ну вот что вы за люди? вы думаете что мало опытный ит специалист после гуи или виндовс полезет конфиги через вим править? нет
он скачает гуи или перейдет на кде или гноме, да да, воткнет иксы на серверный линукс
максимум что возможно это поправить пару строчек в свойствах самбы на разрешение записи в папке или доработает fstab
поэтому гуи, гуи и веб интерфес
Wakko
04.03.2015 - 09:19
Прочитал и посмеялся. Не нужно всех равнять по себе! Очень много людей понимают что гуй на сервере — это первый шаг к тому что этот сервер станет частью чьего-нибудь ботнета. 🙂
Vladimir
25.08.2015 - 23:47
Всем привет. Подскажите плиз почему при выполнении:
[root@centos ~]# chcon -u system_u /etc/openvpn/server.conf
Получаю ошибку:
chcon: не удалось применить частичный контекст к не помеченному файлу «/etc/openvpn/server.conf»