「Network」の記事 - Crieit

NEC IXシリーズルーターでポートVLANとタグVLANをVLANスイッチ的に併用する

2023-09-23T02:32:08+09:00

この記事では、 GE0, GE1 の 2つの "デバイス" を持つ NEC の IX2105 ルーターを例に、1カ所のスイッチングハブ用のデバイスの中でポートVLAN とタグVLAN を併用し、スイッチングハブのトランクポートやアクセスポートのように使う方法について説明する。

はじめに

国内の中規模オフィス向けのルーターとして、 Yamaha や Cisco がよく知られているが、 NEC も UNIVERGE IXシリーズを提供している。

Yamaha の RTXシリーズと価格帯が近いものの、 NEC の IXシリーズには、 Yamaha と比べてもわりと柔軟な構成を行える利点がある。

一方で Yamaha と比べた場合、 NEC の IXシリーズの設定方法を調べるのは少し…いや、だいぶ難しい。
書籍や Web 記事、公式マニュアルなど、ドキュメントや設定例の全てに於いて、 Yamaha と比べて著しく情報が少ないためだ。

そんな IXシリーズを使って、ポートVLAN とタグVLAN を併用する方法について紹介しよう。
（この併用も、Yamaha の RTX で同一ポート内で実現するのは難しい機能のひとつだ）

なお、同じ UNIVERGE でも LTE や Wi-Fi などのワイヤレス機能を持った WAシリーズでは、 VLAN 周りのコマンド体系が異なるため、このページの方法は使えない。

設定例として挙げている IX2105 は 2019年9月30日をもって販売を終了しているが、マイナーバージョンこそ Ver.10.2 までに留まるものの不具合修正は続いている。
（例えば後継の IX2106 だと 10.2系は Ver.10.2.26 までで終了し、最新版は Ver.10.8.21 となっている）
中古ならヤフオク等で二束三文で手に入るし、最新 FW (ソフトウェア) も NEC に "UNIVERGE IXシリーズソフトウェアダウンロードサイトへの接続申請書" を出せば手に入るので、練習機としてはもってこいだ。

ゴール

以下のような構成を行う。

既定ではスイッチングハブとなっている、 GE1 デバイスの4つの物理ポートを、以下の3つに分割する
- タグ付き通信を行う（即ちトランクポートとなる）1番ポート
  - 但し、管理VLAN 的に使うため、 untag のフレームも受け付ける
- VLAN100 の通信を untag で行う（即ちアクセスポートとなる）2番ポート
- VLAN200 の通信を untag で行う（即ちアクセスポートとなる）3, 4番ポート
各 VLAN それぞれで DHCP サーバによる異なるセグメントの IP アドレスの割り当てを行う
GE0 デバイスでは NAT (NAPT) を行い、 GE1 デバイスの各セグメントからのルーティングも受け付ける

先に最終的な構成を載せておくと、以下のようになる。

ip ufs-cache enable
ip dhcp enable
ip access-list web-http-acl permit ip src any dest 192.168.99.1/32
!
!
!
!
! ブリッジの有効化
bridge irb enable
!
!
!
! GE0 から DNS サーバーを自動取得し DNSプロキシー を実行
proxy-dns ip enable
proxy-dns interface GigaEthernet0.0 priority 254
! Webコンソールを管理ポートの 192.168.99.1 として開始
http-server ip access-list web-http-acl
http-server ip enable
!
!
!
! 各サブネットごとに、自身をDNSサーバーと通知するDHCPプロファイルを作成
ip dhcp profile dhcp-profile-99
  dns-server 192.168.99.1
!
ip dhcp profile dhcp-profile-120
  dns-server 192.168.120.1
!
ip dhcp profile dhcp-profile-130
  dns-server 192.168.130.1
!
device GigaEthernet0
! GE1 ポートに ポートベース VLAN グループを設定
device GigaEthernet1
  vlan-group 2 port 2
  vlan-group 3 port 3 4
! GE0 は WAN 側として、 IPアドレスを DHCP から自動取得し、 NAPT を有効化
interface GigaEthernet0.0
  description WAN1
  ip address dhcp receive-default
  ip napt enable
  ip napt hairpinning
  no shutdown
! GE0 の グループ N/A (ポート1番) のアドレスと DHCP の設定
interface GigaEthernet1.0
  description LAN1
  ip address 192.168.99.1/24
  ip dhcp binding dhcp-profile-99
  no shutdown
! GE0 の グループ N/A (ポート1番) の VLANID 222 の VLAN タグ付きの設定 (BVI20とブリッジ)
interface GigaEthernet1.2
  description VLAN222
  encapsulation dot1q 222 tpid 8100
  auto-connect
  no ip address
  bridge-group 200
  no shutdown
! GE0 の グループ N/A (ポート1番) の VLANID 333 の VLAN タグ付きの設定 (BVI30とブリッジ)
interface GigaEthernet1.3
  description VLAN333
  encapsulation dot1q 333 tpid 8100
  auto-connect
  no ip address
  bridge-group 300
  no shutdown
! GE0 の グループ 2 (ポート2番) の untag の設定 (BVI20とブリッジ)
interface GigaEthernet1:2.0
  no ip address
  bridge-group 200
  no shutdown
! GE0 の グループ 3 (ポート3番&4番) の untag の設定 (BVI30とブリッジ)
interface GigaEthernet1:3.0
  no ip address
  bridge-group 300
  no shutdown
! VLANID 222 向けのブリッジインタフェースのアドレスと DHCP の設定
interface BVI20
  ip address 192.168.120.1/24
  ip dhcp binding dhcp-profile-120
  bridge-group 200
  no shutdown
! VLANID 333 向けのブリッジインタフェースのアドレスと DHCP の設定
interface BVI30
  ip address 192.168.130.1/24
  ip dhcp binding dhcp-profile-130
  bridge-group 300
  no shutdown
!
interface Loopback0.0
  no ip address
!
interface Null0.0
  no ip address
!

メモ:

なお、このページのコンフィグ例では、 IX2105 や IX2106, IX2107 のように GigaEthernet1 デバイスがスイッチングハブであることを前提としている。
IX2215 や IX2235 のように GigaEthernet2 デバイスなどがスイッチングハブとなっている場合、適宜読み替えて設定して欲しい。

前提知識

ひとつひとつ、細かく解説していこう。

まず前提として理解しておかなくてはならないのは、 IXシリーズの設定の考え方に於いて タグVLAN とポートVLAN は全く異なる機能 であり、独立した設定となっている、という点だ。

タグVLAN

タグVLAN は、

ある GigaEthernet1.0 といった "基本インタフェース" に対して、 GigaEthernet1.2 のような "サブインタフェース" を作成し… ¹
各サブインタフェースに VLAN ID を割り当てると…
基本インタフェース側では IEEE 802.1Q VLANタギングでカプセル化されたフレームが流れる

という仕組みだ。

すなわち、基本インタフェース GigaEthernet1.0 内にて、各サブインタフェース GigaEthernet1.1, GigaEthernet1.2 が、 VLANタギングによってトンネリングされていると見做せる。

基本インタフェースも各サブインタフェースも、それぞれに IP アドレスを割り当てれば、各々がルーティングの対象となる。

メモ:

IXルーター上でトンネリングを行う仕組みとしては、似たようなもので他にも Tunnelインタフェースが存在する。

Tunnelインタフェースでは、カプセル化後が (L3 の) IP パケットとなるようなモノを対象とするため、カプセル化後のパケットはルーティングされる。

一方、サブインタフェースでは、 VLANタギングや PPPoE といった、カプセル化後が (L2 の) Ethernet フレームとなるようなモノを対象としているため、カプセル化後のフレームは親となる基本インタフェース（と後述するブリッジ先）にしか流れない、といった仕組みの違いがある。

ポートVLAN

一方で ポートVLAN は、

スイッチハブ機能を持つデバイス (IX2105 なら GigaEthernet1) を
複数のサブネット (グローバルキャストドメイン) に分割＆グループ化し
GigaEthernet1:2.0, GigaEthernet1:3.0 のような「ポートベース VLAN グループ番号」が異なる独立したインタフェースを作成する ¹

という仕組みだ。

すなわち、グループなし GigaEthernet1.0 や、ポートベース VLAN でグループ化された GigaEthernet1:2.0, GigaEthernet1:3.0 などは、それぞれ L2 (レイヤー2) 的に互いに独立していると見做せる。

もちろん、各ポートVLANグループにそれぞれ IP アドレスを割り当てれば、各々がルーティングの対象となる。

ブリッジ

独立したタグVLAN とポートVLAN を紐づけるためには、複数のインタフェースをひとつのサブネット（グローバルキャストドメイン）にまとめる ブリッジ機能 を活用する。

インタフェースにブリッジ機能を割り当てると、そのインタフェースでは L3 のネットワーク層の情報が機能しなくなるため、IPアドレスや DHCP の設定など L3 に関する機能が使用できなくなる。 ²

このため、ブリッジしたインタフェース上でルーティングや IPアドレスの設定などを行う場合、 BVIインタフェース という仮想インタフェースを作成してブリッジに加え、これに IPアドレスなどの L3 に関する機能を割り当てる必要がある。

具体的なコンフィグの解説

まず、 GE0 を NAPT する WAN側、 GE1 を DHCP と Webコンソールを有効にした LAN側と見立てた、以下のようなコンフィグを入れてある状態とする。

ip ufs-cache enable
ip dhcp enable
ip access-list web-http-acl permit ip src any dest 192.168.99.1/32
!
proxy-dns ip enable
proxy-dns interface GigaEthernet0.0 priority 254
!
http-server ip access-list web-http-acl
http-server ip enable
!
ip dhcp profile dhcp-profile-99
  dns-server 192.168.99.1
!
interface GigaEthernet0.0
  description WAN1
  ip address dhcp receive-default
  ip napt enable
  ip napt hairpinning
  no shutdown
!
interface GigaEthernet1.0
  description LAN1
  ip address 192.168.99.1/24
  ip dhcp binding dhcp-profile-99
  no shutdown
!

タグVLANの構成

タグVLAN のトランクポートを扱うには、前述の「サブインタフェース」を作成する必要がある。

以下のように、 GigaEthernet1.0 に対応する各サブインタフェースにも IP アドレスや DHCP の設定を行うと、 GE1 の各ポートでは

タグなし: 192.168.99.1/24 の基本インタフェース
VLAN ID 222: 192.168.120.1/24 のサブインタフェース番号2
VLAN ID 333: 192.168.130.1/24 のサブインタフェース番号3

に割当たるようになる。

