鯖缶

現状うまくいっていないと思う点がいくつかある。

CI の worker ノードなどについても静的アドレスを振っている¶

こんなもの本来は DHCP に任せてしまうべきだが、コンテナ用のアドレス範囲が /20 しかないことから、数は足りているもののあまり余裕をもって範囲を割り当てられない。

管理ネットワーク用のネットワークが、サービスやクラスタの稼動用のネットワークと分離されていない¶

/20 の最初の /24 をなんとなく管理用として使っているが、 out-of-band management 用のネットワークを確保できていない。
たとえばクラスタ間の動機やコアサービスの暴走などで帯域を食い潰した場合、 IPMI 等からの制御も困難になってしまう。

NAS との高速な接続のため、デスクトップ PC が管理・バックエンド用ネットワークにいる¶

NAS との接続を 10Gbps にするために、ギガビットルータ (RTX830) を経由しない経路でデスクトップ PC と NAS が接続できる必要があり、結果デスクトップ PC がサーバと同じ VLAN に所属している。
デスクトップも管理に用いており十分に信頼されていると考えれば必ずしも望ましくない運用とは言いきれないが、再検討は必要。

ホスト名とアドレスの管理が手動¶

DHCP を使えるところで使っていないのと似た問題だが、サービスを作るたび静的アドレスを割り当ててそれに依存しており、ホスト名での依存を行っていない。
chuable での HA もできているのだから DNS をクラスタ内に立てて名前のみによる依存に切り替えても良い頃合いかと思われるが、その場合名前とアドレスの紐付けをどう自動化するか考える必要がある。
なにか良い感じの IPAM がほしい。

ハードウェアへの余計な依存がある¶

VLAN あたりは仕方ないとして、 DNS とか、コンテナに対する DHCP とか、その辺りの自前で立ててもなんとかなりそうな領域のサービスをルータ (現状は RTX830 だが、将来的に使う RTX1300 も含む) やスイッチ類から分離したい。
ハードが壊れたとき「そのへんに転がってた機材」を差し込んですぐに仮復旧できるくらいの状態が望ましい。
(この理由から、 chuable で SDN を使う際に機材側で BGP の設定が必要になるなどの事態もできれば避けたい。)

現状の構成。

VLAN:

• 192.168.103.0/24 (VLAN 103): gadgets
• 192.168.104.0/24 (VLAN 104): guest
• 192.168.128.0/20 (VLAN 201): dmz
• 192.168.160.0/20 (VLAN 202): trusted

subnet:

• 192.168.160.0/24 前半: 物理サーバ (NAS, PVE 等)、ネットワーク機器
• 192.168.160.0/24 後半: 信頼できる PC (atri 等)
• 192.168.132.0/23: アプリサーバ等 (コンテナと VM)
• 192.168.164.0/23: アプリサーバ等 (コンテナと VM)
• 192.168.103.0/24: スマホ、IoT 機器等
• 192.168.104.0/24: ゲスト用 (社用 PC 含む)

そもそも VLAN というやつが、ルータ側にちゃんとファイアウォールを挟まない限りはブロードキャストドメインを狭められる程度の嬉しさしかない気がしている。
しかも Cloudflare Tunnels などを使っていない限りは、何かしらのサービスを公開しているサーバ (内部向けも含む) はスマホや IoT ガジェット等を含めアクセス可能であってほしいので、結局のところアクセス制限もあまり強くかけられない。
(IoT ガジェット等やゲスト端末からのアクセスも Pi-hole 等で制限しようとすると、結局一部サービスは任意の VLAN からアクセスできるべきということになってしまう。)

“真面目に” 用意した mgmt-VLAN はスイッチを物理的に分離できて VLAN 非対応のスイッチを使えるようにする意味でも有用だろうが、そうでないものはあまり深く考えない方が良いかもしれない。

もうひとつ重要なのが、 mgmt-VLAN と通常動作・サービス提供用のアドレス範囲を分ける必要がある (実用上は VLAN を分けたい) ということ。
BSD 等だと同じサブネットから2つの IP アドレスを別々のインターフェースに割り当てるなどができないし、 Linux でもできるものの望ましくないような話を見た (正確なところは知らない)。

以上を踏まえて、たとえば以下のような分類はどうだろうか。

• mgmt: IPMI や機器・サーバ管理用に帯域を最低限残しておくための VLAN。独立したスイッチからアクセス可能なのでルータが死んだときでもどうにかできる。
• lab: 自宅ネットワークの主要な一部と見做される機材群。サーバアプリ等や VM/CT、デスクトップ機やラップトップ等、あるいは内部サービスに接続したいときのスマホなどが参加する想定。
• public: 外部からの接続を受け入れる前提のサブネット。
• gadgets: 通常時のスマホ、ゲーム機、 IoT 機器などの、 homelab において “主要” でない機材。
• guest: 信頼できない機材や自分が所有・管理していない機材。

mgmt VLAN を VID=1 にするかどうかはちょっと考えたい。
セキュリティ的に VID=1 は駄目だという話もあるし、そもそも VID があまりセキュリティに寄与しないなどの話もどこかで見た気がする。
今一度調べて検討する必要がある。

cf.

• Defending Against VLAN Hopping Attacks

nop_thread さんは #note-1 で書きました:

ハードが壊れたとき「そのへんに転がってた機材」を差し込んですぐに仮復旧できるくらいの状態が望ましい。
(この理由から、 chuable で SDN を使う際に機材側で BGP の設定が必要になるなどの事態もできれば避けたい。)

結局ルータで VLAN のあれこれを用意することになるので「『そのへんに転がってた機材』を差し込んですぐに仮復旧できるくらい」は基本的に無理だし、であれば「VLAN をあれこれできる程度の機材ならできると想定されるラインまでなら OK」と考えるべき。
もちろん設定が簡素であるに越したことはないが。
(BGP はそのラインの内側だろうか……)

