VMに、自分の住所は要らなかった — NGW初のLinuxサーバと「玄関を貸す」構成

Mac で動く NGW に、Linux の一台を

NGW は自治体向けの行政システムだ。これまでずっと Mac 上で動いてきた。各団体の Mac mini に開発用のローカルサーバ環境を載せ、その一台で数百人が回す。いま動いている団体の規模——DB が数百 MB から数 GB——では、必要十分な性能が出る。無理に作り替える理由はない。

ただ、先はある。いちばんデータの重い団体は、数年後には二桁 GB に届く見込みだ。そこは今年度のうちにハードを更新し、新しい言語ランタイムを先に入れておきたい。そのための土台として、Linux のゴールデンイメージを一枚こしらえる。素の状態から作り込んだ一台を、後から何度でも複製して各所へ配れるようにする。その原本だ。

今日はその第一歩。Linux の仮想マシンを一台、ゼロから建てて、ネットワーク越しに入れる状態にする。 NGW にとって初めての Linux である。

建てる前に、ハッシュを確かめる

分担はこうした。手を動かす GUI の操作は私。コマンドで確かめられるところは AI。 仮想化ソフトの画面や、OS インストーラの対話画面は人が矢印キーで進める。その各手順を AI が指示し、裏で検証できることは検証する。

最初の関門は OS イメージの入手だった。ここで AI は URL もハッシュも推測しなかった。公式の配布元に直接あたり、実在するイメージ名と、公式が公表している SHA256 を引いてくる。3 GB あまりのダウンロードが終わった瞬間、真っ先にやったのがハッシュの照合だった。

公式のハッシュと、手元のファイルのハッシュが完全に一致するまで、起動しない。

この一行がゲートだ。改ざんや破損があればここで止まる。一致を確認して、初めて起動してよしになる。土台にするイメージだからこそ、中身が本物だと確かめてから建てる。 人の勘ではなく機械の照合に任せるところだ。

OS のインストールは淡々と進んだ。最小構成。そして遠隔で入るための仕組みだけは必ず入れる。起動してすぐネットワーク越しに入れなければ、以降の作業が全部止まる。

計画は「自分の住所」だった

つまずいたのはネットワークだった。

当初の計画は明快だ。仮想マシンをブリッジ接続にして、社内 LAN の中で VM 自身に固定の住所を持たせる。そうすれば、開発機だろうと別の PC だろうと、同じ LAN にいる誰もがその住所を宛先にして直接 VM へ届く。素材の転送も遠隔ログインもまっすぐ通る。いちばん素直な形だ。

ところが、起動した VM が名乗ったのは LAN の住所ではなかった。仮想化ソフトが内側に用意した、閉じたネットワークの内部アドレスだった。ブリッジのつもりが、実際には NAT。VM は自分専用の一室にいて、外の廊下に面した窓を持っていない。

環境によっては、ブリッジが素直に通らない。ここもそうだった。原因を延々と追ってブリッジを通しにいく道もある。だが目的は「VM に入れること」であって「ブリッジを成立させること」ではない。手段に義理立てしない。別の形を採った。

玄関を貸す、という答え

答えは、ホストの Mac を玄関にすることだった。

VM は外に窓を持たない。だが VM が載っている Mac は LAN に面している。Mac の住所に届いたアクセスを、そのまま裏の VM へ通す。 玄関は Mac が受け持ち、実際の部屋は裏にいる VM が受け持つ。仮想化ソフトのポート転送で、用途ごとに Mac の窓口を VM の対応する入口へつなぐ。

この形なら、外から見える宛先はひとつ。Mac の LAN 住所だけだ。他のマシンからも、そこを叩けば裏の VM に届く。VM に、自分の住所は要らなかった。 玄関さえ借りられれば、部屋は奥にいていい。

この「玄関がひとつ」は妥協ではない。運用の仕様そのものだ。 仮想化を使う以上、一台の Mac に何台でも VM を積める。だが NGW はそうしない。一台の Mac には、NGW の VM を一台だけ。 VM という器に移しても、NGW はこれまで通りそのマシンを丸ごと占有する。他のサーバと同居させて資源を取り合わせたりはしない。

