この記事で分かること

Wi-Fiには接続できているのに、社内のネットワーク共有フォルダやイントラネットにアクセスできない場合、問題の原因を物理層から論理層まで段階的に特定し解決するための具体的な手順を解説します。単なる接続状態の確認だけでなく、ネットワークの仕組みや設定の違いを理解しながらトラブルシュートをすることで、再発防止や効率的な現場対応が可能になります。この記事では、実際の現場で使えるコマンド例やありがちなミス、注意すべきポイントも細かく説明しているため、これを読めば次に何をどう確かめるべきかが明確になります。

1. Wi-Fi接続ができている状態でも通信できない理由とは？

Wi-Fi接続が確立している状態は、無線LANの電波が端末とアクセスポイント（AP）間で正しく通信できていることを意味します。しかし、ここで重要なのは”Wi-Fiに接続できている”ことと”社内ネットワークのリソースにアクセスできている”ことは別問題だという点です。Wi-Fiはあくまで物理層とリンク層の無線接続が確立しているだけで、その上位のIP層やルーティング、ファイアウォール、認証サーバーなど多層的な仕組みを介してネットワークアクセスが成立します。

たとえば、次のような原因が考えられます：

  • 端末のIPアドレスが誤っているか取得できていない（無線接続はあってもDHCPサーバーとの通信障害）
  • アクセスポイントから社内ネットワークへの接続障害やVLAN設定不整合
  • ルーティング設定の誤りやデフォルトゲートウェイの不在
  • ファイアウォール・ACLによる通信遮断
  • DNS設定の間違いや名前解決の失敗

このため、物理的な”Wi-Fi接続済み”という状態に安心せず階層的に診断を進める必要があります。

2. 物理層とリンク層の基本確認：APおよび関連機器の接続状況の詳細確認

Wi-Fiは無線接続ですが、アクセスポイント（AP）がきちんと社内ネットワークのスイッチやルータに接続され、正常に動作しているかを確認することが最も基本かつ重要なステップです。APが社内ネットワークに接続されていなければ、端末はAPまで無線接続できてもネットワークを越えられません。

  • APの管理情報確認: APの管理コンソールやWebインターフェースで、リンク状態（Link Up/Down）、CPU・メモリ使用率、エラーパケット数、再起動履歴を詳細にチェックします。異常があればファームウェアの問題やハード故障の可能性も考慮。
  • スイッチポートの状態のコマンド確認（例：Ciscoの場合）:  
    show interface status
show interface <ポート名>
show interfaces counters errors

    リンクアップしているか、エラー発生が多くないかを細かく確認します。エラーが多ければケーブル不良やポートの物理問題を疑います。

  • 物理ケーブルと光モジュールの点検: ケーブルの断線、接続不良（緩み、コネクタ腐食）、光ファイバの清掃などを現場で点検。また、ケーブルテスターやトーンジェネレータ使用で正しい配線かどうか確認します。
  • APの電源供給の確認: PoE給電不良や電源アダプタの故障もAPの不安定動作の原因となるため、LED状態確認や電圧チェックも行いましょう。

これらを体系的にチェックすることで、物理層・リンク層の障害かどうかを確実に切り分けられます。ここでミスを見逃すと上位階層の調査に時間がかかり現場対応が長引きます。

3. 端末側ネットワーク設定の詳細チェックと注意点

AP側が正常であることを確認したら、端末のIP層設定を念入りに確認しましょう。設定ミスや取得失敗は頻繁にある問題です。

IPアドレスとサブネットマスクの正確な確認

IPアドレスは社内ネットワーク（例：192.168.x.x/24など）の正しい範囲に入っていることが重要です。DHCPサーバーから正しく取得できているか、固定IP設定で間違いがないかを以下のコマンドで確認してください。

Windows:

ipconfig /all

Linux/macOS:

ip addr show  または ifconfig

IPアドレスが169.254.x.xのようなAPIPA(自動プライベートIP)の場合、DHCPサーバーからIPを取得できておらず、これが直接の障害原因です。

デフォルトゲートウェイの設定確認と動作検証

ゲートウェイは端末から外部ネットワークに出るルータのIPアドレスです。ここが欠落または誤っていると通信が成立しません。設定をコマンドで確認したら、pingで応答を見ることも有効です。

Windows:

route print  （既定ルートの確認）

Linux/macOS:

ip route show
netstat -rn

設定されたゲートウェイにpingを打ち、応答がない場合、機器の接続問題かルーティング上の制限が考えられます。

DNSサーバー設定の詳細確認とトラブルシューティング

社内リソースの多くは名前解決（DNS）でアクセスしているため、DNS設定の誤りは致命的です。DNSサーバーIPが正しいかは以下で確認。場合によってはキャッシュが古いこともあるのでクリアも実施しましょう。

Windows:

ipconfig /all
ipconfig /flushdns

Linux/macOS:

cat /etc/resolv.conf
sudo systemd-resolve --flush-caches　（systemd使用時）

