深夜2時の接続の壁
深夜、本番ノードに重要なホットフィックスを適用しようとしているとき、SSHターミナルが応答を止めます。パスワード入力画面の代わりに、無慈悲な拒絶メッセージが表示されます：
ssh: connect to host 192.168.1.100 port 22: No route to host
このエラーはよく誤解されます。サーバーには到達できるもののサービスが動いていない「Connection refused」とは異なります。「No route to host」は、ネットワークスタック内でのより深刻な断絶を意味します。キーボードとサーバーの間のどこかで、デバイスが「目的地に到達できない」と能動的に報告しているのです。
障害箇所の切り分け
すぐにルーターを再起動したりIPアドレスを変更したりしたくなる誘惑を抑えましょう。パケットがどこで途絶えているのかを正確に特定する必要があります。ローカルマシンか、中継ルーターか、あるいはターゲットの内部セキュリティ設定でしょうか？
1. 基本的な接続確認
まずはシンプルなpingから始めましょう。セキュリティが強化されたサーバーはICMPリクエストを無視することも多いですが、応答があれば物理的および仮想的な配線に問題がないことが証明されます。
ping -c 4 192.168.1.100
応答の内容に注目してください。ターミナルに Destination Host Unreachable と表示される場合、ローカルマシンがどのゲートウェイを使えばいいか分かっていません。もし No route to host と表示されるなら、ファイアウォールから「通信禁止（Communication Prohibited）」パケットを受け取っている可能性が高いです。
2. ルーティングテーブルの確認
ip route show を使ってローカルの経路を確認します。自分のマシンが 192.168.1.0/24 サブネットをどのように処理すべきか把握しているか確認してください。
ip route show
ターゲットのサブネットを探します。もし 192.168.1.100 へのトラフィックが、管理用VPN（tun0 など）ではなく、パブリック向けのインターフェース（eth0 など）にデフォルト設定されている場合、パケットは決して届きません。
主な原因：ソフトウェアファイアウォール
多くの場合、このエラーはターゲット側のファイアウォール設定に起因します。Linuxのファイアウォールは通常、トラフィックを DROP（破棄）または REJECT（拒絶）のいずれかで処理します。DROP の場合はタイムアウトになりますが、REJECT の場合はクライアントに対して「経路が閉じている」ことを伝える小さなICMPパケットを返します。これがこのエラーメッセージの正体です。
RHEL/CentOS/Fedora (Firewalld) での修正
Red Hat系のシステムでは、firewalld がデフォルトですべてをブロックし、特定のサービスのみを許可していることがよくあります。これがボトルネックかどうかを確認するために、安全なネットワーク内で一時的にサービスを停止してみます：
sudo systemctl stop firewalld
もし即座にSSH接続ができるようになったら、ファイアウォールを再開し、明示的にポート22を許可します：
sudo systemctl start firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
Ubuntu/Debian (UFW) での修正
Ubuntuユーザーは、Uncomplicated Firewallの状態を確認してください：
sudo ufw status
ステータスが active であっても、リストにポート22が含まれていない場合は、以下のコマンドを実行してポートを開放します：
sudo ufw allow 22/tcp
sudo ufw reload
サブネットの罠
サブネットマスクの不一致は、通信の完全な途絶を招きます。以前、2枚のネットワークカードに重複する 10.0.0.0/24 サブネットが割り当てられていたサーバーのデバッグに3時間を費やしたことがあります。カーネルが混乱し、戻りのトラフィックを誤ったポートから送信しようとした結果、接続を試みる全員に「No route」エラーが返されていました。
プロのヒント： 静的IPを確定する前に、CIDRの計算を再確認しましょう。私はホストの範囲やブロードキャストアドレスを可視化するために、この サブネット計算機 を使っています。ブラウザで使える高速なツールで、単純なタイポがネットワーク全体の障害に発展するのを防いでくれます。
最終確認
コマンドが1つ成功したからといって、修正が完了したと思い込んではいけません。別のマシンやサブネットから nc (netcat) を使ってポートの状態を確認します：
nc -zv 192.168.1.100 22
接続に成功すると、次のように表示されます：
Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
重要なポイント
- Reject vs. Drop: 「No route to host」が表示される場合は、アクティブな
REJECTルールを探してください。タイムアウトになる場合はDROPルールを探します。 - 戻りパス: ファイアウォールで
ESTABLISHED,RELATEDトラフィックが許可されていることを確認してください。そうしないと、サーバーがあなたに応答を返すことができません。 - ログの確認: ターゲット側で
/var/log/syslogやjournalctl -u sshを確認してください。サービス自体が起動していないのであれば、ネットワーク経路の問題ではありません。 - VLANの不一致: VPN経由で接続している場合は、ローカルLANだけでなく、VPNゲートウェイの特定のIPレンジがファイアウォールで許可されているか確認してください。