ネットワーク運用や構築の現場で、意外と多いのが「同じVLAN内では通信できるのに、別VLANとは通信できない」というトラブルです。

VLANはネットワークを論理的に分割できる便利な仕組みですが、実際に運用してみると、ルーティング設定、タグ付け、デフォルトゲートウェイ、ACLなど、複数の要素が正しくそろっていないと簡単に通信不良が起こります。しかも厄介なのは、原因が一つとは限らないことです。L2スイッチの設定漏れだと思っていたら、実際はL3インターフェースのIPアドレス設定ミスだった、ということも珍しくありません。

現場でも「VLANを作っただけで通信できると思っていた」「trunk設定は入れたのに疎通しない」「片系だけ切り替わると通信できない」といった話は本当によくあります。こうした障害は、仕組みを理解していても、確認順序が整理できていないと長引きやすいです。

この記事では、VLAN間通信できないときにどこを確認すべきかを、初心者にもわかるように整理して解説します。単なる概要説明ではなく、なぜ通信できないのか、どこで詰まりやすいのか、どう確認し、どう直すのかまで順番にわかる内容にしています。WordPressにそのまま貼り付けやすいHTML形式で使えるようにまとめています。

VLAN間通信とは何か

VLAN間通信とは、異なるVLANに所属する端末同士が通信することです。たとえば、VLAN10にいるPCとVLAN20にいるサーバーが通信するケースがこれにあたります。

VLANはレイヤ2でネットワークを分割する仕組みです。そのため、異なるVLAN同士は、そのままでは通信できません。VLAN10とVLAN20が存在していても、単にネットワークが分かれているだけで、相互通信できる状態ではないということです。

この通信を可能にするには、ルータやL3スイッチによるルーティングが必要です。たとえば、L3スイッチ上にVLAN10用のSVIとVLAN20用のSVIを作成し、それぞれにIPアドレスを持たせることで、各VLANの端末はデフォルトゲートウェイ経由で別VLANへ通信できるようになります。

VLAN10: 192.168.10.0/24
GW    : 192.168.10.1

VLAN20: 192.168.20.0/24
GW    : 192.168.20.1

ここで大切なのは、VLANを作ることVLAN間通信を成立させることは別だという点です。現場ではここを誤解しているケースが意外と多く、VLAN定義とポート収容だけで作業を終えた結果、「同一VLANでは通信できるが、別VLANには届かない」という障害になります。

VLAN間通信できないときに最初に整理したい考え方

VLAN間通信トラブルでは、いきなりすべての設定を見直すより、まず「どの段階で通信が止まっているのか」を切り分けることが重要です。焦ってコンフィグ全体を見始めると、関係ない設定に時間を使いやすく、原因発見まで遠回りになります。

基本的には、まず端末が自分のVLAN内で正常に通信できているかを確認します。同一VLAN内ですら通信できないなら、問題はVLAN間通信以前にあります。アクセスポートのVLAN所属、リンクアップ状態、IPアドレス、サブネットマスク、ARP解決など、L2や基本的なL3設定を先に疑うべきです。

次に、端末からデフォルトゲートウェイへ到達できるかを確認します。別VLANへ出る通信は、必ず最初にデフォルトゲートウェイへ向かいます。ここへ到達できない場合は、端末の設定ミス、ポートのVLAN誤収容、trunk未設定などが有力です。

そのうえで、L3スイッチやルータに正しいインターフェース設定があるか、ルーティングが有効か、ACLやファイアウォールで止めていないかを確認します。実務では、端末 → アクセススイッチ → trunk → L3インターフェース → フィルタという順番で見ていくと、かなり効率よく原因を絞れます。

VLAN間通信できない主な原因

ルーティング設定が存在しない

もっとも基本的で、しかも意外と多いのがこのパターンです。異なるVLAN同士が通信するには、L3スイッチやルータでルーティングが有効になっていなければなりません。

ありがちなのは、VLAN10とVLAN20を作って各ポートを所属させたところで作業を終えてしまうケースです。この状態では、各VLAN内の通信はできても、VLANをまたぐ通信はできません。

L3スイッチであれば、SVIを作成し、それぞれにIPアドレスを付与し、必要に応じて ip routing を有効化します。ルータ・オン・ア・スティック構成であれば、物理インターフェース配下にサブインターフェースを作成し、802.1QタグとIPアドレスを設定する必要があります。

端末のデフォルトゲートウェイ設定ミス

端末側の設定ミスも非常によくあります。たとえば、VLAN10のPCに 192.168.10.50/24 を設定しているのに、デフォルトゲートウェイを 192.168.20.1 にしていたら、当然ながら正常に通信できません。

