私は最近、人生で初めてのマネージドスイッチを購入しました。TP-Link JetStream TL-SG3428Xです。

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

TP-LinkのVLANドキュメントは不十分だと感じたので、他の方の参考になればと思い、自分のメモを共有します。

背景

VLANをご存じない方のために、私のお気に入りの解説はRaid Owlの動画です。

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

機器によって、VLAN機能を説明する用語は異なります。

TP-Linkのスイッチで知っておくべき重要な設定は次のとおりです。

• タグ付きポート
• アンタグ付きポート
• 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を理解できないため、スイッチがVLANタグを剥がすのです。

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

PVID

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

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

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

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

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

TP-LinkはVLAN設定を似たような名前のオプションの中に紛れ込ませているので、最初は自分が正しい設定を触っているのかどうかも分かりませんでした。

私のスイッチと似たインターフェースをお使いの場合、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ネットワークに参加できるのに、インターネットにアクセスできません。どうしてでしょうか。ファイアウォールの設定は何も変えていません。アンマネージドスイッチをマネージドスイッチに置き換えただけなのに。

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

解決策は、既存のVLANについてマネージドスイッチに教えてあげることでした。そうしなければ、スイッチはVLANタグ付きパケットをドロップし続けるからです。

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

この設定変更の後、Wi-Fiデバイスは再びインターネットに繋がるようになりました。スイッチがVLANタグを認識し、トラフィックをOPNsenseファイアウォールへ通過させるようになったのです。

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

次に、信頼できない機器をネットワークに追加しようとしたときに、別の問題に遭遇しました。自宅にはソーラーパネルがあり、その状態を監視するために独自のIoT機器を使わなければなりません。

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

そこでOPNsenseファイアウォールで新しいVLANを作成し、ゲストよりもさらに信頼できない機器用の「Purgatory（煉獄）」と名付けました。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の問題をデバッグする際の大きな悩みの種の一つは、テスト用コンピューターが新しいVLAN設定に「いつ反応したか」がよく分からないことでした。

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

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

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

TinyPilotは私のプロダクトなので多少ひいき目はありますが、VLANの問題をデバッグする際にTinyPilotが役に立ちました。

最初はProxmox VMサーバー上のVMでVLANのデバッグを試みましたが、それは実際にシミュレートしたいIoT機器とは違いすぎました。ProxmoxサーバーはVLAN対応ですが、シミュレートしたかったのはVLAN非対応の機器だったのです。Proxmoxサーバーをアンタグ付きポートとして扱うと、Proxmoxサーバー自体から締め出されてしまいます。

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

ping

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

2つのターミナルウィンドウで2つのpingコマンドを使いました。一つはファイアウォールの10.0.80.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」ボタンを押さないと、次回スイッチが再起動したときに変更が消えてしまう。