だから玄関は複数になりようがない。Mac の住所を叩けば、その先にいるのは常に唯一の NGW だ。実質、Mac の LAN 住所がそのまま NGW サーバの住所になる。宛先の曖昧さが最初から存在しない。VM が自分の住所を持てなかったことが痛くないのは、この Mac がこの NGW 一台のためだけに在るからだった。

ssh が通らない、二つの脅し文句

いざ遠隔ログインを試すと、通らない。しかも順に二つの脅し文句が出た。どちらも、見た目より遥かに退屈な理由だった。

ひとつめ。「接続を拒否されました」。 素のログインコマンドが弾かれた。理由は単純で、遠隔ログインの窓口だけ標準の入口ではない別番号に転送してあった。標準の入口を素直に叩くと、Mac 自身の——何も動いていない空っぽの——標準入口に当たって撥ね返される。窓口の番号を明示して叩けば、あっさり通った。拒否は攻撃でも故障でもない。入口を間違えていただけだ。

ふたつめ。「リモートホストの識別情報が変わった!」「誰かが盗聴しているかもしれない!」 全画面に警告の壁が立った。文面は物騒だが、理由ははっきりしている。今回の VM はまっさらな新規インストールで、真新しい鍵を持っている。ところが同じ玄関には、以前ここに割り当てていた別の VM の古い鍵が、こちら側の記録として残っていた。鍵が食い違う。だから遠隔ログインは律儀に「なりすましか?」と疑って足を止めた。

正体は、引っ越してきた新しい住人に前の住人の鍵が合わない、それだけだ。手元の古い鍵の記録を一件消して繋ぎ直せば済む。念のため、VM のコンソールで本物の鍵の指紋を出し、警告に出た指紋と一致することも確かめられる。

脅し文句の裏には、いつも退屈な事実がいる。 全画面の警告に一瞬ひやりとした自分としては、あまり大声では言いたくないが。

AIとの協働作業での学び

今日の作業は役割がきれいに分かれていた。確かめるのは機械、決めるのは人。

ハッシュの照合も、繋がらない理由の切り分けも、AI はためらわずに速い。イメージが本物かを一致で示し、拒否の正体を入口番号の食い違いと言い当て、物騒な鍵の警告を「新規インストールが前の鍵と食い違っただけ」と即座に分解する。怖い文面を、退屈な事実に翻訳する。 これは助かった。物騒な赤い文字を前にすると、人はつい身構えて手が止まる。機械はそこで止まらない。

一方、「玄関を貸す」と決めたのは人だった。ブリッジを通しにいく道もあった。だが目的は VM に入ることであって、当初の設計図を成立させることではない。計画が現実で通らなかったとき、計画に義理立てせず動く別の形へ乗り換える。この判断は使う側にしか下せない。AI はブリッジが通らない原因を延々と追うこともできた。そこを追うべきかは別の話だ。

今日いちばん腑に落ちたのは、VM に自分の住所は要らなかったということだ。最初はそれが正解だと思い込んでいた。LAN に面した固定の住所を VM に持たせる。素直で綺麗な設計である。だが現実がそれを許さなかったとき、玄関を借りるだけで用は足りた。綺麗な形と、動く形は、しばしば別物だ。 動く形を選べたのは、綺麗な形を諦められたからだった。

そして玄関がひとつで済むのは偶然ではなく、NGW の運用の仕様だった。一台の Mac に NGW を一台だけ、丸ごと占有させる。この決め事があるから、Mac の住所と NGW の住所が一致し、宛先に迷いが生まれない。制約が設計を単純にすることがある。何でも積める器に、あえて一台しか積まないと決めたことが、いちばんややこしくなりがちなネットワークの入口を、いちばん単純にしていた。

土台は建った。次は、この一台に NGW の中身を流し込む番だ。