このケースがやっかいなのは、同一セグメント内の一部通信だけは成立することがある点です。そのため利用者からは、「同じ部署のPCにはつながるが、サーバーには届かない」「インターネットだけ出られない」といった中途半端な症状に見えます。

DHCP環境でも油断はできません。DHCPスコープの設定ミスや、VLANごとの配布内容の誤りがあると、複数端末に同じ問題が一斉に発生します。現場で端末が何台も同じ不具合を起こしている場合、個別端末ではなくDHCP側を疑うのが近道になることもあります。

アクセスポートのVLAN設定ミス

端末が接続されているスイッチポートが、想定したVLANに所属していないケースです。本来VLAN10に入れるべきポートがVLAN20に入っていれば、IPアドレスだけVLAN10のものを持った端末が、物理的にはVLAN20に接続されている状態になります。

この状態では、端末は自分が想定しているゲートウェイへ届かず、ARPも正しく解決できません。そのため「IP設定は合っていそうなのに疎通しない」という、切り分けしづらい障害になります。

スイッチ更改、配線変更、空きポートへの差し替えのあとに起きやすく、descriptionだけ信じて作業すると見落としやすいポイントです。現場でも、パッチが別ポートへ差し替わっていて、実は収容VLANが違っていたというケースは珍しくありません。

trunkポートで必要なVLANが通っていない

複数のスイッチをまたいでVLANを運ぶ構成では、trunk設定が正しくないと通信できません。特に見落としやすいのが、allowed VLANの設定漏れです。

たとえば、アクセススイッチ側ではVLAN20に端末が収容されていても、上位スイッチとのtrunkでVLAN20が許可されていなければ、そのVLANのトラフィックは上位へ届きません。この場合、同一スイッチ内では正常でも、別スイッチやL3スイッチにまたがる通信だけ失敗します。

また、native VLANの不一致も注意が必要です。タグ付き・タグなしの扱いが機器間でずれると、意図しないVLANへフレームが入ったり、CDPやLLDPの警告だけ出て本題の疎通不良が見えにくくなったりします。単純な設定漏れに見えても、機器間でL2の認識がずれている可能性があります。

SVIまたはサブインターフェースのIP設定ミス

L3スイッチやルータ側に設定したVLAN用インターフェースのIPアドレスやサブネットマスクが誤っているケースです。たとえば、本来 192.168.20.1/24 を設定すべきところを、192.168.200.1/24 にしていたり、端末は /24 なのにSVIは /25 になっていたりすると、端末側の設定が合っていても正常にルーティングできません。

また、SVIが administratively down のまま、あるいは対象VLANにアクティブなポートが存在せず protocol down になっていることもあります。設定が入っているだけで安心してしまい、実際にはインターフェースが機能していないケースは意外とあります。

ACLやファイアウォールで通信が拒否されている

VLAN間通信そのものは成立していても、ACLやセキュリティポリシーで止められている場合があります。特にサーバー系VLANや管理系VLANでは、意図的に通信制御している環境が多いため、疎通不良が単なる設定漏れとは限りません。

この場合、pingだけ通らないのか、TCPの特定ポートだけ通らないのか、全通信が止まるのかで見え方が変わります。「ネットワークがおかしい」と見えても、実際はセキュリティポリシーが正しく効いているだけということもあります。

そのため、L3疎通とアプリケーション疎通を分けて考えることが重要です。ICMPは拒否していてもTCP/443は許可している、あるいはその逆という構成も普通にあります。

冗長化構成やSTPの影響

STPのブロッキングや、スタック、MLAG、HAなど冗長化構成の不整合が原因になることもあります。特に構成変更直後は、片系だけVLAN設定が入っていない、片側だけtrunk許可VLANが違うといった問題が起こりがちです。

この手の障害は、普段は正常に見えても、経路切り替え時だけ急に通信できなくなることがあります。「昨日までは使えていた」という事実が、設定の正しさを保証しないのがネットワーク運用の難しいところです。片系停止試験やフェイルオーバーテストをして初めて発覚するケースも多く、平常時の疎通確認だけでは不十分なことがあります。

VLAN間通信できないときの確認手順

1. 同一VLAN内の通信を確認する

最初に確認したいのは、同じVLAN内の通信が正常かどうかです。別VLANに行けない前に、まず自分のセグメント内でゲートウェイに届くかを確認します。

ping 192.168.10.1

これが通らない場合、別VLAN以前に、端末が正しいVLANへ収容されていない可能性があります。その場合は、端末のIP設定、接続ポートのVLAN所属、リンク状態を優先して確認します。

