VirtualBox：NAT環境で共有フォルダなしにファイル転送を実現する方法（ポートフォワーディング＋SSH）

今回はちょっと面白くて、しかもやや込み入った問題を取り上げます。VirtualBoxを普段お使いの仮想化ツールとして使っているとしましょう。そこで3Dアクセラレーション関連のトラブル――画面が真っ黒になるなどの症状――に悩まされている状況です。以前のチュートリアルで紹介したように、この問題の対処法はディストリビューションのリポジトリから提供されるGuest Additionsを使うことです。しかし、公式ISOに同梱されているGuest Additionsとは異なり、リポジトリ版には共有フォルダ（shared folders）用のドライバが含まれていません。つまり、その機能が利用できないのです。

さらに話を複雑にしてみましょう。「ファイルを共有したい」とします。別記事「ネットワーク＆共有」でも扱ったテーマですが、今回はブリッジ接続ではなくNATを使用しているため、通常の手段ではホストからゲストマシンにアクセスできません。さらにSambaなども使いたくないとなると、状況はいっそう厄介になります。そこで今回は、共有フォルダなし・NAT環境下で、ホストからゲストへファイルを転送する方法を紹介します。インターネット経由の小細工は一切不要。すべてローカルで完結する手法です。それでは始めましょう。

問題の整理

一見すると、ネットワークアダプタを「ブリッジ」に変更してゲストを見える状態にすれば済むように思えます。しかし、それは必ずしも望ましい対応ではありません。特に通信量の多い（「うるさい」）仮想マシンの場合はなおさらですし、ファイル共有サーバーのセットアップといった追加作業も発生します。

もうひとつの選択肢は、VirtualBox公式ISOのGuest Additionsを導入することです。ただしこのケースでは、ブラックスクリーン問題が解消するまで3Dアクセラレーションを無効化しておく必要があります。その上で、共有フォルダ機能が使えるようになります。

ここで整理しておくと、リポジトリ版パッケージの場合、グラフィックアクセラレーション、マウス統合、画面サイズの自動調整、クリップボード共有など、大半の機能は利用可能ですが、共有フォルダだけは含まれていません。手動でマウントを試みても、次のようなエラーが出てしまいます。

mount -t vboxsf <share> <mount point>
mount: unknown filesystem type 'vboxsf'

解決策：ポートフォワーディング

実はVirtualBoxでは、NAT接続のマシン向けに高度なネットワークルールを設定できます。仕組みの本質は、家庭用ルーターがローカルIPアドレスと公開用アドレスを相互変換しているのと同じです。そしてここでは、VirtualBox自体がその「ルーター」の役割を担います。Dockerでも同様の発想を見たことがあるでしょう。ホストのポートをコンテナのポートへマッピングすることで、ローカルシステムに接続しているようでいて、実際にはコンテナ（今回なら仮想マシン）へつながっているわけです。

手順は以下のとおりです。まず対象の仮想マシンを選択し、「設定（Settings）」を開きます。「ネットワーク（Networking）」でネットワークタイプがNATになっていることを確認し、下部の「高度（Advanced）」セクションを展開します。そこにある「ポートフォワーディング（Port Forwarding）」をクリックすると、必要な情報を入力できる表が表示されます。

• ホストIP（Host IP）：使用するインターフェースのIPアドレス。複数存在する場合はありますが、最も確実なのはlocalhost（127.0.0.1）を指定する方法です。他のインターフェースがダウンしていても、ホスト外への接続性がなくても動作します。
• ホストポート（Host Port）：接続先となる「仮想的な」ポート番号。例えばSSHであれば、2222番をホストポートとして割り当てます。このポートへ接続すると、実際には表で指定したゲストIPの該当ポートへ接続される仕組みです。
• ゲストIP／ゲストポート（Guest IP／Guest Port）：仮想マシン側の情報。ホスト側と同じ要領で入力します。

SSHで接続する

これで接続の準備が整いました。「待ってください、SSHってLinux用では？」と思われるかもしれません。その通りです。今回問題が起きているのはLinuxだからです。Windowsにはブラックスクリーンの問題がないため、ISO版Guest Additionsと3Dアクセラレーションの組み合わせは問題なく機能します。ゆえに、ターゲットはLinuxというわけです。

まず最初のステップとして、ゲストOSにopenssh-serverがインストールされ、サービスが稼働していることを確認してください。加えて、ゲート側のファイアウォールが外部からの接続をブロックしていないことも確認が必要です。準備ができたら、ホストからゲストへSSH（ポート2222）で接続してみましょう。

ssh -p 2222 roger@127.0.0.1
The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established. ECDSA key fingerprint is SHA256:Eq0ow03sffLb7G49e3KNMgMrpVV/8wFfN6uicdxPnEL.
Are you sure you want to continue connecting (yes/no)?

これはあくまで接続確認のための操作です。実際にファイルをコピーするにはSCPを使います。ここでもカスタムポートの指定が必要ですが、重要な注意点があります。SSHでは小文字の-pでポートを指定しますが、SCPでは大文字の-Pを使います。なんとも紛らわしい仕様ですね。したがって、コマンド全体は次のようになります。

scp -P 2222 "file" roger@127.0.0.1:/home/roger/"location"/
"file"  100% 8244KB 135.0MB/s  00:00

まとめ

こうした工夫は、以前紹介した「KVM＆ブリッジネットワークのトリック」と同じく、革新的で楽しめるものになり得ます。一見すると、ブリッジ接続へ切り替えるか、SambaやNFSを構築するか、メールでファイルを送るしかないように思えますが、いずれも手間がかかります。ところが、ポートフォワーディングとSSHを組み合わせれば、シンプルかつシステムに影響を与えない形で問題を回避できますし、不要になった際の解除も非常に簡単です。

今回は多くのことを学びました。リポジトリ版Guest Additionsに欠けている機能、高度なネットワークルールとポートフォワーディングの活用法、SSHとSCPにおけるポート指定オプションの微妙な違いなどです。問題解決においては、粘り強く、体系的に取り組めば、必ずスマートな解決策が見つかるものです。

それでは、また次回お会いしましょう！