RTX830 で LAN 側にトランクポートしか用意していなかったので PC からの LAN ケーブルを挿してもアドレスが降ってこず泣いた。
こういうことがあるからアクセスポートを用意しないといけないんだな (まあ RTX830 は LAN1 ポート (LAN) と LAN2 ポート (WAN) しかないので tag VLAN を活用しようと思ったら選択の余地がなかったが……)。

とりあえず自宅にオタクがやってきて悪さをする事案などはどうしようもないということにして、 VID=1 を default VLAN にして mgmt VLAN を用意してしまおう。

ルータから出ているべきポートは以下の3種類。

• access port (mgmt VLAN (VID=1)) → 1G
• trunk port (mgmt VLAN 含む) → 10G
  • PoE で稼動している無線 AP が LAN ケーブル1本で複数の VLAN に繋がる必要があるため、 PoE スイッチ経由で mgmt VLAN にアクセスできる必要がある。
• WAN port (1) → 1G
  • 将来的に 2Gbps や 10Gbps の回線を契約する可能性がなくもないが、今のところ 1Gbps
  • 将来的に第二の回線を契約する可能性がなくもないが、今のところ1回線のみ

1G WAN 用に2ポート、 trunk 用に10Gポートをひとつ、mgmt への access port 用に4ポートくらいあればいいか。

• 1-4: access port (LAN1)
• 5-6: (unused)
• 7: WAN 1 (LAN2)
• 8: WAN 2 (unused) (LAN3)
• 9-10: trunk (LAG) (LAN4)

こんな感じでいく。

nop_thread さんは #note-4 で書きました:

• mgmt: IPMI や機器・サーバ管理用に帯域を最低限残しておくための VLAN。独立したスイッチからアクセス可能なのでルータが死んだときでもどうにかできる。
• lab: 自宅ネットワークの主要な一部と見做される機材群。サーバアプリ等や VM/CT、デスクトップ機やラップトップ等、あるいは内部サービスに接続したいときのスマホなどが参加する想定。
• public: 外部からの接続を受け入れる前提のサブネット。
• gadgets: 通常時のスマホ、ゲーム機、 IoT 機器などの、 homelab において “主要” でない機材。
• guest: 信頼できない機材や自分が所有・管理していない機材。

• mgmt: VLAN=1 (untagged, default)
  • 新設 (trusted から分岐)
• lab: VLAN=301 (tagged)
  • 旧 trusted
• public: VLAN=302 (tagged)
  • 旧 dmz
• gadgets: VLAN=303 (tagged)
  • 旧 gadgets
• guest: VLAN=304 (tagged)
  • 旧 guest

gadgets VLAN と guest VLAN の VID は変更した。

諸々の機材の mgmt VLAN (VID=1, untagged) への移行は難航している。
特にネットワーク機器の管理画面へアクセスできなくなる事案やスイッチを通して別の VLAN へアクセスできなくなる事象が多発しているため、ファクトリーリセットしてやり直すのが一番楽そう。

mgmt VLAN から DNS のアドレスが配られていないようなのが気になる。 DHCP の設定に問題でもあったか？

lab VLAN と public VLAN の作成もでき、疎通も確認した。
TrueNAS も lab VLAN からアクセスできるようにしたし、 mgmt VLAN から web UI や IPMI に繋がるようにもしてある。

残件は以下のとおり。

• TrueNAS のアドレスを利用している部分で lab VLAN のアドレスを使うよう切り替える (優先的に！)
  • toka のレプリケーション設定
  • PVE の NFS
• chuable 上の VM/CT で trusted VLAN と dmz VLAN のアドレスを使っているものをすべて lab と public のアドレスに移行する
  • → #342 に分岐
• TrueNAS 上の minio のアドレスを lab や public のアドレスに変更する
  • → #330, #342 で検討
• yonagi のアドレスを lab, public, mgmt へ移行
  • lab は SFP+ LAG、 public と mgmt が 1GbE RJ-45
• ashe のアドレスを lab, public, mgmt のうち2つへ移行 (→どうする？)
  • ashe は public から露出する意味が薄い (TLS 証明書が Let's Encrypt で取れなくなるくらいのデメリットしかなさそう)
  • → #69#note-9 で検討
• chelsea に lab のアドレスを使わせる
  • VLAN を使うと管理がややこしくなるので避けるのが良いか？
  • → #342 で検討

これが全て済んだ時点で trusted と dmz を使うホストがなくなっているはずなので、 chima から設定を削除して作業完了。

現状で遠隔勤務できる程度にまともな状況になっているはずなので、特に作業期日はない。

chelsea の属するネットワークをひとつにして Cloudflare Tunnels を使うようにした。あとは IP アドレスの扱いをどうにかすれば lab ネットワークに引っ込められる。

現状で手動のアドレス割り当てが機能しているので、ひとまず先に VLAN 移行だけしてしまいたい。
DHCP/DNS/IPAM の連携はまた後で考えることにして、今は DHCP 抜きで DNS と IPAM だけ考える。

→ DHCP の話題は #338 に分岐。

クラスタ名は用意してあったが拠点名 (あるいはネットワーク名) を用意していないせいでドメインをうまく用意できずにいる。名前を考えねば。

nop_thread さんは #note-21 で書きました:

クラスタ名は用意してあったが拠点名 (あるいはネットワーク名) を用意していないせいでドメインをうまく用意できずにいる。名前を考えねば。

ノベルゲームの舞台の地名とかでいいか。
kagamidai (『ましろ色シンフォニー』より) あたりは良さそう。

ノード名用のドメインは kagamidai 、サービス用のドメインは nukobu に用意することにした。