encapsulation dot1q コマンドを実行した場合は、その反映には端末の再起動が必要な点には注意。

ip dhcp profile dhcp-profile-120
  dns-server 192.168.120.1
!
ip dhcp profile dhcp-profile-130
  dns-server 192.168.130.1
!
interface GigaEthernet1.2
  description VLAN222
  encapsulation dot1q 222 tpid 8100
  auto-connect
  ip address 192.168.120.1/24
  ip dhcp binding dhcp-profile-120
  no shutdown
!
interface GigaEthernet1.3
  description VLAN333
  encapsulation dot1q 333 tpid 8100
  auto-connect
  ip address 192.168.130.1/24
  ip dhcp binding dhcp-profile-130
  no shutdown

encapsulation dot1q コマンドで tpid の値を省略してもデフォルト値 0x8100 が設定されるのだが、省略したか否かにかかわらず show running-config や show startup-config のダンプ結果には表示されるため、最初からコマンドに含めている。

上記の例では、説明のために敢えてサブインタフェース番号 2 に VLAN ID 222、等と異なる番号を割り当てているが、実際に設定するときはある程度揃えておいた方が分かりやすいだろう。
サブインタフェース番号の上限は 32 等と少なめ（機種による）なので、 VLAN ID と完全に一致させるのはなかなか難しいだろうが。

ポートVLANとブリッジの追加構成

前項のタグVLAN の構成だけでは、 GE1 のどの番号のポートもトランクポートへのアクセスとなるため、 untagged なフレームを VLAN 用のサブネットにスイッチングできない。

GE1 の 2番～4番ポートをアクセスポートのように扱うために、これらのポートにポートVLANのグループ設定を構成し、トランクポートとネットワークを分割する以下のコードを実行する。

device GigaEthernet1
  vlan-group 2 port 2
  vlan-group 3 port 3 4

"ポートベース VLAN グループ番号" 2 に、 GE1 の 2番ポートを、グループ番号 3 に、 GE1 の 2番 & 4番ポートを、それぞれ割り当てている。

なお、グループ番号は 1 からスイッチングハブスロット上のポート数以下の整数値 (IX2105 なら 4) を設定できる。

GE1 の 1番ポートをグループ化の対象としないことにより、1番ポートには GigaEthernet0.0 のタグVLAN トランクポートのフレームが引き続き流れ続ける。

一方で、単にポートVLANグループに分割しただけでは、2番～4番ポートに untagged のフレームはスイッチングされてこない。

そこで、 untagged なフレームが流れているタグVLAN の各サブインタフェースと、 ブリッジ させてしまおう。

configure
bridge irb enable
!
!
interface GigaEthernet1.2
  description VLAN222
  encapsulation dot1q 222 tpid 8100
  no ip address
  no ip dhcp binding dhcp-profile-120
  bridge-group 200
  no shutdown
!
interface GigaEthernet1:2.0
  no ip address
  bridge-group 200
  no shutdown
!
interface BVI20
  ip address 192.168.120.1/24
  ip dhcp binding dhcp-profile-120
  bridge-group 200
  no shutdown
!
!
interface GigaEthernet1.3
  description VLAN333
  encapsulation dot1q 333 tpid 8100
  no ip address
  no ip dhcp binding dhcp-profile-130
  bridge-group 300
  no shutdown
!
interface GigaEthernet1:3.0
  no ip address
  bridge-group 300
  no shutdown
!
interface BVI30
  ip address 192.168.130.1/24
  ip dhcp binding dhcp-profile-130
  bridge-group 300
  no shutdown
!

まず、ブリッジ機能を有効にするために bridge irb enable コマンドの実行が必要だ。
(このコマンドはグローバルコンフィグモードで実行する必要があるため、手前で configure コマンドを実行している)

ここでタグVLAN のサブインタフェースと、グループ化したポートをブリッジするのだが、前述の通りブリッジ機能を使うとサブインタフェースに設定していた L3 の IP 関連の構成が機能しなくなる。
このため、 VLAN 毎に BVI インタフェースを作成してブリッジに加えたうえで、そちらに ip address や ip dhcp binding の構成を移植する。

なお、タグVLAN で使用している "サブインタフェース番号" GigaEthernet1.2 と、ポートベース VLAN で使用している "グループ番号" GigaEthernet1:2.0 (、そして BVI インタフェース番号 BVI20 や bridge-group 200、 VLANID VLAN222) をある程度数字揃えてブリッジしているが、必ずしもこれら番号は揃えておく必要は無い。
見やすさやわかりやすさを重視しつつ、指定できる範囲内で設定するのが良いだろう。

動作確認

ここまでの設定が完了すると、4つのサブネット間でルーティングされ、GE1 デバイスの各ポートでは以下のような組み合わせで VLAN のイーサネットフレームが流れるようになる。

試しに、GE1 の 2番ポートに繋いだ PC (192.168.120.2) から、 GE1 の 1番ポートに繋いだ PC (192.168.99.2) に、 ping を打ってみた所を、 GE1 の 1番ポートに繋いだ PC 側でパケットキャプチャしてみる。

192.168.120.1/24 のサブネットで ARP のブロードキャストされたフレームが、送信元 PC に繋いだ NIC の MACアドレス (Buffalo_f0:1X:XX) より VLANID 222 のタグ付きで 1番ポートへ届いていることがわかる。

一方、 ICMP の通信はルーティングされた上で 192.168.99.2/24 のサブネットへ届いているため、 IXルーターの MACアドレス (NECPlatf_4f:XX:XX) よりタグなしで 1番ポートへ届いていることがわかる。

おわりに

上記の設定では、VLANグループ間でスイッチングはされないが、サブネット同士で自由にルーティングされる。このため、L3スイッチで VLAN を分割しただけの場合とは異なり、 VLAN 間でも IPレイヤーの通信は行われる。実運用で VLAN 間の通信を制限したい場合は、適宜フィルタなどを追加して使う事になるだろう。
また、パスワードが設定されていないので、実運用では設定しておこう。

以上のように、VLAN スイッチなどでは単純にできるような設定でも、ルーターで実現するにはまぁまぁ大変であることがわかると思う。

とはいえ、ブリッジなどを駆使すれば、このような複雑な構成であってもルーターだけで構成できるのが IXルーターの強みとも言える。

上記の例では使用しなかったが、 GigaEthernet1:2****.3 のように、"ポートベース VLAN グループ番号" に "サブインタフェース番号" をつけることもできるため、ポートベース VLAN グループに割り当てたポートに VLAN タグがついたフレームを流すことも可能だ。 ³

参考: NEC IX2207 の VLAN 設定備忘録 | hyt adversaria

IX2000シリーズ取扱説明書の【3 基本操作と各種説明 → モードについて → インタフェース表示の意味】あたりを参照 ↩︎ ↩︎
IX2000/IX3000 シリーズ機能説明書の【■2.9 ブリッジの設定】より ↩︎
UNIVERGE IXシリーズ設定事例集の【19.2 ポートベース VLAN とタグ VLAN の併用】あたりを参照 ↩︎

GNS3 に VyOS 仮想ルーターを追加する長い道のり④ 応用編

2022-12-28T23:48:38+09:00

本記事は【アットホームな現場です】🎄★☆ネットワーク系エンジニア★☆アレコレアウトプット★☆🎄 Advent Calendar 2022 25日目の記事だ。
ごめんなさい、色々書いてたら結局分量が多くなって期限内に書き切れなかった。

GNS3 という OSS のネットワークエミュレータを、 Cisco の IOS などの取得なしに、無料のライセンス内で利用できるようにしようという話。

今回は最終回の応用編。
以前の投稿はこちら。
https://crieit.net/posts/GNS3-VyOS (① 環境導入編)
https://crieit.net/posts/GNS3-VyOS-63ac561ed5a75 (② イメージ準備編)
https://crieit.net/posts/GNS3-VyOS-63ac5693838af (③ 実践編)

目指すゴール

今回は、上記の図のように、ルーターを 2台置いて、ルーターを跨いだ端末間 (tmp-net-tools-1, -2) で通信ができるように構成していく。

相互通信するコンテナの準備

ルーターを跨いだ通信を実際に行うことになるコンテナを準備する。

通信の確認を行う最低限のモジュール（パッケージ）をインストールしたイメージを用意する。

（リスクを自分で評価しつつ）第三者が用意したイメージを使っても良いのだが、今回は自分でビルドしてみよう。

まず、 VM管理ツールや ssh で GNS3 VM の管理画面に入る
メニューから Shell を選択する
以下のコマンドで、 tmp-net-tools という名前をつけた Docker イメージをビルドする
- shell gns3@gns3vm:~$ docker build -t tmp-net-tools - FROM alpine:latest RUN apk add --no-cache curl iperf3 net-tools EOF
GNS3 (GUI) の Preferences を開き、 Docker コンテナテンプレートで上記のビルド済み tmp-net-tools でテンプレートを作成する。
- Console type は telnet で OK.

ここでポイントとなるのは、 GNS3 で動かすコンテナは基本的に（明示的に接続市内限り）外部ネットワークに繋がっていないが、 GNS3 VM で Docker をビルドする際は、外部ネットワークに繋がると言う点だ。
このため、コンテナ内にて追加で必要なパッケージがある場合、このように予めコンテナの build 段階でインストールしておく必要がある。

ネットワークの構成 1

コンテナテンプレートの準備ができたら、ペタペタとデバイスを貼って結線していく。
2つの VyOS とも、 eth0 を端末のコンテナ側に、 eth1 をルーター同士を繋ぐ Switch に繋いでいこう。

本来 VyControl は、 1サービスで複数の VyOS を管理できるはずなのだが、試した感じどうも管理対象の切り替えでエラーになってしまうので、素直に VyOS と VyControl を 1対1 で作成している。
ただ、そうするとホストPCからそれぞれの VyControl にアクセスする際に同じ IP アドレスとなって Cookie が衝突するため、片方にログインするともう一方からログアウトされてしまう問題があるので注意。

また、 vycontrol-host や tmp-net-tools の各コンテナにて、 Edit config からの /etc/network/interfaces の編集で、 eth0 を DHCP から IP アドレスを取得するよう設定することを忘れずに。

VyOS は前回の設定に加えて eth1 の IP アドレスを静的に決めるため、それぞれ以下のように設定する。

VyOS1.3.2-1:

