初めてマネージドスイッチを買いました。TP-Link JetStream TL-SG3428Xです。

マネージドスイッチの最大の特徴は、ネットワークをVLANで分割できることです。この機能をとても楽しみにしていたのですが、実際にVLANを動かすまでには何時間もの試行錯誤が必要でした。

TP-LinkのVLANドキュメントは内容が不十分だと感じたので、誰かの役に立てばと思い、自分のメモを共有します。

背景

VLANをご存じない方は、Raid Owlによる解説動画が私のお気に入りです。とても分かりやすく説明されています。

タグ付きポート、アンタグポート、PVID

メーカーや機種によって、VLAN機能の呼び方は異なります。

TP-Linkのスイッチで押さえておきたい設定は次の3つです。

• タグ付きポート
• アンタグポート
• PVID

タグ付きポート

ポートをVLANにタグ付きポートとして追加すると、そのポートに接続された機器はそのVLANとの間でトラフィックを送受信できるようになります。

タグ付きポートでは、スイッチはパケットに付いたVLANタグをそのまま保持します。そのため、VLAN対応機器はタグ付きポートとしてVLANに追加します。VLAN対応機器とは、ファイアウォールや他のマネージドスイッチ、VLANに対応した無線アクセスポイントなどです。

例えば、ポート5をVLAN 10と20にタグ付きポートとして追加すると、スイッチはそのポートにVLANタグ10と20が付いたパケットを送ります。タグは除去されないので、ポート5の機器はVLANタグが付いたままパケットを受信します。許可されているのは10と20だけなので、それ以外のVLANタグが付いたパケットは届きません。

アンタグポート

ポートをVLANにアンタグポートとして追加した場合も、タグ付きポートと同様に、そのポートの機器はVLANとの間でトラフィックを送受信できます。違いは、スイッチがポートにパケットを渡す前にVLANタグを取り除く点です。

アンタグポートは、一般的なデスクトップPCやスキャナー、プリンターなど、VLANに対応していない機器向けです。接続先の機器がVLANを理解できないため、スイッチ側でタグを取り除きます。

例えば、ポート6をVLAN 10にアンタグポートとして追加すると、スイッチはVLANタグ10が付いたパケットをそのポートに送りますが、渡す前にタグを取り除きます。そのためポート6の機器は、タグなしのパケットを受信します。許可されているのはVLAN 10だけなので、他のVLANタグのパケットは届きません。

PVID

TP-Linkのスイッチでは、各ポートにPVID、すなわちポートVLAN識別子が設定されています。接続された機器からそのポートを通ってパケットがスイッチに入ると、スイッチはそのポートのPVIDをVLANタグとしてパケットに付与します。

タグ付き／アンタグポートが「スイッチからポートへ向かう」パケットの扱いを決めるのに対し、PVIDは「ポートからスイッチへ入る」パケットに影響します。

VLAN対応機器が接続されているポートでは、機器自身がVLANタグを付与するので、PVIDを設定する必要はありません。

一方、VLAN非対応機器が接続されているポートでは、スイッチが代わりに正しいVLANタグを付ける必要があるため、PVIDの設定が必要です。

TP-LinkマネージドスイッチでVLAN設定を開く方法

TP-LinkのVLAN設定は、似たような名前の項目の中に埋もれていて見つけにくいです。最初は自分が正しい設定を触っているのかどうかすら分かりませんでした。

私の機種と似たインターフェースのTP-Linkスイッチをお使いなら、次の手順でVLAN設定にたどり着けます。

1. ナビゲーションバーで「L2 Features」をクリックします
2. 左側のサイドバーで「VLAN」をクリックします
3. サブメニューで「802.1Q VLAN」をクリックします

「VLAN Config」タブでは、スイッチにVLANを追加し、どのポートをそのVLANのメンバーにするかを設定できます。

