Как и большинство людей, мы - WFH. Устранять проблемы через чат / по телефону становится все труднее, поэтому мы хотели бы использовать функцию CentOS «Совместное использование экрана», которая поставляется вместе с ОС, чтобы персонал службы поддержки мог подключаться к пользовательскому компьютеру для помощи в решении их проблем. Персонал службы поддержки также будет использовать встроенный клиент vinagre
с участием VNC
выбран в качестве типа подключения.
Все пользователи подключены к VPN, которая настроена так, чтобы внутренние узлы могли взаимодействовать друг с другом. Мы можем пинговать другие хосты, просматривать запущенные ими службы и т. Д. Вот настройки общего доступа к экрану моей машины.
Когда я смотрю netstat, я вижу порт 5900
слушает tcp6
. Я считал, что проблема заключалась в том, что базовый сервер VNC прослушивал IPv6, когда интерфейс IPv4 каждого хоста установлен как соединение по умолчанию, но я помню, что где-то читал, что tcp6
карта подключений к tcp4
соединения, так что это якобы не проблема. Вот мой вывод netstat:
$ sudo netstat -nlt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:10391 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:29754 0.0.0.0:* LISTEN
tcp6 0 0 :::5355 :::* LISTEN
tcp6 0 0 :::5900 :::* LISTEN
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 ::1:631 :::* LISTEN
tcp6 0 0 :::9090 :::* LISTEN
Я считал, что это брандмауэр, но и моя машина, и клиентская машина firewalld
отключен.
Вот результат nmcli
чтобы показать настройки Wired Connection 1
enp57s0u1: connected to Wired connection 1
"Realtek RTL8153"
ethernet (r8152), 8C:04:BA:67:52:16, hw, mtu 1500
ip4 default
inet4 192.168.1.123/24
route4 0.0.0.0/0
route4 192.168.1.0/24
inet6 fe80::xxxx:xxxx:xxxx:xxxx/64
route6 fe80::/64
route6 ff00::/8
Наконец, я протестировал включение SSH, и это сработало. Пользователи смогли подключиться, и им было предложено пройти аутентификацию (мы не позволяли им входить в систему). Это наводит меня на мысль, что проблема связана с самим базовым сервером VNC, возможно, что-то связано с тем, что он слушает tcp6
выше?
Есть идеи, в чем может быть проблема?
Проверка netstat
и firewalld
правильно, но несколько советов:
firewalld
не означает, что у вас не установлен брандмауэр, т.е. netfilter
может контролироваться iptables
и nftables
, так что вам, возможно, придется это проверить. $ iptables -nL
$ nft list tables
netstat -nltp
или ss -nltp
. Если что-то пойдет не так, вы всегда можете проверить журналы и конфигурации указанной службы.Если вы можете добавить команды iptables, чтобы разрешить 5900
Должно быть что-то вроде
$ iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT
$ iptables -A INPUT -p udp -m state --state NEW -m udp --dport 5900 -j ACCEPT
если вы используете nftables
, вы можете сделать что-то вроде
$ nft add table inet t_gnome_vnc
$ nft add chain inet t_gnome_vnc c_input
$ nft add rule inet t_gnome_vnc c_input tcp dport 5900 accept
$ nft add rule inet t_gnome_vnc c_input udp dport 5900 accept
PS:
Я помню, как где-то читал, что соединения tcp6 отображаются в соединениях tcp4, так что это якобы не проблема.
Это называется режим двойного стека.