Parallels上のUbuntuから他のUbuntuをNFSマウントできなくて困る

 こんばんわ

本日は、「Parallels上のUbuntuから外のUbuntuをNFSマウントできない」という話です。

もう少し詳しく書くと、MacBookの中にParallelsをインストールして、ゲストマシンとしてUbuntuサーバを起動しています。こちらUbuntu00というホスト名です。

MacBookとは別に同じWiFiネットワークに接続しているPCにVMWAREなど使わず、リアルマシン上にUbuntuを起動して、NFSサーバを立ち上げています。こちらがUbuntu01というホスト名です。

MacBookのParallels上に起動しているUbuntu00から、MacBookと同じセグメントに起動しているUbuntu01のNFSサーバの共有をNFSでマウントしようとしたらできなかったという話です。両方Ubuntuだからややこしくなりますね。どちらか違うOSにすればよかったかも。NFSサーバを00にしたほうが良かったかも。。。

こんな環境で接続しようとしました。

以下のような環境で、Ubuntu00からUbuntu01上のNFSの共有をマウントします。私の、Parallelsは、ゲストが起動するネットワークは、MacBook本体が接続されているネットワークとは別のネットワークが定義されていて（今回の例では10.211.55.0/24です）、Parallelsでゲストを作成するとすべてこのネットワークに接続され、ネットワーク内のすべてのホストが、MacBookのアドレス＋ポートに変換されて通信するような動きになります。

実際にUuntu00からUbuntu01の共有をマウントしようとすると、次のようなログがNFSサーバUbuntu01に記録されて接続できません。

XXX X   10:55:51 ubuntu01 rpc.mountd[5009]: refused mount request from 192.168.2.25 for /temp (/temp): illegal port 61310

クライアント側Ubuntu00には次のようなメッセージが表示されました。

mount.nfs: access denied by server while mounting 192.168.2.35:/temp

Parallelsのゲストのネットワークの設定は、以下のようになっているのですが、その場合は、上記のようなネットワーク構成になって、MacBookのネットワークI/FでNAT（PAT?Masquerade?ポートも再マップ）されるため、IPアドレスがMacBookのものとなって、Ubuntu00で使用したクライアント側のTCP/UDPのポート番号が、MacBook上で再マップされてしまって、ポート番号が勝手に大きな値に変わってしまいます。Ubuntu00側でソースポートを2001としても、MacBookを通過した時点で2001とは限らないということになると思います。

今回NFSが接続できない問題はポートが置き換わっているためということではなく、置き換わった際に大きな値になってしまうことが問題だと思いますので、より小さい値に置きかわるように設定するか、置き換わらないようにすればよいと思います。

そこで、Parallelsのゲストのネットワークの設定で、ソースと書かれているところを「デフォルトのアダプタ」にします。以下のような感じです。

すると、ネットワーク構成は次のような感じに変わります。先ほどまでは、Parallelsのネットワークの中にいたUbuntu00が、MacBookの存在するネットワークの中に移動します。というか移動するという感じです。MacBook上にUbuntu00用のI/Fが仮想的に作成されて、Ubuntu00のI/Fとして動作します。

MacBookを通らずに接続しているように描かれていますが、実際には、MacBookのデフォルトのインターフェース（私の場合はWiFi）にもう一台接続されるような感じです。昔は物理的なI/Fに仮想的に名前を割り当ててあたかも複数のI/Fとして動かすことをエリアスすると言っていたように記憶していますが、今はどうなんでしょう？まあいいか。

はじめの構成では、Ubuntu00はParalellsの仮想ネットワークの中でDHCPからIPアドレスを取得しますが、本構成では、MacBookが接続しているネットワークのDHCPからIPアドレスを取得します。手動で設定してもいいです。

はじめの構成では、Ubuntu00からの通信は、MacBookのIPアドレスに置き換わって、かつTCP/UDPのポートは、再度マップし直されてしまうのですが、この構成では、MacBookとは別のIPアドレスが割り振られて、ポート番号は再マップされずそのまま接続されるようになります。

これでNFSマウントできるようになりました。

NFSのようにあまり大きなポート番号では接続を許さないケースや、サーバ側からクライアント側のソースポートを指定されるようなケース（そんなのあったかな。。。？）では問題になりますが、https、telnet、sshのようなプロトコルでは全く問題にならないと思います。実際、Ubuntuのアップデートやwget/pip/docker などやっていましたが普通にできてしまっていました。FTPもポートモードではサーバ側のポートは指定されたと思いますが、クライアントに制限はなかったように思います。途中にFireWall的な仕組みがあると、FTPでもあまり大きなポートでは拒否されたような気がします。２０年くらい前の知識なのであまりあてにならないかもしれません。。。そもそも最近FTPとか使ってないですよね？

なぜ、こんなことしているのかというと、「NFSのクライアントとサーバの時間がずれていた場合、クライアントがNFS上にファイルを書き込んだらどちらの時間になるのか？」という疑問を確認したたかっただけなんですがなんかすぐにうまくいかず時間がかかってしまいました。

ちなみに、サーバの時間になりました。さらにちなみに、Windows Professional で共有を作って、Windows Home からドライブのマップをしてやってみましたが、Windowsもサーバ側の時間になりました。