Ubuntu24でTor Browserのダウンロードがダメな場合の、メイン６大対策・非常５大手段とは！？
WindowsからUbuntu24に切り替えた方にとって、Tor Browserのダウンロードの仕方は勝手が違います。下手すると、ダウンロードに失敗する方もいらっしゃるかも知れません。
その場合の対処法を以下にまとめました。
NetworkManagerをリロードしてもダウンロードに失敗した場合は？
上記リンクの１．１．の操作に失敗した場合は、次のように対処します。
１．デーモンやサービスの確認、systemd-resolvedの停止と無効化、ネットワークマネージャーの再起動
ネットワーク関連のデーモンやサービスが正常に動作しているか、ステータスのチェックをします。また、systemd-resolvedの干渉防止のために、/etc/resolv.confへの上書きを出来なくさせます。
sh
sudo systemctl status NetworkManager #ステータスチェック
sudo systemctl status systemd-resolved
sudo systemctl stop systemd-resolved #systemd-resolvedの干渉防止
sudo systemctl disable systemd-resolvedそうすると、このような画面が出ます。
owner@Linux-for-owner:~$ sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
Removed "/etc/systemd/system/sysinit.target.wants/systemd-resolved.service".
Removed "/etc/systemd/system/dbus-org.freedesktop.resolve1.service".
２．ping接続の確認
インターネットに正常に接続できるか確認します。ここで、グーグル、ルーター、IPv4のping接続をまとめて確認している理由は、後から結局確認しなければならなくなったとき、二度手間どころかかなりの手間になるからです。将棋でいう布石、搦手（からめて）、手筋、毒まんじゅうみたいなものです。
sh
ping -c 4 google.com
ping -c 4 8.8.8.8 #GoogleのパブリックDNS
ping -c 4 192.168.1.1 #通常のルーターのIPアドレス１
ping -c 4 192.168.0.1 #通常のルーターのIPアドレス２
ping -c 4 172.217.161.46 #IPv4アドレス。実は、④で取得している。うまくいくなら、このような画面が出ます。
owner@Linux-for-owner:~$ ping -c 4 google.com
PING google.com (142.251.42.206) 56(84) bytes of data.
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=1 ttl=55 time=15.1 ms
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=2 ttl=55 time=21.7 ms
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=3 ttl=55 time=16.6 ms
64 bytes from nrt12s47-in-f14.1e100.net (142.251.42.206): icmp_seq=4 ttl=55 time=15.1 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 15.053/17.094/21.704/2.729 ms
owner@Linux-for-owner:~$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=21.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=30.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=114 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=114 time=19.6 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 17.328/22.016/30.011/4.812 ms
そしたら、そのまま３．に進みます。ですが、このような出力が出たら、次の操作をしましょう。
owner@Linux-for-owner:~$ ping -c 4 google.com
PING google.com (2404:6800:4004:80f::200e) 56 data bytes
#80fの部分は80aや827など、他の値もあり得る
--- google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3054ms
#3054msは恐らく時間のこと
失敗した場合
２．１．ネットワーク接続の確認
有線LANまたはWi-Fiの接続状態を確認します。接続が切れている場合は再接続を試みましょう。
sh
nmcli device status問題がなければ３．に進みます。
ですが、有線モードなのにTor Browserのサーバーにアクセスできない、という方もいるかも知れません。
owner@Linux-for-owner:~$ nmcli device status
DEVICE TYPE STATE CONNECTION
enp9s0 ethernet 接続済み netplan-enp9s0
lo loopback 接続済み (外部) lo
wlp7s0 wifi 切断済み --
p2p-dev-wlp7s0 wifi-p2p 切断済み --
例えばこのような出力です。その場合は、次の操作に移りましょう。
２．２．ネットワークインターフェースの詳細とルーティングテーブルの確認
以下のコマンドで、各種IPアドレスの状態がどうなっているか確認をします。
sh
ip a #ネットワークインターフェースの状態を確認
ip a show enp9s0
ip route show２行目では、enp9s0のIPアドレスが正しいか確認します。状態がUPでinetというエントリーがあるかどうかです。
３行目では、default viaと続くエントリーがあり、ルーターのIPアドレスであることを確認します。
owner@Linux-for-owner:~$ ip a show enp9s0
2: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 70:85:c2:38:b5:c5 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.13/24 brd 192.168.0.255 scope global dynamic noprefixroute enp9s0
valid_lft 83665sec preferred_lft 83665sec
inet6 2405:1200:a14f:d800:9b9a:806d:925f:e69d/64 scope global temporary dynamic
valid_lft 602067sec preferred_lft 83577sec
inet6 2405:1200:a14f:d800:7285:c2ff:fe38:b5c5/64 scope global dynamic mngtmpaddr
valid_lft 604794sec preferred_lft 544314sec
inet6 fe80::7285:c2ff:fe38:b5c5/64 scope link
valid_lft forever preferred_lft forever
owner@Linux-for-owner:~$ ip route show
default via 192.168.0.1 dev enp9s0 proto dhcp src 192.168.0.13 metric 100
192.168.0.0/24 dev enp9s0 proto kernel scope link src 192.168.0.13 metric 100
例えば、上の太字のところを確認します。
３．DNS設定の確認と更新
次に、DNS設定を見てみます。GoogleのパブリックDNS（8.8.8.8および8.8.4.4）を使う設定であれば、問題ありません。
編集するファイルは、/etc/resolv.confと/etc/systemd/resolved.confです。
まず、ファイル確認をしたら後になって結局使えなかった、ということが無いよう、この段階で/etc/resolv.confを再作成します。
sh
sudo rm /etc/resolv.conf #削除
sudo nano /etc/resolv.conf #編集以下をファイルに追加します。
ini
nameserver 8.8.8.8
nameserver 8.8.4.4追加が終わったら、Ctrl+O（保存）⇛Enter（保存同意）⇛Ctrl+X（終了）を順に押します。
念の為、/etc/resolv.confが正しく設定されていることを確認します。その際、iniに上記があることを確認します。
sh
cat /etc/resolv.conf例えば、元のファイルはこのようになります。
owner@Linux-for-owner:~$ cat /etc/resolv.conf
# 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.
nameserver 127.0.0.53
options edns0 trust-ad
search tkota1.kt.home.ne.jp
これだと、nameserverが異なる上に、メモが長すぎて分かりづらいので、以下のようになっていれば正解です。
owner@Linux-for-owner:~$ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
本来は、元のnameserver 127.0.0.53のほうがいいのかも知れません。ですが、あとで結局修正作業をするくらいなら、今のうちに完全に直しておいたほうが、二度手間どころか膨大な手間が省けます。
/etc/systemd/resolved.confの編集もします。
sh
sudo nano /etc/systemd/resolved.conf以下をファイルに追加または変更します。また、`FallbackDNS` の項目も有効にします。
ini
[Resolve]
DNS=8.8.8.8 8.8.4.4
FallbackDNS=8.8.8.8 8.8.4.4終わり次第、Ctrl+O（保存）⇛Enter（保存同意）⇛Ctrl+X（終了）を順に押します。
この段階で、上記リンクの１．１．１．の再起動を試します。問題がなければ５．に進みます。
４．IPv4やIPv6の設定が正しいか確認
次のコマンドを使って、IPv4やIPv6の設定が正しいか確認しましょう。
sh
nmcli connection showIPv6の調子が悪い場合
４．１．tracerouteまたはtracepathで診断
`traceroute`または`tracepath`コマンドを使用して、パケットがどこで止まっているのかを確認します。
sh
sudo apt-get install traceroute #インストール
traceroute google.com #実行または
sh
sudo apt-get install iputils-tracepath #インストール
tracepath google.com #実行を入力しましょう。そうすると、このような画面が出ます。
owner@Linux-for-owner:~$ sudo apt-get install traceroute
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています... 完了
状態情報を読み取っています... 完了
以下のパッケージが新たにインストールされます:
traceroute
アップグレード: 0 個、新規インストール: 1 個、削除: 0 個、保留: 0 個。
60.5 kB のアーカイブを取得する必要があります。
この操作後に追加で 162 kB のディスク容量が消費されます。
取得:1 http://archive.ubuntu.com/ubuntu noble/universe amd64 traceroute amd64 1:2.1.5-1 [60.5 kB]
60.5 kB を 1秒 で取得しました (54.3 kB/s)
以前に未選択のパッケージ traceroute を選択しています。
(データベースを読み込んでいます ... 現在 226602 個のファイルとディレクトリがインストールされています。)
.../traceroute_1%3a2.1.5-1_amd64.deb を展開する準備をしています ...
traceroute (1:2.1.5-1) を展開しています...
traceroute (1:2.1.5-1) を設定しています ...
update-alternatives: /usr/bin/traceroute (traceroute) を提供するために自動モードで /usr/bin/traceroute.db を使います
update-alternatives: /usr/bin/traceroute6 (traceroute6) を提供するために自動モードで /usr/bin/traceroute6.db を使います
update-alternatives: /usr/bin/lft (lft) を提供するために自動モードで /usr/bin/lft.db を使います
update-alternatives: /usr/bin/traceproto (traceproto) を提供するために自動モードで /usr/bin/traceproto.db を使います
update-alternatives: /usr/sbin/tcptraceroute (tcptraceroute) を提供するために自動モードで /usr/sbin/tcptraceroute.db を使います
man-db (2.12.0-4build2) のトリガを処理しています ...
owner@Linux-for-owner:~$ traceroute google.com
traceroute to google.com (142.251.42.206), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 0.415 ms 0.389 ms 0.370 ms
2 100.86.192.1 (100.86.192.1) 15.107 ms 15.109 ms 15.316 ms
3 10.202.120.164 (10.202.120.164) 15.825 ms 15.866 ms 15.906 ms
4 10.84.9.19 (10.84.9.19) 15.036 ms 15.248 ms 15.052 ms
5 10.84.9.27 (10.84.9.27) 22.320 ms 10.84.9.28 (10.84.9.28) 15.585 ms 15.498 ms
6 10.1.220.89 (10.1.220.89) 15.786 ms 10.1.220.93 (10.1.220.93) 21.103 ms 21.020 ms
7 10.1.11.245 (10.1.11.245) 18.957 ms 10.1.11.241 (10.1.11.241) 16.107 ms 10.1.11.245 (10.1.11.245) 13.037 ms
8 nfgw6-be1.at-dc.zaq.ad.jp (220.152.46.118) 16.062 ms nfgw6-be2.at-dc.zaq.ad.jp (220.152.46.122) 16.322 ms nfgw5-be1.at-dc.zaq.ad.jp (220.152.46.110) 18.775 ms
9 142.250.167.52 (142.250.167.52) 18.811 ms 142.250.163.198 (142.250.163.198) 19.454 ms 21.221 ms
10 * * *
11 209.85.248.112 (209.85.248.112) 35.703 ms 142.251.251.0 (142.251.251.0) 14.660 ms 216.239.41.68 (216.239.41.68) 14.404 ms
12 108.170.248.192 (108.170.248.192) 17.094 ms 108.170.248.190 (108.170.248.190) 17.102 ms nrt12s47-in-f14.1e100.net (142.251.42.206) 19.123 ms
この場合、目的のホスト（`google.com`）への経路は正しく設定され、途中でパケットが到達していますが、`ping google.com`が失敗しているため、他の問題が存在することがわかるみたいです。
４．２．IPv6の無効化
IPv6経由でパケットの送信が行われている場合、その影響を排除するためにも、IPv6を無効にしてIPv4を優先して使用するように設定してみます。こうすることで、IPv6関連の設定や通信の不良により、Tor Browserのダウンロードが失敗するのを防ぐことができます。
sh
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1そうすると、このような画面が出ます。
owner@Linux-for-owner:~$ sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
４．３．無効化の永続化
IPv6の無効化を永続化すると、再起動後も設定が適用されたままになります。
sh
sudo nano /etc/sysctl.conf末尾に以下を追加します。
ini
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1追加後、Ctrl+O（保存）⇛Enter（保存同意）⇛Ctrl+X（終了）を順に押します。
次に、設定を反映させます。
sh
sudo sysctl -p２．をこの段階で試します。
５．Wi-Fiネットワークの認識確認
Wi-Fiに接続している場合は、ネットワークが正しく認識されているか確認してみましょう。信号が弱い場合や他の干渉（例えば電子レンジなど）がある場合、接続がうまくいかないことがあります。
６．ファイアウォール設定の確認
ファイアウォールとは、一種のセキュリティーです。そのファイアウォールが過剰に反応し、ウェブサイトへのアクセスをブロックしていないかも見てみましょう。
sh
sudo ufw status #ICMPパケットを遮断していないか確認
sudo ufw allow 443本命に加え、ポート４４３も許可し、アクセスできる手段を増やします。ちなみに、ufwは、Uncomplicated FireWallの略で、単純な操作でファイアウォールの管理操作を行うコマンドです。詳しくはこちらを参照したほうがいいかも知れません。
話を戻します。コマンド実行後、このような画面が出ます。
owner@Linux-for-owner:~$ sudo ufw status
状態: 非アクティブ
場合によってはファイアウォールの一時的な無効化をし、接続が改善されるか確認します。ただ、大切なデータを取り扱う場合は気をつけましょう。予めバックアップなどをするといいかも知れません。
sh
sudo ufw disableその場合、ルータの管理画面にアクセスし、ICMPパケット（ping）がブロックされていないかも確認しましょう。
終わり次第、上記リンクの１．１．１．の再起動から流れに沿って、続きの操作をします。
何度やってもダウンロードがうまく行かない場合は？
①．Proxy設定が正しいか確認
プロキシサーバー（直接インターネットサーバーを閲覧検索実行するのではなく、中継ハブを経由して使うためのサーバー）を使っている場合は、設定が正しいか確認します。
sh
export http_proxy=http://yourproxy:port
export https_proxy=https://yourproxy:port②．ホストファイルの確認
ホストファイルが無効なエントリで設定されていないことを確認しましょう。
sh
sudo nano /etc/hosts必要に応じて、以下の行のみが含まれていることを確認して、無効なエントリーを削除します。
ini
127.0.0.1 localhost
127.0.1.1 <your-machine-name>Ctrl+O⇛Enter⇛Ctrl+Xを順に押します。
③．DNSキャッシュのクリア
DNSキャッシュをクリアしてみます。
sh
sudo systemd-resolve –flush-caches④．ネットワークトラブルシューティング
こちらのコマンドでトラブルシューティングをしてみましょう。
sh
dig（またはnslookup） google.com例えば、このような画面が出ます。
owner@Linux-for-owner:~$ dig google.com
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45320
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 172.217.161.46
;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Sun Sep 15 11:42:05 JST 2024
;; MSG SIZE rcvd: 55
owner@Linux-for-owner:~$ nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.251.42.206
Name: google.com
Address: 2404:6800:4004:80a::200e
この出力により、`google.com`のIPアドレスが正しく取得されていることが判明し、`ping`によるパケット送信の問題を探ることになりました。
⑤．別のコンピューターやネットワークを試す
ここまできてうまく行かなければ、別のコンピュータまたはネットワークで今までの手順を試してみると、原因が分かるかも知れません。
⑥．ISPへの問い合わせ
ここまでやってだめなら、ISP（インターネットサービスプロバイダー）に問い合わせをし、一部の通信をフィルタリングしている可能性も含め、サービスが正常に稼働しているか確認してもらったほうがいいかも知れません。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？