よく分かりませんが、Ubuntu 22.04 とそのカーネルを更新して再起動すると、インターネットへのアクセスがブロックされます。ただし、ルーターの管理ページには接続してアクセスし、ログインすることはできます。
同じWi-Fiにある私のスマートフォンには問題はありません。
アップデート中にラップトップがブロックされるような何かが起こりましたか?
アップデート
現在、イーサネット ケーブルを持っていないため、イーサネットを使用していません。そのため、現時点ではコメントできません。
私の WiFi チップはコマンドに基づいています:
$ lspci -knn | grep Net -A2
02:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:02b1] (rev 73)
Subsystem: Intel Corporation Wireless-N 7260 [8086:4462]
Kernel driver in use: iwlwifi
アップデート2
$ ping 8.8.4.4宛先ホストに到達できません:
$ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
From 192.168.1.162 icmp_seq=1 Destination Host Unreachable
From 192.168.1.162 icmp_seq=2 Destination Host Unreachable
From 192.168.1.162 icmp_seq=3 Destination Host Unreachable
テザリング時にパケットが送信されているのがわかります。
また、テザリングの場合：
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.42.129 dev usb0 proto dhcp metric 100
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.42.0/24 dev usb0 proto kernel scope link src 192.168.42.167 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
$ dig google.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13107
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 285 IN A 142.250.196.46
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Nov 23 17:04:43 +0545 2022
;; MSG SIZE rcvd: 55
Wi-Fiのみの場合：
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
$ dig google.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45316
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 102 IN A 142.250.196.46
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Nov 23 17:12:16 +0545 2022
;; MSG SIZE rcvd: 55
若干の違いがあるようですip route show。
Wi-Fi を使用するとパケットがゲートウェイを通過できないようです (?) 。
アップデート3
ライブ CD を使用する場合、Wi-Fi は正常に動作します。
通常起動時に、モバイルホットスポットワイヤレスのみを使用してネットにアクセスできません。
現在の Ubuntu のワイヤレス設定に何か問題がありますか?
アップデート4
私考えるVirtualBox にブリッジがインストールされており、私は VirtualBox を定期的に使用しています。
答え1
maan81 は、この問題をルート テーブルに切り分けるという非常に良い仕事をしました。
- インストール ディスクを使用してテストした結果、原因としてハードウェアがすべて排除されました - スマート スタート。
- ワイヤレス ルーターに接続すると、wlan0 接続構成が検証されました。
非常に賢い 2 つの手順です。では、ワイヤレス ルーターに接続できるのに、インターネットへのトラフィックが接続できないのはなぜでしょうか?
この問題は maan81 のルート テーブルで明らかになります。
$ ip route show
default via 192.168.1.1 dev br0 proto static metric 100 linkdown
default via 192.168.0.1 dev wlan0 proto dhcp metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.109 metric 600
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.162 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
br0経由のルート（リンクダウン状態のためどこにも行かない）はwlan0ルート（600）よりもメトリック（100）が低い。これは、すべてのトラフィックで勝つことを意味する。を除外する192.168.0.1 サブネットにバインドされています。そのサブネットに直接インターフェイスがあるため、デフォルトのルーティングはそのトラフィックには適用されません。
ここの責任者は誰ですか?
最初に行うべきステップは、どのネットワーク マネージャーが担当しているかを判断することです。ほとんどの場合、NetworkManager が担当します。
残念なことに、maan81 と私は NetworkManager が動作していると想定してこの手順を省略し、再起動のたびにブリッジ br0 が再び表示され続けたため、2 日間も悩まされました。
# Determine network renderer
netplan get renderer
レンダラーがネットワークマネージャートラブルシューティング技術までスキップできます。
レンダラーがネットワーク化された、netplanを実行しており、すべての問題は/etc/netplan/*.yamlにあります。標準ネットプラン完全なドキュメントについては、ネットプラン以下に挙げるものは役に立つかもしれないが、ネットプランこの回答の範囲内で扱うには大きすぎる問題です。
maan81 は確かに netplan を実行しており、NetworkManager に戻すことを選択しました。
netplan から NetworkManager に戻す
以下は root として実行されます。cat...EOFコマンドは連続したブロックとして実行する必要があります。.yaml ファイルのインデントを間違えないように注意してください。netplan はそのようなことに敏感です。
mkdir /etc/netplan/old
mv /etc/netplan/*.yaml /etc/netplan/old
cat << 'EOF' > /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
EOF
netplan generate && netplan apply && shutdown -r now
これが、maan81 のネットワーク問題を最終的に解決したものです。以下は、この解決策に到達するために使用した「ツール」の一部です。
トラブルシューティング
ルートテーブルをバックアップする:
# Backup the route table
sudo ip route save > route.bin
# Recover the route table
sudo ip route restore < route.bin
ブリッジ操作:
# take bridge br0 down
sudo ip link set br0 down
# bring up bridge br0
sudo ip link set br0 up
# delete bridge br0 (requires bridge-utils)
sudo ip link set br0 down && sudo brctl delbr br0
接続メトリックを変更する
# list connections
nmcli connection
# list devices
nmcli device
# set connection metric # requires link dn/up to take effect
nmcli connection modify <name> ipv4.route-metric <metric>
デフォルトルートのブルートフォース上書き
# Delete the default routes
sudo ip route del default
# Recreate new route to wireless router IP
sudo ip route add default via 192.168.0.1 metric 50
まとめ：
プロフェッショナルの世界では、複数のデフォルト ルートを実行することは非常に悪い習慣だと考えられています。結局のところ、「複数」と「デフォルト」は矛盾した概念です。
ユーザーのデスクトップの場合、NetworkManager はこれを自動的に処理しますが、常に正しく処理されるとは限りません。アクティブなネットワーク インターフェイスが複数ある場合は、複数のデフォルト ルートが作成されます。その場合、メトリックによってインターネット トラフィックが流れる場所が決定されます。