同一VLAN内の別端末へ疎通確認できるなら、その情報も有効です。ゲートウェイには届かないが同一VLAN端末には届くのか、それとも両方届かないのかで、疑うべきポイントが変わってきます。

2. 端末のIPアドレスとデフォルトゲートウェイを確認する

Windowsなら ipconfig、Linuxなら ip addrip route を確認します。

ip addr
ip route

ここで確認したいのは、IPアドレスが想定VLANのセグメントに属しているか、サブネットマスクが正しいか、デフォルトゲートウェイが同一セグメント内にあるかの3点です。ここが崩れていると、ネットワーク機器側が正しくても通信できません。

実際の障害対応では、端末が固定IPで運用されているのか、DHCPで自動取得しているのかも重要です。固定IPなら個別設定ミス、DHCPならスコープやリレー設定も確認対象になります。

3. スイッチポートのVLAN所属を確認する

Cisco系の例であれば、以下のコマンドが基本です。

show vlan brief
show interfaces status
show running-config interface GigabitEthernet1/0/10

ここでは、対象ポートが本当に想定VLANに所属しているかを見ます。descriptionだけを信じるのではなく、実際の設定を確認することが大切です。配線変更後は特に要注意です。

また、shutdown状態やエラーディセーブル状態になっていないかも確認したいところです。VLAN設定だけ見て終わるのではなく、ポート自体が正常に動作しているかも合わせて見るべきです。

4. trunk設定を確認する

trunkが絡む場合は、許可VLANと動作状態を確認します。

show interfaces trunk
show running-config interface GigabitEthernet1/0/48

ここで、対象VLANがtrunkで通過できる状態かを見ます。allowed VLANに含まれていない、片側だけaccessになっている、native VLANが一致していないといった問題が見つかることがあります。

障害時には、片側だけを確認して安心しないことが重要です。trunkは対向も含めて1本なので、片側は正しくても、相手側でVLANが許可されていなければ意味がありません。現場では、上位側の設定変更だけ忘れていたというのはかなりありがちです。

5. L3インターフェースを確認する

L3スイッチならSVI、ルータならサブインターフェースを確認します。

show ip interface brief
show running-config interface Vlan10
show running-config interface Vlan20
show ip route

ここで確認するのは、IPアドレス、up/down状態、ルーティングの有効性です。SVIが down のままだと、ゲートウェイとして機能しません。

Cisco系L3スイッチなら、必要に応じて以下も確認します。

show running-config | include ip routing

単にインターフェースが存在するだけでなく、正しいマスクで正しいVLANに関連づいているかを見ることが重要です。特に似たセグメントが複数ある環境では、数字の打ち間違いが意外と多く、見落とすと長引きます。

6. ACLやポリシーを確認する

L3疎通がありそうなのに通信できない場合は、ACLやFWポリシーを見ます。

show access-lists
show running-config | section access-list
show ip interface Vlan20

インターフェースにACLが適用されていないか、どの方向に適用されているかを確認します。pingは通るが業務アプリだけ使えない場合は、ネットワークより上位の制御も疑うべきです。

アプリケーション単位の疎通確認も有効です。たとえばWeb系なら443番、SSHなら22番など、実際に使う通信を確認することで、ネットワーク障害とアクセス制御を切り分けやすくなります。

VLAN間通信トラブルで使いやすい設定例

L3スイッチでの基本例

vlan 10
 name USER_VLAN

vlan 20
 name SERVER_VLAN

interface Vlan10
 ip address 192.168.10.1 255.255.255.0
 no shutdown

interface Vlan20
 ip address 192.168.20.1 255.255.255.0
 no shutdown

ip routing

interface GigabitEthernet1/0/1
 switchport mode access
 switchport access vlan 10

interface GigabitEthernet1/0/2
 switchport mode access
 switchport access vlan 20

この構成では、VLAN10とVLAN20の端末は、それぞれ 192.168.10.1192.168.20.1 をデフォルトゲートウェイに設定すれば、相互通信できる状態になります。小規模から中規模環境でよく使われる、もっともわかりやすい形です。

trunkを使うときの基本例

interface GigabitEthernet1/0/48
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 10,20

機種によっては switchport trunk encapsulation dot1q が不要な場合もありますが、考え方は同じです。重要なのは、trunkで必要なVLANをきちんと通すことです。

本番環境では、allowed VLANを広く開けすぎると意図しないVLANまで通してしまうため、必要最小限で管理するのが基本です。ただし、変更時の追加漏れが起きやすくなるため、運用設計と変更手順をあわせて整えておく必要があります。

ルータ・オン・ア・スティックの基本例