vyos@vyos:~$ configure
vyos@vyos# set interfaces ethernet eth0 address '192.168.11.254/24'
vyos@vyos# set interfaces ethernet eth1 address '192.168.1.1/24'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' default-router '192.168.11.254'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' name-server '192.168.11.254'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' range 0 start '192.168.11.17'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' range 0 stop '192.168.11.126'
vyos@vyos# set service https api keys id my_id key 'my_secret_key'
vyos@vyos# set service https certificates system-generated-certificate lifetime '65535'
vyos@vyos# set service https virtual-host vyos1 listen-address '192.168.11.254'
vyos@vyos# set service https virtual-host vyos1 listen-port '6443'
vyos@vyos# set service https virtual-host vyos1 server-name 'vyos1.example.com'
vyos@vyos# commit
vyos@vyos# save
vyos@vyos# exit

VyOS1.3.2-2:

vyos@vyos:~$ configure
vyos@vyos# set interfaces ethernet eth0 address '192.168.21.254/24'
vyos@vyos# set interfaces ethernet eth1 address '192.168.1.2/24'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' default-router '192.168.21.254'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' name-server '192.168.21.254'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' range 0 start '192.168.21.17'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.21.0/24' range 0 stop '192.168.21.126'
vyos@vyos# set service https api keys id my_id key 'my_secret_key'
vyos@vyos# set service https certificates system-generated-certificate lifetime '65535'
vyos@vyos# set service https virtual-host vyos1 listen-address '192.168.21.254'
vyos@vyos# set service https virtual-host vyos1 listen-port '6443'
vyos@vyos# set service https virtual-host vyos1 server-name 'vyos1.example.com'
vyos@vyos# commit
vyos@vyos# save
vyos@vyos# exit

ちなみに、 VyOS の仮想デバイスは、一通り設定を完了させてから、仮想デバイスを複製できる。
VyOS のインストールなどの作業が 1回で済む点は便利なのだが、コピー後 MAC アドレスが変更になるため、仮想デバイス内のインターフェース名が、 eth0, eth1, eth2 から eth3, eth4, eth4 へと名前を変えてしまうことが多く、 GNS3 UI 上の NIC のインターフェース名と、仮想デバイス内の名前が一致しなくなってややこしい事になるので、ご注意を。

ネットワークの構成 2

さて、ここで各端末 (tmp-net-tools-1, -2) が DHCP サーバーに割り当てられた IP アドレスを使って、お互いに ping を打っても、当然届かず失敗する。

ここで VyControl を使って、それぞれの VyOS に静的ルーティングを定義する。

その後改めてお互いに ping を打つと、無事疎通ができるようになった。

外部との接続

さらなる応用として、 "Cloud" デバイスを使って外部機器との接続もできる。

まず、適当な物理NIC (USB LAN アダプタ) を、仮想マシン管理ツール側で GNS3 VM のネットワークアダプタに割り当てる。
その後、 GNS3 内で "Cloud" デバイスをその物理NIC に割り当ててやれば、物理ルーターと仮想ルーターとの間で、論理的なネットワークの接続を構成できる。

おわりに

…とまあ、こんなところが GNS3 の基本的な使い方となる。
慣れてきたら、不完全な VyControl なんか使わず、直接 VyOS に CUI コマンドで設定を定義してやると良いかもしれない。

長々となる解説となったが、誰かの役に立てば幸いだ。

GNS3 に VyOS 仮想ルーターを追加する長い道のり③ 実践編

2022-12-28T23:45:39+09:00

本記事は【アットホームな現場です】🎄★☆ネットワーク系エンジニア★☆アレコレアウトプット★☆🎄 Advent Calendar 2022 17日目の記事だ。

GNS3 という OSS のネットワークエミュレータを、 Cisco の IOS などの取得なしに、無料のライセンス内で利用できるようにしようという話。

環境導入編、イメージ準備編に続く実践編。
以前の投稿はこちら。
https://crieit.net/posts/GNS3-VyOS (① 環境導入編)
https://crieit.net/posts/GNS3-VyOS-63ac561ed5a75 (② イメージ準備編)

実際に、 GNS3 上で VyOS を使ってみよう。

GNS3 プロジェクトを作成

GNS3 を開き、適当なプロジェクトを新規作成（ないし開く）する。

平行して、 GNN3 VM が起動するまで待とう。

VyOS の起動

GNS3 GUI 上で、テンプレート一覧から VyOS のデバイスをドラッグ＆ドロップして、プロジェクトに追加する。

デバイスアイコンの右クリックで Configure をクリックしてプロパティを開き、 On close の動作を Save the VM state (休止状態) にしておくとよいだろう。

その後、デバイスアイコンの再度右クリックで Start を選択し、仮想マシンをスタートさせる。
デバイスアイコンをダブルクリックすると、コンソールが起動する。 iso ファイルがブータブルディスクになっていてるため、VyOS の起動ログが表示されているはずだ。
ログイン画面が出るまで待つ。

デフォルトの認証情報 (login: vyos, password: vyos) を使ってログインする。

VyOS 仮想 HDD へのインストール

このままでも VyOS として利用できるのだが、 "T2958 DHCP server doesn't work from a live CD" といった問題もあるようなので、一旦仮想 HDD にインストールする。
→ Permanent installation — VyOS 1.3.x (equuleus) documentation

ログイン後、以下のコマンドを実行し、いくつかの質問に答えれば OK だ。

vyos@vyos:~$ install image

その後、再起動する。

vyos@vyos:~$ reboot

再起動前は、 cat /proc/cmdline のカーネルに渡された BOOT_IMAGE が /live/vmlinuz となっていたのが、

vyos@vyos:~$ cat /proc/cmdline # 再起動前
BOOT_IMAGE=/live/vmlinuz boot=live components hostname=vyos username=live nopersistence noautologin nonetworking union=overlay console=ttyS0,115200 console=tty0 net.ifnames=0 biosdevname=0 initrd=/live/initrd.img

再起動後は、 install image の途中で入力したイメージ名のものに変更されていることがわかる。

vyos@vyos:~$ cat /proc/cmdline # 再起動後
BOOT_IMAGE=/boot/1.3.2/vmlinuz boot=live rootdelay=5 noautologin net.ifnames=0 biosdevname=0 vyos-union=/boot/1.3.2 console=tty0 console=ttyS0,115200

VyOS の初期設定

VyOS の操作は VyContol に任せたい… が、どうしても VyControl から VyOS にアクセスできるようにするため、以下の 3点はコマンドで設定する必要がある。

インターフェースへの IP の設定
- 以下の例では、 192.168.11.254/24 に設定
DHCP サーバーの起動
- 以下の例では、 192.168.11.0/24 のサブネットに、 DNS, デフォルトゲートウエイを自分自身、 DHCP の貸し出し範囲を .17 から .126 の範囲で指定
(VyControl で操作させるための) HTTP API の有効化
- API のアクセスキーを my_secret_key (任意の文字列) に設定

このため、 VyOS のコンソールでログインし、以下のコマンドを入れる。

vyos@vyos:~$ configure
vyos@vyos# set interfaces ethernet eth0 address '192.168.11.254/24'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' default-router '192.168.11.254'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' name-server '192.168.11.254'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' range 0 start '192.168.11.17'
vyos@vyos# set service dhcp-server shared-network-name 'subnet01' subnet '192.168.11.0/24' range 0 stop '192.168.11.126'
vyos@vyos# set service https api keys id my_id key 'my_secret_key'
vyos@vyos# set service https certificates system-generated-certificate lifetime '65535'
vyos@vyos# set service https virtual-host vyos1 listen-address '192.168.11.254'
vyos@vyos# set service https virtual-host vyos1 listen-port '6443'
vyos@vyos# set service https virtual-host vyos1 server-name 'vyos1.example.com'
vyos@vyos# commit
vyos@vyos# save
vyos@vyos# exit

これで、 VyOS 側の設定は完了だ。

VyControl の起動

GNS3 GUI 上で、テンプレート一覧から VyControl をドラッグ＆ドロップして、プロジェクトに追加する。

スイッチングハブか何かを間に咬ませて（2デバイスを繋ぐだけなら無くても良いけど）、 VyOS と VyControl を結線する。

デバイスアイコンの右クリックで Edit config をクリックして、コンテナの /etc/network/interfaces を編集する。

# DHCP config for eth0 の部分のコメントアウトを外せば、 VyOS の DHCP から IPアドレスを取得するようになる。

その後、デバイスアイコンの再度右クリックで Start を選択し、コンテナをスタートさせる。
デバイスアイコンをダブルクリックすると、コンテナ内にフォワードされるアドレスがブラウザ側で開く。

VyControl の初期設定

VyControl の初回アクセス時は、管理者アカウントを作るように表示されるので、適当なユーザー名とパスワードで作成しておく。

そして、 VyControl のコントロール対象の VyOS インスタンス情報を設定してやる。

Router の Interfaces 情報を開き、 VyOS ルーター側の interface 一覧が表示されていれば、設定は完了だ。

以上で、 VyControl から VyOS が操作できるようになった。

トラブルシューティング

VyOS 起動時に `KVM acceleration cannot be used` と出る

VyOS 起動時に、以下のようなエラーが出て起動に失敗するケース。

