Kali Linuxで突然ネット接続不可に。「Unable to connect」の原因とDNS設定による解決法

2025年10月22日

Kali Linuxを運用していると、昨日まで問題なくインターネットに接続できていたにもかかわらず、ある日突然Firefoxなどのブラウザで「Unable to connect（接続できません）」というエラーが表示されることがあります。

同じWi-Fiや有線LANに接続している他のPC（WindowsやmacOS）は問題なく通信できているのに、なぜかKali Linuxのマシンだけが接続できない…。

この記事では、このような典型的なネットワークトラブルについて、原因を切り分ける手順から、DNS設定を見直して解決するまでの具体的なプロセスを、実際に行ったトラブルシューティングの記録として詳しく解説いたします。

状況の確認：初期症状とpingテスト

まずは、ネットワークがどのレベルで問題を抱えているのかを切り分けるため、ターミナル（端末）を開き、代表的なIPアドレス（例：Googleが提供するパブリックDNSサーバー）へpingコマンドを実行してみます。

ping 8.8.8.8

この時、もし以下のような結果が得られた場合、状況は少し複雑です。

64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=20.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=21.0 ms
...
From 192.168.1.1 icmp_seq=5 Destination Net Unreachable

この結果は、「最初の数回はインターネット（8.8.8.8）まで到達できているが、すぐに接続が途切れ、ルーター（この例では192.168.1.1）から『到達不能』という応答が返ってきている」ことを示しています。

これは、Wi-Fiの接続が極端に不安定であるか、またはルーターが何らかの理由でKali Linuxからの通信を途中で遮断している可能性を示唆します。

設定の確認：ゲートウェイとDNSは正常か？

次に、Kali Linuxがネットワーク設定を正しく取得できているかを確認します。

1. デフォルトゲートウェイの確認

ip r（ip route）コマンドで、ルーティング（通信の出口）の設定を確認します。

$ ip r
default via 192.168.1.1 dev wlan0 proto dhcp src ...

default via 192.168.1.1と表示されていれば、デフォルトゲートウェイ（インターネットへの出口）としてルーター（192.168.1.1）が正しく設定されていることがわかります。

2. DNSサーバーの確認

cat /etc/resolv.confコマンドで、名前解決（例：www.google.comをIPアドレスに変換する）に使用するDNSサーバーの設定を確認します。

$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1

nameserver 192.168.1.1と表示されています。これは、「DNSサーバーとして、ルーター（192.168.1.1）を使用する」という設定です。

ここまでの設定は、一般的な家庭やオフィスのネットワーク環境においてごく標準的なものであり、一見すると何ら問題ないように見えます。

原因の切り分け：HTTP通信は通過できているか？

ping（ICMP通信）は不安定ながらも一部通るのに、なぜブラウザ（HTTP/HTTPS通信）は全く繋がらないのでしょうか。

ここで、aptコマンドやcurlコマンドを使い、HTTP通信のテストを試みます。

$ sudo apt-get update
Err:1 http://http.kali.org/kali kali-rolling InRelease
  Undetermined Error [IP: 192.168.1.1 80]

apt-get updateが失敗し、エラーメッセージ内にルーターのIPアドレス（192.168.1.1）が表示されました。これは奇妙な現象です。

さらにcurlコマンドで確認します。

$ curl -I http://google.com
HTTP/1.0 501 Not Implemented
Server: httpd
Date: Thu, 05 May 2025 10:30:00 GMT
X-FRAME-OPTIONS: SAMEORIGIN
Connection: close

この応答は、明らかにGoogleのサーバーからのものではありません。（本来であれば Server: gws や HTTP/2 200 OK などが返ってきます）

Server: httpdという応答内容から、これはルーター（192.168.1.1）自身が内蔵しているWebサーバーからの応答である可能性が極めて高いです。

ほぼ特定できた原因

これらの結果から、以下の状況が推測されます。

Kali LinuxはDNSサーバーとしてルーター（192.168.1.1）に名前解決を要求しています。
しかし、そのルーターが何らかの理由でDNSクエリを外部（インターネット）に中継（リレー）せず、すべてのHTTPリクエスト（aptやcurl）をルーター自身に向けてしまっています。
その結果、Kali Linuxはインターネット上のどのサイトにもアクセスできず、ルーターの内部Webサーバー（501 Not Implementedを返す）に接続してしまっていたのです。

