Published on

繋がらないときの判断表 — Proxmox 構築で踏んだネットワーク切り分け

Authors
  • avatar
    Name
    muzzledskr
    Twitter

仕事中に開く用。症状から次に打つコマンドを最短で決めるためのもので、network の教科書ではない。 2026-07-19 の Proxmox 構築で実際に踏んだ切り分けが土台。一般論の部分は明示する。

最初に決める2つ

これで打つコマンドが変わる。ここを決めずにコマンドを打ち始めると遠回りする。

Q1. サーバー側のコンソールに触れるか？（物理・IPMI・別経路の SSH）

  • 触れる → 下から順に見る（後述「サーバー側」）。原因特定は速い
  • 触れない → クライアント側の症状から推測するしかない（後述「クライアント側」）。推測の精度が落ちるので、断定を急がない

Q2. クライアントとサーバーは同じ L2 か？

  • 同一 LAN → ARP が使える。ping の失敗の仕方が情報になる
  • ルータ越し / VPN 越し → ARP は効かない。「宛先ホストに到達できません」の意味が変わる

クライアント側：症状から読む

主力コマンド

Test-NetConnection -ComputerName <host> -Port <port> -InformationLevel Detailed

ping と telnet を1回で兼ねる。まずこれ。結果の読み方：

出力意味次の一手
TcpTestSucceeded : Trueサーバー側は正常クライアント側を疑う。URL のスキーム・ポート・プロキシ・証明書
PingSucceeded: True / TcpTestSucceeded: Falseホストはいる。そのポートが閉じているサーバーで ss -tlnp。サービス停止 or FW or バインドアドレス
DestinationHostUnreachableARP すら解決できていない（同一 LAN の場合）ホストが LAN に出ていない。リンク・IP 設定・電源を疑う
タイムアウト（応答なし）経路上でドロップFW / ルーティング / 別セグメント

ping の結果を誤読しない

同一 LAN で存在しないアドレスを ping すると、こう返る：

192.168.1.75 からの応答: 宛先ホストに到達できません。
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)

「損失 0%」は成功ではない。 返ってきた 4 つは echo 応答ではなく、送信元自身（.75）が生成した ICMP host unreachable。統計だけ見ると成功に見えるので注意。

判別法：応答元の IP が 自分のアドレス なら失敗。相手のアドレスなら成功。

名前で繋がらないときは、まず IP で試す

Resolve-DnsName <name>
  • 解決しない → 名前解決の問題。到達性とは別。hosts / DNS サーバ / サーチドメインを見る
  • 解決するが繋がらない → 名前は無関係。到達性の問題として切り分け直す

今回の pve.home.arpa はこれ。その名前を知っているのはサーバー自身だけで、LAN の DNS には登録されていなかった。ホスト名を設定した ≠ 名前で引ける。

サーバー側：下から順に見る

触れるなら、上の層から調べるのは時間の無駄。下が壊れていたら上は必ず壊れて見える。

1. リンクは上がっているか（ここが最優先）

ip a
ip link

NO-CARRIER または state DOWN が出ていたら、それ以上コンフィグを読んでも意味がない。 ケーブル・ポート・スイッチ側の問題。

今回の実例：

2: nic0:  <NO-CARRIER,BROADCAST,MULTICAST,UP> ... state DOWN
3: vmbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> ... state DOWN
      inet 192.168.1.240/24 scope global vmbr0

IP 設定は完全に正しかった。 それでも届かない。ip r にも痕跡が出る：

default via 192.168.1.1 dev vmbr0 proto kernel onlink linkdown
                                                    ^^^^^^^^

→ 設定が正しいことと、通信できることは別。

2. L3 で出られるか

ip r                      # default route はあるか
ping -c 3 <gateway>       # ゲートウェイに届くか
ping -c 3 1.1.1.1         # 外に出られるか（DNS 抜きで）

ゲートウェイに届かないなら、その先を調べる意味はない。

3. サービスは待ち受けているか

ss -tlnp | grep <port>

見るポイントは2つ。

  • そもそも LISTEN しているか — していなければサービス停止。systemctl status / journalctl -u <name>
  • バインドアドレス — 127.0.0.1:8006 ならループバックのみで、外からは永久に繋がらない。0.0.0.0:* や *:* なら全インターフェース

バインドアドレスの見落としは、「サービスは動いているのに繋がらない」の典型。（※これは今回踏んでいない。一般論）

4. アプリ層

curl -vk https://localhost:8006/     # サーバー自身から。-k で証明書を無視

サーバー自身から通ってクライアントから通らないなら、間（FW・経路）の問題。

Tailscale が絡むとき

tailscale status        # 相手ノードが一覧にいるか、active か
tailscale ping <host>   # tailnet 経路で届くか。direct か DERP 経由かも分かる
tailscale netcheck      # 自分側の NAT 状況

同一 LAN にいるときの落とし穴

tailscale status にこう出ることがある：

100.85.64.57   pve   linux   active; direct 192.168.1.240:41641

direct <LAN の IP> は、同一 LAN にいるので最短経路を選んでいるだけ。正常な最適化だが、この状態で疎通確認しても tailnet 越しの到達性を検証したことにならない。

正しい検証：

  • 名前（MagicDNS）でアクセスする。IP 直打ちは検証にならない
  • 最終確認は別ネットワークから。スマホなら Wi-Fi を切ってモバイル回線

「引っ越し先から繋がるか」を実家の Wi-Fi で確認しても何も分からない。そしてそれが判明するのは引っ越した後。

一度の失敗で結論を出さない

Tailscale は接続確立中に一時的に失敗する。今回、Test-NetConnection が一度 False を返した直後の再試行で疎通した。最低2回試す。

誤読しやすいシグナル

見えるもの実は
ping 損失 0%失敗のことがある（応答元が自分の IP なら host unreachable）
SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした成功。自己署名証明書に対する正常な反応。名前解決・経路・サービス応答が全部通っている
curl: (60) SSL certificate problem同上。到達はしている
Connection refusedホストは生きている。サービスが落ちているだけ。到達性の問題ではない
No route to hostL3 で経路がない。FW の DROP でも出る
NO-CARRIER物理層。これが出ていたら上の層を読む意味はない

TLS エラーを「失敗」と読んで引き返さない。 証明書の検証は到達した後に起きる処理なので、エラーが出た時点で到達は証明されている。

原因は1つとは限らない

今回の「Web UI に繋がらない」は3つ同時だった。

  1. LAN ケーブルが繋がっておらず NO-CARRIER（主因）
  2. http:// のポート 80 でアクセスしていた（正しくは https://...:8006）
  3. pve.home.arpa が LAN の DNS に存在しない

1 つ直しても症状が変わらないので、「この修正は間違いだった」と誤判断しやすい。これが切り分けを難しくする本体。

対策：下の層から潰して、各層で「ここは正常」を確定させてから上に進む。 症状が消えたかどうかを判断基準にしない。

最短ルート（迷ったらこれ）

1. Test-NetConnection -Port          → サーバー側/クライアント側の切り分け
2. サーバーに触れる？
   Yes → ip a（NO-CARRIER?）→ ip r → ping gw → ss -tlnp
   No  → Resolve-DnsName → IP 直打ちで再試行 → ポート番号とスキームを確認
3. 名前で駄目、IP で通る          → DNS の問題
4. IP で駄目、TCP タイムアウト     → 経路 / FW
5. TCP 通る、アプリで駄目          → スキーム・ポート・証明書
Discuss on Twitter • View on GitHub