DNS解決ができているかは、例えば社内URL（ホスト名）をpingやnslookup、digコマンドで試してみるとよいです。

4. ネットワーク疎通検査とルーティング経路の詳細解析

設定されたIPとゲートウェイが正しくとも、ネットワーク経路に問題がある場合もあります。以下の手順で端末から社内ネットワーク内の各ポイントへの通信可否を段階的に調べます。

デフォルトゲートウェイ到達性のpingテスト

端末からデフォルトゲートウェイIPへpingを試みてください。応答があればL2以上は正常である可能性が高いですが、応答がなければ物理層・リンク層の再確認やAPの問題が疑われます。

Windows/Linux/macOS共通：

ping <デフォルトゲートウェイのIP>

社内リソースへの経路トレース

pingできないリソースについてはtraceroute（Windowsはtracert）を利用し、経路上のどのポイントで障害が起きているか確認します。

Windows:

tracert <アクセス先IP>

Linux/macOS:

traceroute <アクセス先IP>

途中の機器で応答が途切れている場合、その機器のACL設定やルーティングテーブルを管理者に確認依頼しましょう。たとえば、誤ったVLAN設定やファイアウォールポリシーで通信が遮断されていることがあります。

5. 社内ファイアウォール・セキュリティポリシーの詳細確認と検証手順

Wi-Fiから社内ネットワークにアクセスできない大きな要因の一つは、ファイアウォールやネットワーク機器のアクセス制御リスト（ACL）による通信ブロックです。これらはSSIDごと・VLANごと・端末IPごとに異なる通信ポリシーが設定されることが一般的です。

  • 端末IPの通信ログをファイアウォールで確認する:
    通信拒否ログがないか、対象の端末のIPアドレスをフィルタして検索します。FortiGate、Cisco ASA、Juniper SRXなど使用機種に応じてログ取得方法を熟知しておくべきです。
  • ライブパケットトレース（例：FortiGateの diagnose debug flow）:
    該当端末が社内リソースに通信を試みる際のパケット通過経路をリアルタイム監視し、どのポリシーで止まっているか明確に特定します。この操作は管理者権限が必要で慎重に行う必要があります。
  • SSIDとVLANの正しい紐づけ確認:
    社内Wi-Fiは通常、複数SSIDを用いて利用者属性別にVLANを分ける運用が多くあります。端末が想定外のSSIDやVLANに接続していると、意図しないファイアウォールルールが適用されアクセス不可になることがよくあります。AP管理画面とスイッチ設定を見て、VLANタグ付けの整合性を必ず確認してください。

これらを把握していないと不要な再設定や混乱を招くため、現場のネットワーク構成文書や設定マニュアルを熟読し、必要に応じてネットワーク管理者と連携をとりましょう。

6. ありがちな失敗と注意すべきポイント

  • APのSSID設定を間違えたままトラブルシュートを開始する: SSIDのVLAN割当を誤認している事例が多く、調査を長引かせます。
  • 端末側設定を毎回リフレッシュしない: IP再取得（DHCPリース更新）やDNSキャッシュクリアをせず、古い情報のまま調査すると原因特定が困難。
  • pingでの疎通テストのみで解決したと勘違いする: pingはICMPなので、ファイアウォール等でブロックされてもICMPパケットだけが遮断されるケースがあり注意が必要。
  • ネットワーク管理者への早期相談を怠る: 自分だけで解決できない場合、無理に操作せず速やかに連絡しましょう。

7. まとめと次に取るべき具体的対応ステップ

Wi-Fi接続は成功しているのに社内リソースにアクセスできない問題は、物理層から上位アプリケーション層まで複数階層での検証が不可欠です。以下のフローを順番に実施し、原因の範囲を着実に絞り込んでください。

  1. 物理層・リンク層の確認: APの状態、スイッチポートの動作、ケーブル物理状態、電源供給を現場で徹底してチェックし不具合を排除。
  2. 端末のネットワーク設定詳細確認: IPアドレス・サブネットマスク・デフォルトゲートウェイ・DNSの設定状況をコマンドで検証し、誤りや取得失敗を解消。
  3. ネットワーク疎通検査: pingでゲートウェイおよびリソースIPの応答テスト、tracerouteで通信経路の途中で止まっていないか詳細に確認。
  4. ファイアウォール・ACL・SSIDとVLANの整合性確認: 端末IPのログ分析・パケットトレースを実施し、通信ポリシーによる遮断や誤設定を特定して修正。
  5. 必要に応じてネットワーク管理者への連絡: 現場で解決できない場合は詳細ログやトレース結果を提出し、設定の再確認や改修依頼を行う。

これらの手順を丁寧に実施すれば、「Wi-Fi接続はできるのに社内ネットワークにアクセスできない」問題を迅速かつ確実に解決できるようになります。問題の全体像理解が進み、トラブル時の現場対応能力も格段に向上するでしょう。

関連記事