Назад | Перейти на главную страницу

Невозможно подключиться к CentOS 7/8 Screen Sharing (VNC) через рабочий VPN

Как и большинство людей, мы - 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 правильно, но несколько советов:

  1. Отключено firewalld не означает, что у вас не установлен брандмауэр, т.е. netfilter может контролироваться iptables и nftables, так что вам, возможно, придется это проверить.
    $ iptables -nL
    $ nft list tables
  1. Всегда проверяйте имя PID / процесса при диагностике сетевых служб, т. Е. 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, так что это якобы не проблема.

Это называется режим двойного стека.