interface GigabitEthernet0/0
 no shutdown

interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0

interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0

小規模環境では今でも使われる構成です。ただし、物理1本に通信が集中するため、帯域や冗長性の面では制約があります。端末数やトラフィックが増える環境では、L3スイッチ構成のほうが扱いやすい場面も多いです。

現場で特に多い見落としポイント

VLAN間通信トラブルでは、難しい機能よりも、むしろ基本的な設定の食い違いで詰まることが多いです。実際の現場で特に多いのは、端末のゲートウェイ設定ミス、trunkでのVLAN許可漏れ、片系だけ設定が違う冗長構成、ACLの存在を見落としているケースです。

特にやっかいなのは、「設定は入っているが、一部だけ違う」状態です。コンフィグを流し見すると正しそうに見えるのに、VLAN番号が1つだけ違う、サブネットマスクが片側だけ異なる、予備系だけallowed VLANが不足している、といった差分で止まっていることがあります。

以前、配線変更後にユーザー端末がつながらなくなったケースでも、最初はL3やFWを疑って確認していましたが、最後に調べたアクセススイッチのポートが別VLANに入っていたのが原因でした。高度な問題に見えても、結局は基本設定の食い違いだったというのは、ネットワーク障害では本当によくあります。

VLAN間通信トラブルを減らすための考え方

障害を減らすには、設定を入れること以上に、確認しやすい構成と運用にしておくことが大切です。

まず、VLAN番号、用途、サブネット、デフォルトゲートウェイ、収容スイッチ、trunk経路を一覧化しておくと、切り分けがかなり早くなります。「VLAN20は何用だったか」「ゲートウェイはいくつだったか」を毎回調べる運用だと、障害時に時間をロスします。

次に、trunkのallowed VLANを必要最小限にしつつ、変更時の反映漏れが起きないよう標準化しておくのが有効です。運用設計が曖昧だと、増設のたびにどこかで設定漏れが発生します。

また、ACLやFWポリシーは、どのVLAN間通信を許可・拒否しているのかを明文化しておくと、ネットワーク担当とサーバー担当の切り分けがしやすくなります。障害対応では「通すつもりだったのか、止めるつもりだったのか」が曖昧だと、それだけで調査時間が伸びます。

最後に、変更後は平常系だけでなく、冗長系や切り替え時も含めて確認するのが理想です。通常時だけ問題なくても、障害時にだけ通信できなくなる構成は実務では少なくありません。

VLAN間通信に関するよくあるQ&A

VLANを作成しただけでVLAN間通信はできますか

できません。VLANはレイヤ2でネットワークを分割する仕組みなので、別VLANへ通信するにはルータまたはL3スイッチによるルーティングが必要です。

同じVLAN内では通信できるのに別VLANだけ通信できないのはなぜですか

よくある原因は、デフォルトゲートウェイ設定ミス、SVI未設定、ip routing未有効化、trunkでVLAN未許可、ACLによる拒否です。同一VLAN内通信ができるなら、まずゲートウェイ到達性とL3設定を確認すると切り分けしやすくなります。

pingが通らない場合は必ずネットワーク障害ですか

必ずしもそうではありません。ACLやFWでICMPだけ拒否している場合もあります。pingだけで結論を出さず、必要なアプリケーションのポート疎通も確認することが大切です。

trunk設定で特に確認すべきポイントは何ですか

mode trunk、allowed VLAN、native VLAN、対向機器側の設定の4点は最低限確認したいところです。片側だけ正しくても通信は成立しません。

まとめ

VLAN間通信ができない原因は、単純なようでいて実際には複数の要素が絡みます。VLANを作成しただけでは通信できず、ルーティング、デフォルトゲートウェイ、アクセスポート、trunk、SVI、ACLなど、すべてが正しくかみ合って初めて別VLANへの通信が成立します。

障害対応で大切なのは、やみくもに設定を眺めることではなく、どこまで通信できていて、どこから先で止まっているのかを順番に確認することです。端末、アクセススイッチ、trunk、L3インターフェース、ACLの順に見ていけば、原因をかなり効率よく絞れます。

特に現場では、高度な機能よりも、VLAN誤収容、ゲートウェイ設定ミス、allowed VLAN漏れのような基本的なミスが原因になることが多いです。だからこそ、仕組みを理解したうえで、確認ポイントを型として持っておくことが重要です。

VLAN間通信トラブルは、慣れないうちは難しく感じやすいですが、確認すべき場所を順番に追えば必ず原因に近づけます。構築時も障害対応時も、「端末設定」「L2」「L3」「制御」の順で整理して見る癖をつけておくと、現場でかなり強くなれます。