text/plain KVM acceleration cannot be used (/dev/kvm doesn't exist). It is possible to turn off KVM support in the gns3_server.conf by adding enable_kvm = false to the [Qemu] section.

① 環境導入編で触れていた、「入れ子になった（ネストされた）仮想化」が機能しておらず、 GNS3 VM の中で更に、 KVM という仮想化支援機能を使用して二重の仮想化にて VyOS を起動するのに失敗している。
GNS3 VM を開くと以下のように "KVM support available: True" となるべきところが "False" となっていると思われる。

まずは、 OS のバージョンや CPU, 仮想化管理ツールのバージョンが、ネストされた仮想化をサポートしているかをもう一度確認しよう。

しかし、 CPU や仮想化管理ツールの組み合わせによっては、どうしても有効化できない場合がある。

そういった場合は、動作速度は遅くなるが KVM による仮想化支援機能を無効化してしまう方法もある。

まず、 VM管理ツールや ssh で GNS3 VM の管理画面に入る
メニューから Configure を選択する
以下の内容を追記し、 Ctrl+X で保存、その後 GNS3 VM を再起動する。
```
[Qemu]
enable_kvm = false
```

ただし、 VyOS の動作速度がかなり落ちるので注意。

次回

最後となる次回は応用編。

GNS3 に VyOS 仮想ルーターを追加する長い道のり② イメージ準備編

2022-12-28T23:43:42+09:00

本記事は【アットホームな現場です】🎄★☆ネットワーク系エンジニア★☆アレコレアウトプット★☆🎄 Advent Calendar 2022 15日目の記事だ。（空いていたので埋め）

GNS3 という OSS のネットワークエミュレータを、 Cisco の IOS などの取得なしに、無料のライセンス内で利用できるようにしようという話。

前回の環境導入編に続く第2回。
https://crieit.net/posts/GNS3-VyOS

GNS3 のインストールと GNS3 VM へのアタッチが完了している状態から始める。

VyOS イメージの取得

GNS3 のマーケットプレイスには、 VyOS のテンプレートが用意されており、これを使うと手軽に GNS3 内で VyOS のルーターを追加できる。

このテンプレートを使うためには、 VyOS の特定のバージョンの ISO イメージファイルが必要だ。
しかし、 VyOS の LTS 版では、ビルド済みイメージのダウンロードは、サブスクリプション契約者（または非営利団体など）のみとなっている。
https://docs.vyos.io/en/equuleus/installation/install.html#download

一方で、 VyOS 自体は OSS であり、 GPL のライセンスを守る限りソースコードを自由にビルドして利用できる。そのビルド自体も docker を利用したツールセットが用意されていたりと、比較的しっかり整備されていて失敗しにくい。
あまり性能が高くないノートPC でも 10分程度でビルド可能だ。

VyOS イメージを自分でビルド

このため、マニュアルの Build 手順に従って VyOS 1.3 を自分でビルドしてイメージファイルを作成しよう。

そのビルドには、前回インストールした Docker が必要となる。
加えて、 Docker は WSL2 内のディストリビューションから利用する必要がある。
Docker 自体は、 Windows のシェル (コマンドプロンプトや PowerShell) から直接起動できるが、今回行う作業では Windows と Linux のファイルシステム違いによる問題で、ビルドが失敗してしまうためだ。

というわけで、前回 WSL Integration を有効にした、適当な WSL2 ディストリビューション (Ubuntu 22.04.1 LTS など) を起動する。
適当な空のフォルダをカレントフォルダに設定し、以下のように実行する。

git でビルドスクリプトを clone して、 docker でビルド環境を起動する

$ git clone -b equuleus --single-branch https://github.com/vyos/vyos-build.git
$ cd ./vyos-build/
$ docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos vyos/vyos-build:equuleus bash

docker コンテナに入ったら、以下のコマンドでビルドする。

vyos_bld@xxxx:/vyos# ./configure --architecture amd64 --build-type release --version 1.3.2
vyos_bld@xxxx:/vyos# sudo make iso

ビルドが成功すれば、 build ディレクトリに .iso ファイルが出力されているはずだ。ホスト PC 側から WSL2 内のビルドディレクトリを開き、ホスト PC にコピーする。
- \\wsl$\\... のネットワークパスで、ホスト PC側から WSL2 のファイルを参照できる。

ちなみに、このビルド手順に関しては、プロキシ環境下ではどうしてもうまくビルドができなかった。
ビルドスクリプトが、プロキシ環境下のことをあまり考慮していないのだと思われる。

VyOS イメージの野良ビルドを取得する

もし自分でイメージのビルドができなかった場合…

GPL のライセンス上、ビルドしたイメージを再配布することも再配布されたビルドを利用することも、ライセンスを守る限り問題は無い。
このため、 VyOS の LTS版のビルドを公開している人がいるので、それを取得して利用することもできる。

→ Releases · 9l/vyos-build-action

GitHub Actions でビルドされており、比較的信頼できそうなイメージではあるが、 VyOS 以外の第三者によるもので何か余計な物が仕込まれているリスクは上がるので、利用に関しては自己責任で。

最初からこれを紹介しとけよって？まぁまぁ、自分でビルドできるならそれに越したことはないし。

VyOS のテンプレートを GNS3 に取り込み

GNS3 のマーケットプレイス Appliances から VyOS のテンプレート (vyos.gns3a) をダウンロードする。
GNS3 GUI の [File]->[Import appliance] メニューから、ダウンロードした vyos.gns3a を取り込む。
取り込み先をどこにするか聞いてくるので、 GNS3 VM を選択する。（これまで手順通りなら、他の選択肢はグレーアウトされているはず）
GNS3 VM 内で VyOS を動かす仮想マシン (入れ子の VM) をどれにするか選択する。デフォルトの選択で問題ないはず。
必要なファイルをインポートする。
1. まず、 empty8G.qcow2 を選択し、 [Download] をクリックすると、自動的に sourceforge.net のダウンロードページに飛ばされるので、それをダウンロードする。
2. [Import] ボタンで、 ↑ でダウンロードされたファイルを選択すれば、 "Found on GNS3 VM" と表示が変わる
3. vyos-x.x.x-amd64.iso のほうは、 "Allow custom files" のチェックボックスにチェックをつけてからインポートする。これは、セルフビルドや野良ビルドをインポートする際に、公式提供の .iso とファイルハッシュが異なるために、エラーとなるのを回避するためだ。
  
  [Import] ボタンから .iso ファイルをインポートすると MD5 チェックサムが異なると怒られるが、それでもインポートを続行させる。
Ready to install 表記に変わったら、その version を選択して、 Next をクリックする。
- 他のバージョンの VyOS を用意する場合は、インポートの動作を繰り返す。

これで、 GNS3 で VyOS を利用する準備が整った。

VyControl Docker イメージを GNS3 に取り込み

VyOS を操作するフロントエンドとなる VyControl を、 Docker で導入する。

公式で用意されている robertoberto/vycontrol イメージを入れれば良い… と言いたいところなのだが、別途用意した advanceboy/vycontrol-host のイメージを使う。

GNS3 で vycontrol コンテナがホストする HTTP サーバーを操作する際、 GNS3 がフォワーディングしてくれので、ホスト側のブラウザを使用する。
ところが、 vycontrol の公式イメージは 127.0.0.1 以外でのアクセスを禁止しているので、フォワーディングされたアドレスで UI に入ることができない。

そこで、 ALLOWED_HOSTS という環境変数経由でアクセスに使える IPアドレスを指定可能に改造したイメージを使用する。
https://github.com/advanceboy/vycontrol-host

GNS3 の [Edit]->[Preferences] から "Docker container templates" の設定を開き、 [New] をクリック。
Docker コンテナを実行する場所をどこにするか聞いてくるので、 GNS3 VM を選択する。（これまで手順通りなら、他の選択肢はグレーアウトされているはず）
New image の Image name に、先ほどの advanceboy/vycontrol-host:latest のイメージ名を設定する。
- ちなみに、 GNS3 VM のシェル側で docker pull をあらかじめ実行しておけば、 "Existing imases" の選択肢に現れるようになる。
Template name は、適当にわかりやすい名前で。 Adapter 数は 1 で OK。 Start Command も空でよい。
Console type を "http" に設定する。
Environment で、 ALLOWED_HOSTS=* を設定して、コンテナテンプレートの設定を完了させる、
"Docker container templates" の設定から [Edit] で詳細設定画面を開き、 "HTTP port in the container" を 8000 に設定する。
更に、 Advanced タブに移動して、コンテナの永続化パスに /code/db.sqlite3 を追加する。

これで、 GNS3 で VyControl を利用する準備が整った。

ついでに、 curl などが利用できる buildpack-deps:stable-curl イメージあたりも追加しとくと便利かもしれない。

次回

次回は、いよいよ GNS3 で VyOS を実行する。

GNS3 に VyOS 仮想ルーターを追加する長い道のり① 環境導入編

2022-12-23T23:58:54+09:00

本記事は【アットホームな現場です】🎄★☆ネットワーク系エンジニア★☆アレコレアウトプット★☆🎄 Advent Calendar 2022 8日目の記事だ。（空いていたので埋め）

GNS3 という、オープンソースのネットワークエミュレータがある。

GUI 上で、様々なネットワーク機器を仮想環境に設置して、仮想ネットワークを構築できる、大変優れたツールだ。

実際に、ルータや端末を沢山用意して物理的に結線せずとも、 PC 上で簡単にネットワークを作成できるので、ネットワークの勉強の為に、いわゆるネットワークラボ環境を準備には最適だ。

しかし、一つ大きな問題がある。
GNS3 自体には、基本的なハードウェアのエミュレータしか含まれていないため、ルーターなどを使うには、 "Cisco の IOS" といった「ルーターのソフトウェア」を別途用意しなくてはならない。

すでに Cisco のルーターを持っていて、 IOS イメージなどが手に入るならよいのだが、そうではない場合合法的にこういったイメージを入手するのは（主に金銭的な意味で）厳しい。

ネットワークの検証や勉強をする目的であれば、何も Cisco のルーターでなくとも、使う分には問題ないはずだ。

…ということで、 VyOS という OSS のネットワークデバイスを、 Windows 上の GNS3 で使えるようにするまでの長い道のりを、数回に分けて紹介しようと思う。

とりあえず、今回は環境導入編。

OS

実行する Windows のバージョンは、 CPU が Intel なら Windows 10 で問題ないが、 CPU が AMD (Ryzen/Epic) の場合 Windows 11 以上が望ましい。
これは、入れ子になった（ネストされた）仮想化による仮想マシンのサポートが、 OS 側に必要であるためだ。
(一応、 AMD のサポートは Windows 10 Build 19640 以上となっているが、このバージョンはプレビュービルドしか存在しない)

一応、上記を満たしていなくても動作させることは可能だが、内部で仮想化支援機能が働かないので、 VyOS の動作が著しく遅くなる。

ちなみに、 ARM Windows はそもそもサポートされない。

VyOS と VyControl

VyOS とは、オープンソースのネットワーク機器向けの OS で、 Linux をベースとしたディストリビューションである。

ルーティングからファイアウォール、パケットフィルタから負荷分散まで、商用ルータに劣らない様々な機能を持っている。

VyOS の設定は、基本的に専用のコマンドを用いて行うのだが、最初からそれを学ぶのは学習コストが高い。
そこで、 VyControl という VyOS 向けのシンプルな GUI フロントエンドと組み合わせるところまで、構築していきたいと思う。

環境構築に必要なもの

しかし、 GNS3 上で VyOS を利用できるようにする道のりは長い。

まず、 VyControl を使うためには、 VyOS 1.3 以上が必要となる。
実は、ビルド済みの安定板の VyOS イメージは、サブスクリプション契約をしないとダウンロードできない。

VyOS 自体は、前述のとおり OSS なのでソースコードを自由に取得できる。
そのビルド自体も docker を利用する仕組みがしっかりと用意されおり、環境依存なども少なく失敗しにくい。
あまり性能の高くないノートPCでも、 10分程度でビルド可能だ。

Windows 上で VyOS 1.3 のイメージをビルドするには、 WSL2 と Docker (Docker Desktop または Rancher Desktop) が必要だ。
Docker Desktop を使えば、 Windows のシェルから直接 Docker を起動できるが、ファイルシステムの問題でビルドエラーになるため、 WSL が必要となる。

また、 GNS3 を Windows 上で使うには、別途 VirtualBox などの仮想マシン管理ツールが必要となる。 ¹
以降、無料で使用できる VirtualBox での利用方法を中心に説明するが、他の仮想マシン管理ツールを利用する場合は適宜読み替えていただきたい。

GNS3 は、この VirtualBox の中に "GNS3 VM" という仮想マシンを作成し、その中でさらに QEMU の仮想マシンや、 docker コンテナ (※) を作成し、ネットワークをエミュレーションを行うのが、基本的な仕組みとなる。

※: VyOS のビルドに使用した docker とはまた別の環境。

…とまあ、いろいろツールの名前が出てきたが、これらの構成をまとめると、以下の図のようになる。

これらを順にインストールしていこう。

なお、このうち WSL2 と Docker Desktop については、 VyOS の ISO イメージのビルドを自分でせず、野良ビルドを使う場合はインストール不要だ。 (詳しくは次回②に記載)

WSL2

WSL のインストール | Microsoft Learn
のページの内容に則り、以下の手順でインストールする

PowerShell または Windows コマンドプロンプトを管理者モードで開く
以下のコマンドを入力して PC を再起動する
```
wsl --install
```
以下のコマンドで、 WSL で作成される WSL バージョンを WSL2 を規定にする。
```
wsl --set-default-version 2
```
Microsoft Store などから、適当な WSL ディストリビューション (Ubuntu 22.04.1 LTS など) をインストールする

Docker Desktop

Docker Desktop のインストーラを取得し、ウィザードに従ってインストールする。

インストール後、設定から WSL Integration を有効にする。

もし、ライセンス的に Docker Desktop が使いづらい環境なら、以下の Rancher Desktop の手順を参照。

https://aquasoftware.net/blog/?p=1703

VirtualBox

VirtualBox で、 Version 6.1 以上を取得して、ウィザードに従ってインストール。

こちらは特に気を付けるべきことはなかったと思う。

GNS3

GNS3 本体のインストール

GitHub の gns3-gui プロジェクトのリリースページから、最新バージョンの

GNS3-*-all-in-one.exe

をダウンロードし、実行する。

インストールするコンポーネントを選択するところで、

GNS3 Desktop
GNS3 VM

の2つだけを選択してそれ以外の選択を（外せる物は）全て外す。 ²

ウィザードを進めると、 GNS3 の VMタイプを選ぶ場面になるので、 VirtualBox を選択する。

そのままインストールを進め、初回起動の段階で一旦休憩。

GNS3 VM のインポート

次に、インストール途中で "ダウンロード" フォルダあたりにダウンロードされていた、 GNS3.VM.VirtualBox.*.zip を解凍して GNS3 VM.ova を取り出す。 ³

VirtualBox を起動し、この GNS3 VM.ova を「仮想アプライアンスのインポート」にて、 "GNS3 VM" という名前でインポートする。

その後、 PowerShell を立ちあげ、以下のコマンドを実行する。
これにより、前述の入れ子になった（ネストされた）仮想化による仮想マシンの機能が有効化される。 ⁴

$env:Path += ';' + 'C:\Program Files\Oracle\VirtualBox\';
VBoxManage.exe modifyvm 'GNS3 VM' --nested-hw-virt on;

GNS3 上の VM の設定

GNS3 の初回起動に戻ると、 GNS3 のネットワークシミュレーションをどのように実行するか選択肢が出てくる。

The GNS3 VM option is strongly recommended on Windows and Mac OSX.

と書かれているように、 Virtual Machine を選択する。

Local server の設定はデフォルトのままで良い。この設定を使って、 GNS3 VM で動くサービスがホストされ、 GNS3 GUI がそのサービスと通信することでツールが動作する仕組みとなる。

改めてもう一度 GNS3 VM がどの仮想マシンマネージャーを使うか効いてくるので、 VirtualBox を選択する。

vCPU や RAM のサイズ (特に前者) は、ホスト PC のリソースが許す限り豊富に設定しておいた方が良い。

GNS3 起動後、 [Edit]->[Preferences] の [GNS3 VM] の設定でも、もう少し細かい GNS3 VM の設定ができる。
"Run the VM in headless mode" や "Action when closing GNS3: suspend the GNS3 VM" あたりの設定は ON にしておいた方が便利。

正しくセットアップできていれば、 GNS3 起動後暫くしたら、 Servers Summary ウィンドウの GNS3 VM がグリーンになっているはずだ。

GNS3 VM 側の設定

VirtualBox 側で立ち上がった GNS3 VM を開くと、以下のように VM 情報が表示されている。

この画面 (TUI) を直接操作したり、画面に書かれているアドレスやパスワードで ssh することで、 GNS3 VM 内部のより細かい設定ができる。

例えば、プロキシ環境下でプロキシの設定が必要な場合、以下の 2カ所の設定を行う。

VM 情報のページから [OK] -> メニューで [Proxy] と選択し、 http://203.0.113.99:8080 と言った形で指定する。
- VM 内からホストPCで設定されている DNS は見れず、 DNS は 8.8.8.8 や 8.8.4.4 が決め打ちされている。イントラネット内の名前解決はできないので、プロキシがイントラネット内なら、ホスト名では無くて IPアドレスで指定する方が良い。

メニューで [Shell] を選択して以下のように実行し、 docker デーモン (dockerd) にもプロキシの設定を反映させる。

gns3@gns3vm:~$ sudo mkdir -p /etc/systemd/system/docker.service.d
gns3@gns3vm:~$ sudo tee -a /etc/systemd/system/docker.service.d/http-proxy.conf /dev/null
[Service]
Environment="HTTP_PROXY=$http_proxy"
Environment="HTTPS_PROXY=$https_proxy"
EOF
gns3@gns3vm:~$ sudo systemctl daemon-reload
gns3@gns3vm:~$ sudo systemctl restart docker
gns3@gns3vm:~$ cat  ~/.docker/config.json
{"proxies":{"default":{"httpProxy": "$http_proxy","httpsProxy": "$https_proxy","noProxy": "127.0.0.0/8"}}}
EOF

GNS3 から VirtualBox を操作する部分の作り込みが甘いのかもしれないが、 GNS3 VM が再起動されると GNS3 から VM を正常に操作できなくなってエラーが起きがちだ。
このため、一通り GNS3 VM の設定が終わったら、 GNS3 (GUI) 側を再起動したほうが良い。

次回

次回は、 GNS3 に入れる VyOS イメージのビルドと、 GNS3 に VyControl のコンテナを準備する。

VirtualBoxではなくHyper-Vなども使えることは使えるが、仮想NICの扱いの仕組み上Hyper-Vだと若干ややこしい。（GNS3 VMのIPアドレスが毎回わかるとか、VPN環境下で使いにくいとか） ↩︎
GNS3は、VMではなくホストPC上で直接ネットワークをエミュレートする方法もあり、そういった場合にTool以下のソフトが必要になるのだが、今回はVM上でエミュレートしているので、これらの殆どはホストPC側にインストールする必要が無い。強いて言うならNPCAPとWiresharkはインストールしても良いかも。 ↩︎
ダウンロードし間違えたり、どこにダウンロードされたかわからない場合、前述のリリースページから手動でダウンロード可能。 ↩︎
Hyper-Vの場合は、GNS3.VM.Hyper-V.*.zip内のinstall-vm.batのバッチを実行すれば、自動的にネストされた仮想化が有効になる。 ↩︎

Vagrant で Temporary failure resolving となる問題の解決 - イントラネット DNS 編

2021-05-19T09:57:20+09:00

Vagrant で Ubuntu の VM を立ち上げたとき、 apt 等を行おうとすると、以下のようなエラーに遭遇した。

client: Err:1 http://security.ubuntu.com/ubuntu focal-updates/main amd64 libjpeg-turbo8 amd64 2.0.3-0ubuntu1.20.04.1
client:   Temporary failure resolving 'proxy.local.example'

上記のエラーの内容はプロキシに接続できないというものだが、問題のポイントはプロキシかどうかはあまり関係が無く、名前解決に失敗しているという部分だ。
こういうのはだいたい systemd-resolved のスタブリゾルバ周りの問題だと相場が決まっている。

…ということで、順番に確認しながら問題を解決していこう。

なお、使った box は generic/ubuntu2004 で、 VirtualBox で VM をホストしている。

スタブリゾルバの確認

まず、 resolv.conf を確認してみる。

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
nameserver 127.0.0.53

テキストファイルのコメントに書いてあるとおり、コイツを書き換えるのは悪手。

ネームサーバーが 127.0.0.53 を指しているが、これが systemd-resolved のスタブリゾルバだ。

ここで言うリゾルバとは、ドメイン名を元にIPアドレスを解決する仕組みのことを指していて、 DNS なども同様の機能を持っている。
その中でも、スタブリゾルバは、（「スタブ」と言うだけあって、）それ自身はドメイン名とIPの対応リストを持たずに、 DNS 等の他のリゾルバを呼び出して解決する仕組みをもっている、ローカルのサービスだ。
ローカルアプリケーションが直接 DNS を参照せず、一旦スタブリゾルバを参照することで、 systemd で管理された適切な DNS を自動的に参照されるようになったり、 DNS では解決できない hostname.local といったホスト名ベースの名前解決 (mDNS) を行えるようになっている。

さて、そのスタブリゾルバがどう動いているか resolvectl status で確認してみよう。

$ resolvectl status
[...]
Global
  Current DNS Server: 4.2.2.1
         DNS Servers: 4.2.2.1
                      4.2.2.2
[...]
Link 2 (eth0)
      Current Scopes: DNS
    DNSSEC supported: yes
  Current DNS Server: 4.2.2.1
         DNS Servers: 4.2.2.1
                      4.2.2.2
                      208.67.220.220
                      10.0.2.3

4.2.2.1 や 208.67.220.220 などが DNS に設定されているのがわかる。
これらは、いわゆるパブリックDNSだ。

実は、先ほど名前解決できなかったプロキシは、 LAN 内のサーバーだった。このため、パブリックDNSに問い合わせられてしまっては、名前解決ができないのも当然だ。

パブリックDNS はどこで設定されているのか

名前解決に失敗する理由はわかった。しかし、この DNS はどこで設定されているのか？

ざっと確認してみたところ、 resolved.conf の設定と、仮想マシン内の NAT を繋いだ NIC の netplan 設定に、それっぽい設定が書かれていた。

$ cat /etc/systemd/resolved.conf 
[Resolve]
DNS=4.2.2.1 4.2.2.2 208.67.220.220

$ cat /etc/netplan/01-netcfg.yaml 
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true
      dhcp6: false
      optional: true
      nameservers:
        addresses: [4.2.2.1, 4.2.2.2, 208.67.220.220]

これらは通常の Ubuntu のインストールプロセスでは設定されないので、 generic/ubuntu2004 の box の作成者の味付けなのだろう。

これらの DNS のアドレスの設定を、プライベートネットワーク内の DNS のアドレスに書き換えてしまえば、きっと意図した動作に近づくはずだ。

スタブリゾルバを使わずに LAN内の DNS を指定する

スタブリゾルバは、細かい優先度合いの制御などを外から行えない。これはネットワークの状況に応じて最適調整してくれる設計だからなのだが、 Vagrant で立ちあげる VM のように、 NAT の DNS やローカルの DNS が混在していると、うまく調整できずに、こういった問題の解決がやりにくい。

スタブリゾルバを動かしているままでも問題なく動いているのならそれでもかまわないのだが、上記の DNS の書き換えを行ってもどうも意図通りに名前解決されない場合は、 systemd-resolved のスタブリゾルバを使わずに、 /etc/resolv.conf の nameserver を切り替えるようにしたい。

具体的には、 /etc/resolv.conf が ../run/resolvconf/resolv.conf へのシンボリックリンクになっているところ、 ../run/systemd/resolve/resolv.conf へのシンボリックリンクに書き換える。
こうすることで、 resolved.conf や netplan で設定した DNS が直接 /etc/resolv.conf の nameserver に書かれるようになる。
詳しくは、 systemd-resolved.service のマニュアルあたりを見て欲しい。

…と、このような書き換えを、 Vagrantfile の定義に書き落とすと、以下のようになる。
なお、以下は 192.168.11.1 がローカルネットワークの DNS のアドレスである場合の例なので、適宜書き換えていただければと。

config.vm.provision :shell, inline: <<-'SHELL'
    ln -sf ../run/systemd/resolve/resolv.conf /etc/resolv.conf
    sed -i -E '/nameservers:/{n; s/(addresses:).*/\1 [192.168.11.1]/}' /etc/netplan/01-netcfg.yaml
    netplan apply
    sed -i -E 's/(^\s*DNS\s*=\s*).*$/\1192.168.11.1/' /etc/systemd/resolved.conf
    systemctl restart systemd-resolved.service
SHELL

そうすると、 resolv.conf の中身が以下のように netplan の設定などから求められた DNS に置き換えられ、スタブリゾルバを経由せずに名前解決されるようになる。

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
nameserver 192.168.11.1
nameserver 10.0.2.3

このようになれば、ローカルの DNS でキチンと名前解決されるようになるだろう。

Windows Server の CertReq で作成した CSR の文字化けを回避する

2021-05-04T11:55:50+09:00

Windows Server の certreq.exe を使って、 https 等を目的にサーバー証明書署名要求 (CSR) を作成した際に、その CSR や署名後の CER で、サブジェクト字が文字化けしてしまう場合がある。

この問題は、 certreq.exe にて、テキストファイル (.inf ファイル) から CSR を作成した場合に発生する。

そしてこれは、 .inf ファイルを BOM付き UTF-16 LE で保存すれば解決する。
(BOM付き/BOMなしの UTF-8 には対応していない)

Windows のメモ帳であれば、文字コードを Unicode に設定すれば、 OK だ。

対処法は単純だが、原因が少しややこしかったので、少し深堀りしてみる。

CSR が文字化けする要因

そもそも、文字化けする要因は以下の3カ所あった。

.inf ファイルが ASCII (Shift_JIS) で保存すると Unicode の情報が失われる
certreq.exe が .inf ファイルの文字コードの解決に失敗する
X.509 の文字列のエンコードが UTF-8 が指定されていない

(1) はまぁわかりやすいだろう。
テルグ文字や絵文字など、 Shift_JIS に存在しない Unicode の文字が文字化けするのは、これが原因だ。

ところが、古い Windows Server (2012 あたりとか) だったり、 .inf の内容によっては、非 Shift_JIS 文字だけでなく、非Ascii 文字 (上のスクショで言うと "京都府" のあたり) も文字化けする場合がある。
これは (1) だけでは説明がつかない。

(2) については、 .inf ファイルが Shift_JIS や UTF-8 で保存されていると、 certreq.exe が文字コードの解決を誤ってしまう場合があるのが原因だ。
おそらく、 OS のロケールなどを見て、 BOM付き UTF-16 LE ではないファイルが .inf ファイルに渡されたときの挙動が決まるのだと思われる。

この問題も、 .inf ファイルを .inf ファイルを BOM付き UTF-16 LE で保存すれば、文字の解釈が明確になるので、文字化けしなくなる。

なお、 (3) については、現行のサポート中の OS では気にする必要はないだろう。古い OS だと、 HTTPS サーバー証明書の規格である X.509 で、扱う文字列を UTF-8 で記述するバージョンに対応していない可能性がある。

サーバー証明書のサブジェクトに顔文字を入れる

試しに、以下のような内容の request.inf ファイルを、 BOM付き UTF-16 LE で保存して、 certreq.exe で CSR ファイルを作成してみよう。

[NewRequest]
Subject = "CN=(´◉◞౪◟◉); OU=🥺; O=aquasoftware.net; L=京都市; ST=京都府; C=JP; [email protected]"
X500nameflags = "CERT_NAME_STR_SEMICOLON_FLAG"
KeyLength = 3072
KeySpec = AT_KEYEXCHANGE
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_ENCIPHERMENT_KEY_USAGE"
HashAlgorithm = sha256
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

[Extensions]
2.5.29.17="{text}"
_continue_ = "DNS=aaa.example.com&"
_continue_ = "DNS=bbb.example.com&"
_continue_ = "IPAddress=192.0.2.1&"
_continue_ = "IPAddress=192.0.2.2"

PS> certreq.exe -new .\request.inf .\csr.req

CertReq: 要求が作成されました

.inf ファイルの書き方については、 certreq | Microsoft Docs のドキュメントを参照のこと。
いくつか特徴的な部分について解説しておくと、

Subject 内のパラメーターに "," が使えるよう、 X500nameflags に CERT_NAME_STR_SEMICOLON_FLAG を指定して、区切りを ";" に変更している。
OID=1.3.6.1.5.5.7.3.1 の部分では、「拡張キー使用法」に「サーバー認証」の仕組みを与えている。
[Extensions]2.5.29.17=... の部分では、 SubjectAltName (SAN) に、 DNS や IpAddress を指定している。 SAN の指定がないと、 Chrome で証明書エラーになってしまうため。

これを CA で署名してもらってサーバー証明書として使えば、サーバー証明書内で絵文字ですら使えるようになる。

VPN に繋ぐと WSL2 や Hyper-V VM でネットワークに繋がらなくなる問題を解消する

2021-01-27T09:33:58+09:00

OpenVPN や Cisco AnyConnect, GlobalProtect 等といった VPN に接続した際、 Hyper-V 仮想マシン内からや、 WSL2 のディストリビューション内、 Windows Sandbox 内、 WSL2 ベースの Docker コンテナ内等々、 Hyper-V 系の技術を使った仮想環境から、 PC 外のネットワークにアクセスしようとすると、以下のようなエラーが発生して失敗する。

$ # curl 利用時の例
curl: (6) Could not resolve host: example.com
curl: (5) Could not resolve proxy: proxy.example.com

$ # apt で更新しようとした場合の例
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'proxy.example.com'

エラーの内容からわかるとおり、アクセス先やプロキシーのドメイン名を DNS で解決できなくなっている。

このような問題が発生することは以前から知っていたのだが、このご時世で VPN 使うことが増えてきて、いい加減鬱陶しくなってきたので、なんとかしようと思う。

解決方法

とりあえず、まずは解決方法から。

以前は AnyConnect でもこの方法が使えたはずなのだが、どうやら対策されて打つ手なしになってしまった模様。
今のところ、以下の方法で回避の確認が取れているのは、 GlobalProtect のみだ。

WSL2 の場合は何らかの WSL2 を使ったディストリビューションを立ち上げる。
- WSL 2 based engine が有効になった Docker Desktop を起動するだけでも OK。
- WSL2 を使っていないなら、何もする必要はない。
VPN を接続状態にする。
管理者権限で Windows PowerShell を立ち上げ、以下のコードを実行する。 (GlobalProtect の例)
```
$targetIfName = 'PANGP Virtual Ethernet Adapter';
# define function
function Get-NetworkAddress {
    param([Parameter(Mandatory, ValueFromPipelineByPropertyName)][string]$IPAddress, [Parameter(Mandatory, ValueFromPipelineByPropertyName)][int]$PrefixLength);
    process {
        $bitNwAddr = [ipaddress]::Parse($IPAddress).Address -band [uint64][BitConverter]::ToUInt32([System.Linq.Enumerable]::Reverse([BitConverter]::GetBytes([uint32](0xFFFFFFFFL -shl (32 - $PrefixLength) -band 0xFFFFFFFFL))), 0);
        [pscustomobject]@{
            Addr = $IPAddress;
            Prfx = $PrefixLength;
            NwAddr = [ipaddress]::new($bitNwAddr).IPAddressToString + '/' + $PrefixLength;
        };
    }
}
# extend route metric
$targetAddresses = Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -Match 'Hyper-V Virtual Ethernet Adapter' | Get-NetIPAddress -AddressFamily IPv4 | Get-NetworkAddress;
$targetIfs = Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -Match $targetIfName;
$targetIfs | Set-NetIPInterface -InterfaceMetric 2;
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $_.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $_.Prfx).NwAddr } } | Set-NetRoute -RouteMetric 6000;
```
- GlobalProtect 以外の場合は、上記コード一行目の 'PANGP Virtual Ethernet Adapter' のところを VPN ソリューションのネットワーク接続アダプタ名に書き換える。
  具体的には、 Win+R で ncpa.cpl を実行して「ネットワーク接続」を開き、該当する VPN の接続のプロパティを開いて、 "接続の方法" のところに書かれた名前 (の一部) を指定する。
  - OpenVPN なら TAP-Windows Adapter とか、 AnyConnect なら Cisco AnyConnect とか。環境によっても違うかも。
- 管理者権限の PowerShell は、スタートボタンを右クリックで簡単に立ち上げられる。
- 1回の実行で成功しない場合、 上記コードの最後の行 を、ルートメトリックが書き換わるまで何度もしつこく実行する。
  - ルートメトリックが書き換わっていない状態の例:
    
```text/plain
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $.Prfx).NwAddr } }

ifIndex DestinationPrefix NextHop RouteMetric ifMetric
------- ----------------- ------- ----------- --------
36 172.30.175.255/32 0.0.0.0 0 0
36 172.30.160.1/32 0.0.0.0 0 0
36 172.30.160.0/20 0.0.0.0 0 0
20 172.18.31.255/32 0.0.0.0 0 0
20 172.18.16.1/32 0.0.0.0 0 0
20 172.18.16.0/20 0.0.0.0 0 0
```
  - ルートメトリックの書き換えに成功した例:
    
```text/plain
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $.Prfx).NwAddr } }

ifIndex DestinationPrefix NextHop RouteMetric ifMetric
------- ----------------- ------- ----------- --------
36 172.30.175.255/32 0.0.0.0 6000 0
36 172.30.160.1/32 0.0.0.0 6000 0
36 172.30.160.0/20 0.0.0.0 6000 0
20 172.18.31.255/32 0.0.0.0 6000 0
20 172.18.16.1/32 0.0.0.0 6000 0
20 172.18.16.0/20 0.0.0.0 6000 0
```
上記を、 PC を再起動したり、 VPN を接続しなおす度に、毎回実行する。

解説

上記のコードは、 VPN プロバイダがホスト PC に作成しているルーティングの設定のうち、 Hyper-V や WSL に関係する宛先ものだけ、ルーティングのメトリックをめっちゃ長くしている。

Hyper-V や WSL のネットワークの仕組みに簡単に触れながら、もう少し細かく説明していこう。

Hyper-V と WSL2 の NAT

まずそもそもの前提として、 ホストPC と WSL2 の仮想環境で異なる IPアドレスを持っている。
利便性のため、 WSL2 の localhost のリッスンが、ホスト PC の localhost へ転送されているなど、 IPアドレスが異なることをあまり意識せずすむような仕組みにはなっているけれども。

そしてその WSL2 や、 Hyper-V の VM では、 PC の外と通信する際に NAT を経由して通信を行う仕組みがメインとなる。

このとき、 Hyper-V や WSL2 のバックエンドとなる Hyper-V ハイパーバイザーは、ホスト PC 上に仮想 NIC を作成する。
そしてその仮想 NIC に、 WinNAT と呼ばれる機能を割り当て、更に WSL2 向けには DNS の機能も割り当てて、ホスト PC の外との通信の中継を担わせるようになっている。

これら、仮想 NIC や、 WSL2 に自動で割り当てられる IP アドレスは、ホスト PC と被らない適当なプライベート IP アドレスが割り当てられる。

なお、 やっかいなことに、この割り当てられた IP アドレスは、起動する度に毎回異なる。

VPN 側の動作

一方のソフトウェア VPN では、 VPN の有効化と同時に、ホスト PC のルーティングを片っ端から書き換えている。

具体的には、 VPN の仮想 NIC に対して短いメトリックとなるよう、ルーティングを書き加える。
それによって、全ての通信が VPN トンネルを通るようになっているのだ。

そして悲劇が起こる

その結果、どうなるか。

ホスト PC からゲスト VM (あるいは WSL ディストロ) のプライベート IPアドレスへ通信しようとすると、 VPN のトンネリング側にルーティングされてしまう。

例えば、 WSL2 からホストPC へ DNS の問い合わせ (クエリ) を受けると、そのレスポンスが明後日の方向にルーティングされてしまう。
これが、 ゲスト側で DNS による名前解決ができなくなる原因だ。

この問題を回避するため、前述のスクリプトでは、ルーティングテーブルを書き換えて、ゲスト VM のアドレスに対して、 VPN の仮想NIC のメトリックを長くすることで、 VPN にルーティングされないようにしているわけだ。

本当は、 VPN へのルーティングを消してしまいたいところなのだが、ルーティングを消しても、 VPN クライアントが即座にルーティングを復活させてしまうため、メトリックを長くするだけにとどめている。

なお、 GlobalProtect でも、書き換えたメトリックを戻される対策がされたようだが、インターフェースメトリックを書き換えたり、短期間に何度も書き換え直したりすると、メトリックを戻すことを諦めてくれる。
このため、上記のようなコードになっている。

WSL2 , problem with network connection when VPN used (PulseSecure) · Issue #5068 · microsoft/WSL | GitHub
ちなみに、上記の Issue ではもっと単純に、 WSL2 へのメトリックは 1 にして、全ての VPN 関係のルーティングのメトリックを 4000 くらいに延ばすワークアラウンドが紹介されている。
しかしそれだと、本来 VPN 経由にしなくてはならない通信までもが VPN 通らなくなったりする場合があって、 VPN を使わせるポリシー上マズい。
このため、上述のように、必要なネットワークアドレスだけに絞ってメトリックを書き換えている。

別解

Microsoft Docs 上の WSL のトラブルシューティングでは、 WSL の /etc/resolv.conf の DNS を、ホストPC の WinNAT ではなく VPN のトンネリング先のネットワークの DNS に書き換える方法も掲載されている。

……が、これを行うと、ゲスト側の DNS の名前解決こそできるようになるものの、依然ホストPC からゲストOS へのパケットが届かない問題は解消されない。
このため、ゲストで立てたサーバーに、ブラウザでアクセスしたり、 ssh 等でログインしたりと言ったことはできないままだ。

更に、イントラネット内で別途 DNS を運用していた場合、イントラネット内の名前解決ができなくなる問題もある。

このため、この DNS を書き換える方法は、望ましい解決方法とは言えない。

改訂履歴

2023-02-22:
- コードの一部でエラーが発生していた部分を修正。
2023-02-14:
- 各社のメトリック書き換え対策に対し、 GlobalProtect 向けにコードを変更し、 AnyConnect 向けには打つ手なしとなったことを追記。
2021-04-04:
- Windows Sandbox などでも問題となる旨追記
- いくつかの VPN ソフトについての設定例を追記
- Microsoft Docs 記載の改善方法について追記
2021-01-28:
- 仮想ネットワーク上に DHCP は存在しないのに、 DHCP の存在がすると誤記があったので修正。
- スクリプトで Hyper-V の仮想スイッチをさかす際に、 NIC 名ではなくて、ネットワークアダプタの接続名で探すように変更。

Raspberry Pi で作るネットワークエミュレータ

2021-01-01T05:43:33+09:00

明けましておめでとうございます。

この記事は、 Raspberry Pi Advent Calendar 2020 24日目の記事だ。
…遅刻すぎるのもいいとこだわ。

さて、ネットワーク回りの仕事をしていると、意図的にネットワークの遅延やパケロスを発生させて、検証したくなる状況がままある。

対象のサーバーにネットワークを遅延させるようなモジュール入れるようなやり方も考えられるが、もっと手軽に、 LAN ケーブルの間に挟むだけで、そこを通る通信が全て遅延するみたいな、そんな機材が欲しくなる。

もちろん、そのような需要があれば、それに応える製品があるわけで、それらは一般的に「ネットワークエミュレータ」として売られている。
しかし、高いものでは数百万を軽く超え、安くても数万円はするものばかりだ。

なんか安く作れないかなぁ…
Raspberry Pi あたりで。

…ということで、 Raspberry Pi 4 を使って、遅延とパケロスを制御できる、お手軽ネットワークエミュレータを作ってみよう。

先駆者

そもそもなのだが、そのものズバリなことを実践している先駆者様がいらっしゃった。

ラズパイで作るネットワークエミュレータ（前編）

この記事の Raspberry Pi には、小型ドットマトリックス LCD ディスプレイや、様々な物理キーが GPIO に繋がっていて、 THE IoT という仕上がりになっている。

かっこいいと思う。
でも、電子工作するのめんどくさいよね。

GUIで手っ取り早く作る

そんな複雑 (…というほど複雑でもないけど) な電子工作しなくても、 RasPi にタッチパネルディスプレイつけちゃえばいいじゃん。
…ということで、 Amazon で割と評判のよい、 OSOYOO の 2,980円タッチスクリーン付き LCD を取り付けて、めっちゃ簡単な UI をつくってみよう。

OSOYOO(オソヨー) HDMI 3.5 インチ LCD ディスプレイ IPS モニター IPSタッチスクリーン 1920x1280ハイビジョン Raspberry Pi 4 3 2 Model B に対応 (3.5" HDMI LCD+クリアケース)

もはや、 IoT 感を感じるのが難しくなってしまっているな……

構成は、以下の図のように有線 LAN 2つをブリッジ接続させる。

これなら、 Raspberry Pi OS の標準の機能だけで実現できそうだ。

なお設計的には、 Raspberry Pi が 2, 3, 4 どれでも機能するとは思うが、 1000BASE-T や USB 3.0 のポートを持っている Raspberry Pi 4B がオススメ。

RasPi 4B には 1つしか有線LAN ポートがないので、適当にもう一つ USB 有線LAN アダプタをつける必要がある。
Gigabit 対応のアダプタが良いだろう。

Raspberry Pi のセットアップ

まず、 Raspberry Pi OS with desktop イメージを SD カードに焼く。
"and recommended software" ではない ほうでかまわない。

今回は、 2020-12-02-raspios-buster-armhf.img のバージョンのイメージで試した。

OS イメージを焼くツールは何でも良いが、 balenaEtcher あたりが良いだろう。

Raspberry Pi OS が起動したら、以下の手順に従って、タッチスクリーンのドライバーが動くようにしておく。
http://osoyoo.com/ja/?p=4244

Raspberry Pi の2つの有線NICでブリッジ

まず接続されている、 NIC のインターフェイス名を確認する。

$ ip address show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0:  mtu 1500 qdisc mq state DOWN group default qlen 1000
3: wlan0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
4: eth1:  mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000

Raspberry Pi の有線LAN インターフェイスの場合は、 eth0, eth1... と名前がついていくため、ここでは eth0, eth1 がブリッジ接続させる対象だとわかる。

続いて、 ip コマンドを使って、ブリッジの作成する。

$ sudo ip link add br0 type bridge
$ sudo ip link set dev br0 up
$ sudo ip link set dev eth0 promisc on
$ sudo ip link set dev eth0 up
$ sudo ip link set dev eth0 master br0
$ sudo ip link set dev eth1 promisc on
$ sudo ip link set dev eth1 up
$ sudo ip link set dev eth1 master br0

※: ip link コマンドで設定したブリッジ設定は、 Raspberry Pi を再起動するとリセットされる。起動時に自動設定させたければ Raspberry Pi OS であれば /etc/network/interfaces.d/ 以下に、 Ubuntu であれば /etc/netplan/ 以下に、設定を書いておけば良いはず。

この状態でブリッジが意図したとおり機能しているか、 PC1, PC2 を接続して iperf で速度を測ってみる。

> .\iperf3.exe -c PC2
Connecting to host 192.168.1.222, port 5201
[  4] local 192.168.1.111 port 59582 connected to 192.168.1.222 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  53.6 MBytes   449 Mbits/sec
[  4]   1.00-2.00   sec  56.9 MBytes   478 Mbits/sec
[  4]   2.00-3.00   sec  58.0 MBytes   486 Mbits/sec
[  4]   3.00-4.00   sec  57.1 MBytes   479 Mbits/sec
[  4]   4.00-5.00   sec  57.9 MBytes   487 Mbits/sec
[  4]   5.00-6.00   sec  58.6 MBytes   491 Mbits/sec
[  4]   6.00-7.00   sec  57.6 MBytes   483 Mbits/sec
[  4]   7.00-8.00   sec  55.0 MBytes   462 Mbits/sec
[  4]   8.00-9.00   sec  56.5 MBytes   474 Mbits/sec
[  4]   9.00-10.00  sec  58.9 MBytes   492 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   570 MBytes   478 Mbits/sec                  sender
[  4]   0.00-10.00  sec   570 MBytes   478 Mbits/sec                  receiver

iperf Done.

1Gbps 出てないが、まぁこんなもんだろう。

qdisc 制御 GUI コード

Raspberry Pi 上のブリッジを通過して通信が通るようになったので、お次は通過するパケットに遅延やパケロスを発生させるための UI を作る。

UI 上でポチポチした値を基に、 tc qdisc コマンドを実行するような、単純な仕組みで良いだろう。
Python と tkinter で適当に仕上げてみる。

https://gist.github.com/advanceboy/b2bb75b1b1b95d7cd2af15c199c4a5b5

試しに動かしてみた動画がこちら。

https://aquasoftware.net/blog/wp-content/uploads/2021/01/pi-nw-emu-ping.mp4

UI上で設定した値に応じて、 ping の遅延とパケロスが発生しているのが、一目瞭然だろう。

遅延を 100ms (RTT 200ms) としたときに、先ほどと同じ組み合わせで iperf を動かしたところ、以下のようになった。

> .\iperf3.exe -c PC2
Connecting to host 192.168.1.222, port 5201
[  4] local 192.168.1.111 port 59582 connected to 192.168.1.222 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.03   sec   256 KBytes  2.04 Mbits/sec
[  4]   1.03-2.03   sec  0.00 Bytes  0.00 bits/sec
[  4]   2.03-3.00   sec   512 KBytes  4.30 Mbits/sec
[  4]   3.00-4.00   sec   384 KBytes  3.14 Mbits/sec
[  4]   4.00-5.01   sec   640 KBytes  5.23 Mbits/sec
[  4]   5.01-6.01   sec   384 KBytes  3.14 Mbits/sec
[  4]   6.01-7.01   sec   512 KBytes  4.18 Mbits/sec
[  4]   7.01-8.01   sec   384 KBytes  3.14 Mbits/sec
[  4]   8.01-9.00   sec   640 KBytes  5.31 Mbits/sec
[  4]   9.00-10.00  sec   384 KBytes  3.14 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  4.00 MBytes  3.35 Mbits/sec                  sender
[  4]   0.00-10.00  sec  3.95 MBytes  3.31 Mbits/sec                  receiver

iperf Done.

輻輳制御が働いて 3.35Mbps しか速度が出なくなっていることがわかる。

…とまぁ、こんな感じで目的を達成することができた。

余談

Raspberry Pi に Raspberry Pi OS 以外の OS を入れる場合

Raspberry Pi OS では、標準だと sudo コマンドにパスワードが不要な設定が visudo にされている。
一方、 Ubuntu など他の多くのディストリビューションではそうなっていない。

他の OS で動かしたい場合、 visudo で /usr/sbin/tc コマンドをパスワードなしで実行できるように設定しておこう。

OSOYOO のタッチスクリーン付き LCD について

先ほど挙げた OSOYOO のタッチスクリーン付き LCD は、この価格帯のものなので過度な期待は禁物ではあるものの、少なくともこの用途にはコスパ抜群だった。

クリアケース付きのもののケースは、正直このクオリティだと +1,000円分に達していないレベルのものだが、 LCD ディスプレイにちょうど合うサイズだったので、払ってしまっても損はないと思う。
ただし、 Raspberry Pi 4B には端子の穴の位置が合わないため、サイドのアクリルが取り付けられなかった。

また、同梱されていた紙のマニュアルに書かれていたリンクでダウンロードしたドライバーが古かったらしく、最新の Raspberry Pi OS に入れたら、タッチ位置が 90° 回転して認識されるトラブルに遭遇した。
以下のオンラインマニュアルのリンク先の、最新(?) のドライバーを使うようにしたら、上記のタッチ位置の問題は解消されたので、参考まで。
http://osoyoo.com/ja/?p=4244

同梱されていた Raspberry Pi 4B 用の HDMI - microHDMI コネクターが壊れていたのだが、サポートにメールしたら即返事が来て代替品送ってくれたので、好印象。
代替品が届くまでは、家にあった変換ケーブルで我慢。

一方で、タッチパネルの「ドライバー」とやらが、インストールスクリプトの中身をよく見ると、何故かカーネルごとゴッソリ置き換える仕組みになっている。
HW のドライバーという時点で、提供元を信頼しないとどうしようもないのだが、カーネルごと置き換えられるのにはちょっとモニョる。

2020年末現在、 Raspberry Pi OS の Linux カーネルは 5.4系なのだが、このドライバーでカーネルが置き換えられると、 Linux カーネルが 4.19系に落ちる点は注意。
とりあえず、 2020-12-02-raspios-buster-armhf にインストールした限りは、問題なく動いていそうではあるが。

マニュアルにも書いてあるが、 Kernel を更新すると正常に動作しなくなる可能性があるので、 apt の更新大将から Kernel を除外すると良いようだ。
このため、常用するマシンにはオススメしない。

ルータを経由すると仮想ブリッジ接続の VM にアクセスできない？

2019-11-25T04:32:35+09:00

今回は、ネットワークの話。

解決してみれば割としょうも無いトラブルで、時間を浪費してしまったので、自戒の意味を込めて記事にしておく。

サブネット外から ping が通らない

ある日、ホストPC の NIC とブリッジ接続されている VM に、サブネット外からアクセスできなくなってしまった。

構成を図にすると、以下のような感じ。
(あまり UML図に明るくないので、書き方がヘタクソだったり本来の意味と違う記号の使い方をしている点は大目に見て欲しい。)

同一サブネット内 (図の "Machine on Same Subnet") から 172.16.42.16 を叩くと VM ゲストに到達するのだが、サブネット外 (図の "Machine on Different Subnet") からだと ping すら通らない。

以前は同じ構成で、サブネット外から繋がっていたはずだ。

ちょうど直前に、ネットワーク機器のメンテナンスがあったため、そちらで IPフィルタの動作がおかしくなったのではないかと疑ってしまった。
しかし、繋がらなくなった直接的な原因は、 VM Gurest 側にあった。
このため、答えにたどり着くのに時間がかかってしまった。

アクセスできなかった原因

上の図で若干答えを示唆してしまっているが、 VM Guest に繋がっているもう一つの仮想ネットワークアダプタ (図の "eth0") が原因だ。

この eth0 は NAT 経由でホスト側のネットワークに繋がっていた。
そして、 eth0 の metric が、 eth1 よりも短くなる設定に変更してしまっていたのだ。
(何故そんな繋ぎ方をしているかというと、ホスト PC の IP として通信させたい事情があったから。理由は察して。)

構成を図にしてみると、以下のような感じ。

このような構成だと、 VM Guest からの通信は全て、より『距離が近い』と見做される eth0 と NAT 経由で行われるようになる。

通常、ルータや L3スイッチなどが、 IPアドレスと MACアドレスの対照表である ARP テーブルに載っていない IP のパケットを受け取った場合、サブネット内に ARP リクエストパケットをブロードキャストして、対象の MACアドレスを探しに行く。
しかしこのサブネットの間を取り持っているルータは、どうも ARP テーブルに載っかっていない IP へのパケットを全て破棄してしまうらしい。
（レイヤ3 の知識が不十分なので、正確な説明ではないかも知れないが、雰囲気だけでも伝われば。）

つまり、 VM Guest から eth1 を経由してルータに到達する通信がなかったために、ルータが eth1 の MACアドレスを知らず、パケットが全て破棄されてしまっていたようだ。

以前通信できていた頃は、 eth0 より eth1 からの通信の方が metric が近かったため、 eth1 からルータを経由してインターネットへ向かう通信が存在し、ルータが eth1 の MACアドレスを知っていたため、サブネット外からの通信がちゃんと eth1 に届いていたのだろう。

一方、同一サブネット内の "Machine on Same Subnet" からの通信は、この Machine が直接 ARP リクエストパケットをブロードキャストして、 eth1 の MAC アドレスを見つけられるため、 metric の距離にかかわらず通信できていたのだと思われる。

解決策

VM Guest の eth1 から通信が外に出るように metric の設定を変更して、適当なパケットを投げたところ、サブネット外から eth1 の IPアドレスに通信ができるようになった。

ルータがサブネット内の未知の IPアドレスへのパケットを全て握りつぶすというのは、盲点だった。。。

「Network」の記事 - Crieit

NEC IXシリーズルーターでポートVLANとタグVLANをVLANスイッチ的に併用する

GNS3 に VyOS 仮想ルーターを追加する長い道のり④ 応用編

GNS3 に VyOS 仮想ルーターを追加する長い道のり③ 実践編

VyOS 起動時に KVM acceleration cannot be used と出る

GNS3 に VyOS 仮想ルーターを追加する長い道のり② イメージ準備編

GNS3 に VyOS 仮想ルーターを追加する長い道のり① 環境導入編

Vagrant で Temporary failure resolving となる問題の解決 - イントラネット DNS 編

Windows Server の CertReq で作成した CSR の文字化けを回避する

VPN に繋ぐと WSL2 や Hyper-V VM でネットワークに繋がらなくなる問題を解消する

Raspberry Pi で作るネットワークエミュレータ

ルータを経由すると仮想ブリッジ接続の VM にアクセスできない？

VyOS 起動時に `KVM acceleration cannot be used` と出る