우분투 22.04를 사용하고 있습니다. 내 컴퓨터는 Realm을 사용하여 회사 도메인에 가입되어 있습니다. 저는 Adsys를 사용하지 않습니다. PAM 구성은 Unix 및 SSS 인증에 사용됩니다.
사무실에 있거나 원격지에 있을 때는 도메인 사용자 sudo로 로그인하는 것이 빠르지만, VPN에 로그인할 때 sudo에서 비밀번호를 묻는 메시지를 표시하는 데 몇 분이 걸리는 경우가 있습니다. gdm 잠금 화면도 마찬가지입니다.
susudo로 로컬 계정을 사용하여 sudo tail -f -n 100 /var/log/auth.log문제가 발생했을 때 /var/log/auth( )를 모니터링하는 데 사용했습니다 .
나는 이것을 관찰했다:
Jul 27 08:23:53 nick-precision-7560 pkexec: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1666422094)
Jul 27 08:23:53 nick-precision-7560 pkexec[10341]: nick: Executing command [USER=root] [TTY=unknown] [CWD=/home/nick] [COMMAND=/usr/lib/update-notifier/package-system-locked]
Jul 27 08:25:46 nick-precision-7560 sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1666422094 euid=0 tty=/dev/pts/6 ruser=nick rhost= user=nick
Jul 27 08:25:47 nick-precision-7560 sudo: pam_sss(sudo:auth): authentication success; logname= uid=1666422094 euid=0 tty=/dev/pts/6 ruser=nick rhost= user=nick
Jul 27 08:25:47 nick-precision-7560 sudo: nick : TTY=pts/6 ; PWD=/home/nick ; USER=root ; COMMAND=/usr/bin/whoami
Jul 27 08:25:47 nick-precision-7560 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1666422094)
Jul 27 08:25:47 nick-precision-7560 sudo: pam_unix(sudo:session): session closed for user root
pkexec오랜 시간이 걸린 이번 작품도 마찬가지다.
비슷한 질문이 많이 있으며 허용되는 솔루션은 호스트 파일과 관련이 있습니다. VPN에 연결되어 있을 때만 발생하기 때문에 같은 문제는 아닌 것 같습니다. 나는 이것이 어떤 방식으로든 네임서버 및 LDAP와 관련이 있다고 의심합니다. FWIW는 아래와 같이 내 호스트 파일입니다.
127.0.0.1 localhost
127.0.1.1 nick-precision-7560 nick-precision-7560.companydomain.mycompany.com
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
이런 일이 일어나는 동안 모니터링 했는데 systemd-resolved로그에 아무 것도 표시되지 않았습니다. 흥미롭게도 resolvectl statusVPN에 로그인해도 변경되지 않을 것이라고 생각했습니다. 그런데 VPN에 로그인해 보니 /etc/resolve.conf아래와 같이 업데이트된 것을 볼 수 있습니다.
#@VPNC_GENERATED@ -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
options edns0 trust-ad
nameserver 10.3.1.140
nameserver 10.3.1.43
search . companydomain.mycompany.com
IT 부서에 연락했더니 사고 당시 내 IP의 트래픽이 여러 도메인 컨트롤러에 도달하는 것을 볼 수 있었고 방화벽 로그에서는 거부된 트래픽을 볼 수 없었습니다.
이 문제를 디버깅하기 위해 어디로 가야 할지 잘 모르겠습니다. 문제는 쉽게 재현되지 않습니다. 이는 도메인에 연결되어 있는 동안 오랫동안 로그인하지 않았거나 sudo를 사용하지 않은 경우에만 발생합니다. 그러나 때로는 그런 일이 일어날 것이라고 예상했는데 인증 로그에서 unix 인증이 실패하고 인증을 위해 pam_sss를 사용해야 한다는 것을 알 때도 그런 일은 일어나지 않습니다.
고쳐 쓰다: Wireshark를 실행하고 TUN 어댑터를 모니터링합니다. 결국 sudo 중단 중 하나가 발생했습니다. 로그를 확인해보니 DNS, LDAP, SMB 트래픽이 많이 보였습니다. 로그를 보면 인증에 Adsys를 사용하지 않는데도 Adsys가 계속 실행되고 있고 로그에 많은 네트워크 트래픽과 많은 메시지를 생성하는 반복적인 오류가 발생하고 있음을 알 수 있습니다. 상황이 개선되는지 확인하기 위해 Adsy를 제거했습니다. 적어도 문제를 찾으려면 네트워크 트래픽과 로그를 정리해야 한다고 생각합니다.
이 시점에서 나는 내 컴퓨터가 올바른 도메인 컨트롤러를 확인하고 통신하고 있으며 올바른 이름 서버를 사용하고 있음을 알고 있습니다.