「Port Config」タブでは、各ポートのPVIDを設定できます。繰り返しになりますが、PVIDを設定するのは、VLANに所属させる必要があるVLAN非対応機器が直接つながっているポートだけです。PVIDを設定するポートは、単一のVLANにアンタグポートとして所属させてください。

なぜTP-LinkはPVIDを手動で管理させるのか

機種によっては、PVIDを設定項目として見せないものもあります。タグ付きポートとアンタグポートだけを表示し、PVIDはスイッチが自動で設定してくれます。

PVID設定を公開していないスイッチでは、ポートをVLAN 20にアンタグポートとして追加すると、暗黙的にそのポートのPVIDが20に設定されます。TP-Linkもこの方式を採用してくれればよかったのにと思います。今の実装は不必要に複雑です。

TP-LinkスイッチでアンタグポートとPVIDを管理する際の私なりの原則は次のとおりです。

• VLAN非対応機器をスイッチに接続する場合は、単一のVLANにのみ所属させます。
  • その機器のポートを、対象VLANにアンタグポートとして追加します。
  • そのポートのPVIDをVLAN IDに設定します。
  • 他のすべてのVLANからそのポートを外します。

例えば、プリンターをスイッチのポート16に接続してVLAN 20に入れたい場合、ポート16をVLAN 20にアンタグポートとして追加し、ポート16のPVIDを20に設定します。

TP-Linkは技術的には1つのポートを複数のVLANにアンタグポートとして追加できますが、そうする理由はないと思います。そうすると、その機器は他のVLAN上の機器からパケットを受信できてしまいますが、送信できるのはPVIDと一致する単一のVLAN上の機器に限られるからです。

マネージドスイッチ導入前の自宅ネットワーク

マネージドスイッチを導入する前からVLANは使っていましたが、アンマネージドスイッチ経由で接続していました。

当時のネットワーク構成に関わる機器は次のとおりです。

• すべてのVLANにフルアクセスできるデスクトップPC
• 異なるVLANに紐づいた2つの無線LANを提供するRuckus製無線アクセスポイント
• VLAN間やインターネットへのパケットにファイアウォールルールを適用するOPNsenseファイアウォール
• 一部のVMのネットワークインターフェースにVLAN IDをタグ付けしているProxmoxサーバー

なお、この図ではVLAN対応機器同士を直列に接続していません。この構成が設定をとてもシンプルにしていたことに、マネージドスイッチに替えて初めて気づきました。

失敗その1：アンマネージドスイッチをマネージドスイッチに置き換えたらWi-Fiでインターネットが使えなくなった

TP-Link TL-SG3428Xを購入したとき、それまで使っていたアンマネージドスイッチと単純に入れ替えました。ネットワーク図自体はほとんど変わりません。

新しいマネージドスイッチを設置して数分後、婚約者からノートPCでインターネットに繋がらなくなったと言われました。自分のスマートフォンを確認すると、同じ状態でした。

Wi-Fi自体にはどの機器も接続できるのに、インターネットにアクセスできないのです。どうしてでしょうか。ファイアウォールの設定は一切変えていません。アンマネージドスイッチをマネージドスイッチに置き換えただけなのに。

数時間後、ようやく原因が分かりました。マネージドスイッチがタグ付きパケットをすべて破棄していたのです。Wi-Fi機器からアクセスポイントまではトラフィックが届くものの、スイッチが私のVLANを認識していないため、VLANタグが付いたパケットを拒否していました。

解決策は、マネージドスイッチに既存のVLANを認識させることでした。そうしなければ、スイッチはVLANタグ付きパケットを破棄し続けてしまいます。

修正後のマネージドスイッチの設定は次のとおりです。

この設定変更の後、Wi-Fi機器は再びインターネットに接続できるようになりました。スイッチがVLANタグを認識し、トラフィックをOPNsenseファイアウォールへ転送するようになったからです。

失敗その2：ルーターをVLANに追加し忘れた