解決策：DNSサーバーを手動で変更する

原因が「ルーターのDNS機能不全」にあるとほぼ特定できたため、ルーターに頼るのをやめ、信頼性の高いパブリックDNSサーバー（例：Google Public DNS）を直接参照するように設定を変更します。

1. `/etc/resolv.conf` を編集

nanoエディタなどで、DNS設定ファイルを管理者権限で開きます。

sudo nano /etc/resolv.conf

2. nanoエディタの操作（補足）

nanoの操作に慣れていない方向けの補足です。編集後、Ctrl + Xキーを押すと、画面下部に「Save modified buffer?（変更を保存しますか？）」と尋ねられます。 Yキー（Yes）を押すと、次に「File Name to Write: /etc/resolv.conf（書き込むファイル名）」と表示されます。これは変更せず、そのままEnterキーを押せば保存完了です。

3. DNSサーバーの記述を変更

ファイル内には、以下のような記述があるかもしれません。

# Generated by NetworkManager
nameserver 192.168.1.1
nameserver 240b:xxxx:xxxx:xx::x  <-- (例: IPv6のDNS)
nameserver 240b:xxxx:xxxx:yy::y  <-- (例: IPv6のDNS)

これらの行をすべて削除（または行頭に # を付けてコメントアウト）し、代わりに以下の2行を記述します。

nameserver 8.8.8.8
nameserver 8.8.4.4

8.8.8.8がメインのDNSサーバーです。
8.8.4.4は予備（サブ）のDNSサーバーです。8.8.8.8だけでも動作しますが、万が一の障害に備え、両方記述しておくことが推奨されます。

解決の確認

設定ファイルを保存した後、再度pingやcurlを試してみます。

$ ping www.google.com
PING www.google.com (142.250.xxx.xxx) 56(84) bytes of data.
64 bytes from nrt12s45-in-f14.1e100.net (142.250.xxx.xxx): icmp_seq=1 ttl=60 time=22.0 ms

$ curl -I http://google.com
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
...
Server: gws
...

今度はpingがGoogleのサーバー（142.250.xxx.xxx）に応答し、curlもGoogleのサーバー（Server: gws）から正常な応答が返ってきました。

sudo apt-get update も問題なく動作するようになり、無事にインターネット接続が回復しました。

なぜ昨日まで使えていたのに急に使えなくなったのか？

これは非常に多い疑問ですが、以下のようないくつかの理由が考えられます。

ルーター側の問題: ルーターが自動的なファームウェアアップデートや再起動を行った際、DNSリレー機能が停止・不安定になった可能性があります。
Kali側の問題: Kali Linuxはローリングリリースモデルを採用しているため、apt upgradeによってNetworkManagerなどの挙動が変わり、DNSの取得方法に影響が出た可能性も否定できません。
IPv6の影響: 元の設定にあったIPv6のDNS（240b:...など）が優先された結果、IPv4との通信に不整合が起き、不安定になった可能性も考えられます。

いずれにせよ、**根本的な原因は「ルーター（192.168.1.1）のDNS機能に依存していたこと」**であり、8.8.8.8を直接指定することで、その問題を回避（バイパス）したというのが今回の解決の筋道です。

補足：Google DNS (8.8.8.8) を使うデメリットやリスクは？

DNSサーバーをGoogleに変更することについて、セキュリティやプライバシーの懸念を持たれる方もいらっしゃるかもしれません。

プライバシー面のデメリット: 「あなたがどのWebサイト（ドメイン名）にアクセスしようとしたか」というDNSクエリの履歴は、Googleに送信されます。ただし、通信内容自体（HTTPSで暗号化されたデータ）がGoogleに見られるわけではありません。
ハッキングのリスク: 8.8.8.8 (Google Public DNS) は、世界で最もセキュアに運用されているDNSの一つです。これを使ったからといって、ハッキングされやすくなることはありません。むしろ、出所不明なDNSサーバーを指定する方が、偽のサイトに誘導される「DNSポイズニング」のリスクが高まります。
代替案: もしGoogleへのクエリ送信を懸念される場合は、同様に高速でセキュア、かつプライバシー保護を重視している1.1.1.1 (Cloudflare DNS) を利用するのも良い選択です。