Ubuntu 22.04でVPNに接続するとsudoに時間がかかる

Ubuntu 22.04でVPNに接続するとsudoに時間がかかる

Ubuntu 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の中断の1つが発生しました。ログを確認してみると、DNS、LDAP、SMBトラフィックがたくさん見えました。ログを見ると、認証に Adsys を使用していなくても Adsys が実行され続けており、ログに多くのネットワーク トラフィックと多くのメッセージを生成する繰り返しエラーが発生していることがわかります。状況が改善されるかどうかを確認するために、Adsyを削除しました。少なくとも問題を見つけるには、ネットワークトラフィックとログをクリーンアップする必要があると思います。

この時点で、私のコンピュータが正しいドメインコントローラを確認して通信しており、正しいネームサーバーを使用していることを知っています。

ベストアンサー1

おすすめ記事