次につまずいたのは、信頼できない機器をネットワークに追加しようとしたときでした。自宅のソーラーパネルを監視するために、この独自仕様のIoT機器を使わなければなりません。

このIoT機器は、計測データをベンダーのクラウドダッシュボードにアップロードするためにインターネットアクセスを必要とします。この小さな箱が他に何をしているのか分からないので、自宅ネットワーク上の何にもアクセスさせたくありません。

OPNsenseファイアウォールに「Purgatory」という新しいVLANを作りました。ゲストよりもさらに信頼できない機器用のVLANです。Purgatory内の機器はDNSサーバーとインターネット上の公開IPにはアクセスできますが、他のVLANには一切アクセスできません。

次に、TP-Linkスイッチ上でソーラー監視用IoT機器のポートをPurgatory VLANに追加しました。IoT機器はVLAN非対応なので、Purgatoryのメンバーとしてアンタグポートに設定し、ポートのPVIDにはPurgatoryのVLAN ID（80）を割り当てました。

ポートをVLANにアンタグポートとして割り当てると、パケットがIoT機器に届く前にVLANタグが取り除かれます。PVIDを割り当てると、IoT機器がスイッチに送り込むパケットにVLANタグが付与されます。

しかし、うまくいきませんでした。クラウドダッシュボードではすぐにIoT機器がオフラインと表示されました。

IoT機器側では何の診断も実行できないので、別のシステムでデバッグする必要がありました。Dell OptiPlexのNixOSマシンをPurgatory VLANに追加してみたところ、こちらもネットワークアクセスを失いました。Purgatory VLANに所属している限り、ネットワーク上の何にもpingが通らなくなったのです。

何が悪いのか分からず、頭を抱えました。テスト用機器をタグ付きポートにしたり、アンタグポートにしたり、PVIDを1にしたり80にしたりと、あらゆる組み合わせを試しましたが、どれもダメでした。機器をネットワークに参加させることができませんでした。

OPNsenseファイアウォールを確認しても、Purgatory VLAN上には一切トラフィックが表示されません。DHCPの設定を確認すると、Purgatory VLAN用のDHCPサーバーはきちんと動作していました。

3晩にわたって悩んだ末、ようやく気づきました。OPNsenseファイアウォールをPurgatory VLANに追加していなかったのです。

実際に起きていたことは次のとおりです。

1. IoT機器がTP-Linkマネージドスイッチにトラフィックを送信する。
2. スイッチがPurgatory用のVLANタグを付与する。
3. Purgatory VLANには他にホストがいないため、パケットの行き先がない。

解決策はシンプルでした。OPNsenseファイアウォールをPurgatory VLANに追加することです。ファイアウォールはVLAN対応なので、タグ付きポートとして追加しました。

ポート24の元のPVID設定は正しいままでした。IoT機器がスイッチに送るパケットにPurgatory用のVLANタグ80を付けてもらう必要があるため、PVIDは80でなければなりません。

この修正を行ったところ、IoT機器はクラウドダッシュボードに接続できるようになり、同時に自宅ネットワークからは適切に隔離されました。

VLANの問題をデバッグするコツ

VLANの問題をデバッグする上で最も難しかったのは、設定変更がどのような影響を与えたのかを観測する方法を見つけることでした。ポートをタグ付きからアンタグに変えたら、どうやって効果をテストすればよいのでしょうか。

Wiresharkを使ってみる

機器のネットワーク状態を診断するためにいくつかのコマンドラインツールを試しましたが、最も役立ったのはWiresharkでした。

普段はあまりWiresharkを使いたくありません。素晴らしいツールではありますが、自分の問題に関係する情報を見つけようとすると迷子になってしまうからです。Wiresharkを開けば、またフィルタクエリ言語を学び直さなければいけないのだろうと身構えてしまい、あまり気が進みません。

今回は、Wiresharkで凝ったことをする必要はまったくありませんでした。立ち上げてみると、機器からトラフィックが出ていこうとしているのに何も返ってこない様子がすぐに分かり、何が問題なのかに気づけました。

