VPNルーターのLANとWAN:購入前に記録すべきこと
VPNの表示だけでは、VLAN、WANのフェイルオーバー、トンネルの役割は何も分かりません。導入する機種とファームウェアの正確な機能を書き留めてください。
VPN対応という表示は、ルーティング、分割、障害時の切り替えも担う機器の一機能として扱うべきで、表示だけでは装置がいくつの独立したネットワークを収容できるかは分かりません。まず正確な機種とファームウェアについて機能記録を書き、その記録を現場が必要とするフローと照らし合わせます。販売ページはポート数を並べますが、VLANの所属、フェイルオーバー方針、トンネルの範囲まで載せることはほとんどありません。記録には二十分ほどかかり、機器が届く前に購入論争の大半を決着させます。
何よりも先に正確な機体を固定する
機種名はファームウェアの世代をまたいで流通し、同じ筐体でもリリースによって別のスイッチドライバで出荷されることがあります。基板の識別情報は段ボールではなく装置そのものから読めば、後続の主張はすべて再現できるものに結び付きます。OpenWrtでは一つのコマンドで機種、基板名、ファームウェアのリリースが分かり、同等の画面は多くの業務用ファームウェアにもあります。
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_release
その文字列を短縮せずに記録へ書き込みます。次に、通常のルーティング作業とトンネル作業を分けてください。パケット転送が得意な装置でもトンネルを終端できないことがあり、トンネルを終端する装置でも二つのローカルネットワークを分離できない場合があります。両者を一つの要件として扱うと、機器がすでにラックへ設置され、設定され、半分信用された状態になるまで食い違いが隠れます。
ポート数ではなくLANの構造を記録する
四つのポートは通常は一つのスイッチを意味し、VLANを設定しない限りスイッチは一つのブロードキャストドメインを意味します。平坦な家庭内ネットワークには適しますが、同じ機器にゲスト用セグメント、管理用セグメント、分離したカメラ用セグメントを求める現場には不適切です。どのポートがどのVLANに属するか、どのVLANがCPUに届くか、どのインターフェースがアドレスを持つかを記録します。
ファームウェアがVLANを提供する場合、インターフェース一覧が書ける方針の数を決めます。スイッチ上で定義されてもインターフェースとして割り当てられないVLANにはアドレスもファイアウォールゾーンもなく、単独では何も強制できません。
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
メニューを信じるのではなく、スイッチの状態を読みます。古いOpenWrtの対象ではスイッチ用ツールが設定済みのデバイスを出力し、DSAの対象ではブリッジ用ツールがポートごとに同じ事実を報告するため、ファームウェアのリリースを記録に含めます。
WANとフェイルオーバーの挙動を書き留める
接続方式、アドレスの所有、フェイルオーバーの順序はWANの変化を生き延びるトンネルがこの三つすべてに依存するため、上流リンクごとに一行へ収めます。PPPoEセッションは新しいアドレスで再接続し、トンネルもろとも落としますが、リースを保つDHCPの上流リンクはそうならないことがあります。
フェイルオーバーには方針の判断も必要です。すべての通信を予備リンクへ送るのは簡単ですが、通常のウェブ通信が予備を使う間にトンネルを主リンクに保つにはポリシールーティングが必要で、すべてのファームウェアがそれを備えているわけではありません。トンネルが一つの上流リンクに結び付いているか、そのリンクが消えたときに装置が確立済みのセッションをどう扱うかを記録します。フェイルオーバーのチェックボックスではなく、ルーティングテーブルを証拠として残してください。
許可されるフローと拒否されるフローを一つずつ試す
記録は、それに照らして装置を検収できる場合にだけ残す価値があります。通るべきフローを一つ、通ってはならないフローを一つ選び、問題のセグメントのクライアントから両方を実行します。すべてのサブネットを運ぶトンネルは、要件が一つのサブネットだった場合には失敗です。
許可的な初期設定がいつもの驚きなので、次に拒否を確認します。ゲスト用セグメントは管理アドレスへ到達してはならず、確認はログインページではなくタイムアウトか拒否を示すべきです。
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1
許可したフローが通り、拒否したフローも通るなら、メニューが示唆した内容に反して分割が欠けています。両方が失敗するなら、トンネルの範囲か戻り経路が誤っており、WANの記録がどちらかを通常は説明します。二つの結果を機能記録と一緒に残し、次の確認者が何を、どのファームウェアで、いつの日付に受け入れたかを見られるようにします。