VirtualBoxにUbuntuServer22.04をインストールしました。
さらに詳しく
何も手を加えてない状況でUbuntuServer22.04のファイアウォール設定はどうなっているのでしょうか?
デフォルト時のファイアウォール設定
Ubuntuのコマンドプロンプトから下記のコマンドを叩いてファイアウォールの状態を確認してみました。
sudo ufw status
ココがポイント
デフォルトでは、非アクティブ
になっていました。
では、このデフォルト状態での外部からのポートスキャンをかけるとどうなっているのでしょうか?
UbuntuServerのネットワークをブリッジアダプターに変更すると、IPが192.168.1.75に振られたようです。
現時点では、pingは疎通確認できました。
nmapにてポートスキャンをすると、「Host seems down」となり見つからないようです。
さすがにサーバーと言ってるだけあって、デフォルトではファイアウォール設定してなくてもポートは閉じているようですね。
GUIファイアウォール設定
自分の場合は、どうしてもコマンドからの操作が苦手です。
そこで、UbuntuServerのソフトウエア管理からGUIでファイアウォール設定ができるソフトをインストールしました。
とりあえず先頭に出てきた「ファイアウォール」というのをインストールしてみました。
アイコンが作成されたので、起動するとファイアウォールが動いてないよってメッセージが出たのでコマンドから起動させました。
sudo ufw enable
どうも「ファイアウォール」の使い勝手がよくないので、2番目の、「Firewall Configuretion」に変更しました。
とりあえず、SSHの22ポートだけ開けて実験してみることにしました。
VirtualBoxのネットワークが謎
VirtualBoxのホストネットワークマネージャーから、アダプター(ホストオンリーアダプター)を追加しました。
DHCPサーバーの設定も下図のようにしました。
UbuntuServerの設定の方は下図のようになります。
IPv4の設定などは、DHCPにしていますので、自動振り出しにより、IPが192.168.10.2になったようです。
この状態において、ping 192.168.10.2での疎通はできています。
SSHクライアントからこのIPで接続したら、ユーザーとPW入れて接続することができました。
ここから謎なのですが、
ココに注意
全く同じUbuntuServerを準備して、同じように設定してもIPが降られない謎
本当に何度も何度も実験してみましたが原因が分かりません。
UbuntuServerのIPアドレスが、192.168.56.3とかなり、まったく接続できません。
しかたなく固定IPにしてもネットに接続できません。
自分のスキルでは越えられませんでした。
ブリッジアダプター接続
アダプターの割り当てを、ホストオンリーアダプターから、ブリッジアダプターに変更しました。
ココに注意
ホストオンリーアダプタとブリッジアダプタの違いって何???
よく調べずに実験していたので、そもそも使い方を間違っている可能性があります。
下記のサイトによく違いの内容がかかれていました。
自分が実験したい設定は、ブリッジアダプターが正解だったのかもしれません。
UbuntuServerのネットワーク設定は、DHCPを自動にしてあるので、勝手にIPが降られるのですが、VirtualBoxが動いているWindows11パソコンのIPレベルと同じ192.168.1.XXXになりました。
この実験では、192.168.1.79でIPが降られましたので、そのIPからSSH接続したら接続することができました。
ただ謎なのが、固定IPにするとネット接続できなくなるという感じになります。本当に癖があり過ぎてよくわかりません。
TigerVNCで遠隔操作実験(失敗)
ココに注意
UbuntuServer20.04はTigerVNCは相性がわるいのでしょうか!?
sudo apt install tigervnc-standalone-server -y
インストールして、パスワード設定して、起動させても接続できません。
よくわかりませんが、VirtualBoxの環境なのか!?5901ポートでのVNCserverの起動ができないので、5902で起動しました。
そして、サーバーの開いているポートを確認するとちゃんと開いているのですが、外部からnmapなどで開いているポートを確認しても開いていません。
nmap -sT -P0 IPアドレス
ココがダメ
UbuntuServer20.04のufwの挙動が理解できません!
サーバー上では、ufwにてちゃんとポートを開けたのですが、外部から調べると空いてないのです。
試しに、WEBサーバーのnginxをインストールして、80ポートをufwでブロックすればブロックになり、許可すれば許可になるという想定内の動きをしてくれました。
どうしても、TigerVPNを疑うしかないですかねー(?)
TightVNCで遠隔操作実験(成功)
sudo apt update #アップデート sudo apt upgrade #アップグレード sudo apt install xfce4 xfce4-goodies #xfce4インストール sudo apt install tightvncserver #TightVNCインストール vncserver #VNCServer起動 パスワード設定を聞かれる
ココに注意
VNCserverをインストールすると大量のエラー?
ロックファイルがどうの!?ってことで、下記のコマンドを叩けば解消しました。
sudo kill -9 8153(エラーのプロセスID)
さて、
ここでめんどくさいサーバーの設定が必要です。これをやらないと接続できても画面はグレーのままです。
vncserver -kill :1 vncserver -kill :2
とりあえず起動しているVNCserverを停止させました。
次に、viを使ってファイルを修正しました。
vi ~/.vnc/xstartup
チルダ「~」の出し方が分からず苦労しましたが、Shift押しながらバックスペースの2個左です。※キーボードにより違うかも。
viのコマンドを覚えてないので、1行を追加するだけでも大変です。
VNCserverの起動ですが、とりあえず、1番も起動してみると、VirtualBoxが既に使用しているようなメッセージがでてきました。
2番で起動してみるとちゃんと起動したようです。そうなると接続ポートは、5902になります。
次に、ufwにてポート開放をしました。
コマンドから解放してもGUIから解放しても同じ結果でした。
外部からnmapで確認してみてもちゃんとポートが開いているのを確認できました。
実際にVNCviewerで接続してみました。
TightVNCserverなので、TightVNCViewerでないとだめなのかな?って思いましたが、UltraVNCViewerでも、VNCViewerでも接続できました。
ufw(ファイアウォール)の挙動の感想
今回の実験でのufwの動作がよくわからなくて苦労しました。
SSHをインストールしてufwにて22番ポートを開いて接続できたところまでは良かったのですが、VNC接続をしようとTigerVNCserverを入れてから、ufwにて開いたポートが外部からは開いてないという状況が発生し、もちろん接続もできないという状況になりました。
結局、TightVNCserverを入れたら接続もできるようになりました。
ufwのリロードなどもして設定した状態を更新して接続実験などにも挑みましたが、
注意ポイント
(1)ポート閉じても、nmap確認では開いている(逆もあり)
(2)VNC5902ポート開いても、nmap確認では閉じている
などの挙動がわからないのもありますが、とりあえず時間の関係で終わりにしたいと思います。
あと、自分の推測ではありますが、UbuntuServer20.04は、ufwにてポートを開いても、ちゃんとしたプロセスがポートで動いてないとポートが開かないようになっているんじゃないでしょうかね!?
今回の実験では、TigerVNCserverがちゃんとポート待ちで動いてないからポートが開かなかった!と考えられるんじゃないでしょうか。
あくまでも自分の推測です。
ココに注意
再度やったらTightVNCserverでも接続できない状況
あれから、再度Ubuntuをまっさらにした状態からやってみたら、何がわるいのか?TightVNCserverでもポートが開いてくれません。
まったく原因がわかりません。VirtualBox環境なのが原因なのでしょうか?
VirtualBoxでのVNC接続は怪しい
その後、さくらのクラウドにて全く同じ実験をしてみましたが、ちゃんとポートも開けられてVNC接続もできるようになりました。
どうも、VirtualBox環境でのVNC接続に問題があったようです。なにかフィルターでもかかっていたのかもしれません。
上記のリンク先と同じ作業をやってファイアーウォールを5901だけ開けたら接続できました。
途中迷ってしまったのが、UbuntuDisktop環境から、~/.vnc/xstartupのファイルがGUIで確認できなかったので、なんで?ってなっていましたが、隠しファイルになっていました。
あとVirtualBox環境で、おかしな挙動として、VNCで接続できたとしても、グレー画面で何も操作できないという状況になりました。
もちろん、いろいろとグレー画面の対応した結果です。
やっぱり、実機でやった方が無駄な時間を費やさなくてよかったのかもしれません。