再起動する

VLANの問題をデバッグする際の大きな悩みの1つは、テスト用コンピューターが新しいVLAN設定に「いつ」反応したのかが分かりにくいことでした。

ネットワーク状態をリセットする手法としてこれが最も確実だとは言いたくないのですが、実際そうでした。ホストが何を動かしているかにもよりますが30〜90秒かかるので面倒ですし、テストのサイクルも遅くなります。それでも、スイッチ側のVLAN設定変更に対してシステムのネットワーク状態を確実にリセットするという点では、他のどの方法よりも効果がありました。

もっと良い方法があるはずですが、私は見つけられませんでした。

リモート管理ツールを使う

TinyPilotは私の製品なのでひいき目かもしれませんが、VLANの問題のデバッグにはTinyPilotが役立ちました。

当初はProxmox VMサーバー上のVMでVLANのデバッグを試みましたが、これはシミュレートしたい実際のIoT機器とは性質が違いすぎました。ProxmoxサーバーはVLAN対応ですが、再現したいのはVLAN非対応機器の挙動です。Proxmoxサーバーをアンタグポートとして扱うと、サーバー自体にまったくアクセスできなくなってしまいます。

TinyPilotがあれば、テスト対象の機器がネットワーク接続を失っても、常にアクセスを確保できました。しかも、メインのデスクトップからブラウザのタブで操作するだけで、すべての設定が完結します。

ping

ネットワーク接続の断絶を確認するのに最も確実だったのは、昔ながらのpingユーティリティでした。

2つのターミナルウィンドウで、2つのpingコマンドを実行しました。1つはファイアウォール（10.0.80.1）宛て、もう1つはgoogle.com宛てです。それぞれのウィンドウで、ローカルネットワークとGoogleへの接続がいつ失われ、いつ復旧したのかが分かりました。

ping 10.0.80.1    # Test connection to router
ping google.com   # Test connection to Internet

ifconfig

意外にもifconfigコマンドはあまり役に立ちませんでした。次のコマンドでネットワーク設定がリセットされるだろうと思っていました。

IFACE="eth0"

sudo ifconfig "${IFACE}" down && \
  sudo ifconfig "${IFACE}" up && \
  sudo ifconfig "${IFACE}"

しかし、これらのコマンドを実行しても、ネットワーク状態がリセットされないことが多かったのです。スイッチ側で機器をあるネットワークから外し、機器側でネットワークインターフェースをifconfigでリセットしても、機器は古いVLANのIPアドレスを保持したままだと認識していました。再起動するまで、新しいサブネットのIPアドレスを取得してくれませんでした。

dhclient

dhclientを勧めている人も見かけました。この一連のコマンドで、ホストにDHCPリースを解放させ、新しいリースを要求させるというものです。

dhclient -r
dhclient

私のテスト環境ではうまくいきませんでした。最初のコマンドがハングしたまま、DHCPリースが解放されなかったのです。

nslookup

nslookupも試してみました。これまであまり使ったことがありませんでしたが、DNSルックアップの結果を教えてくれます。

nslookupは結局VLANのデバッグには役立ちませんでしたが、手持ちの道具として覚えておくには良いツールです。

ハマりどころ

TP-LinkスイッチでVLANを設定する際に私がハマったポイントは次のとおりです。

• VLANにアンタグポートを指定したのに、そのポートのPVIDを設定し忘れた。
• ポートをVLANに追加したのに、同じVLANにルーターのポートを追加し忘れた。
• VLAN対応機器AがVLAN対応機器B経由でファイアウォールに接続している場合、BはAのすべてのVLANを認識していなければならないことを忘れていた。そうでないと、Bがファイアウォールに届く前に未認識のVLANのパケットをすべて破棄してしまう。
• TP-Linkのナビゲーションバーにある「Save」ボタンを押さないと、次にスイッチを再起動したときに変更がすべて消えてしまう。