💻

仮想サーバー(M1 Mac, UTM, Ubuntu Server) & ネットワークモード:ブリッジ環境下で、IPv4アドレスを静的化

2025/04/16に公開

昨日の午前中、仮想サーバーにおける名前解決の問題を解消して、外部との通信を行えるよう修正した。
しかし、夜10時頃に再度確認してみると、またIPv4アドレスが表示されていない。
ping google.com を実行しても、当然 Temporary failure in name resolution が出力される。
これは一体どう言う事？と思い、色々調べてみた。

1. 名前解決ファイルの確認

まず、以下のコマンドでファイルを確認してみた。

sudo nano /etc/systemd/resolved.conf

すると、DNSとFallbackDNSの箇所には以前設定したアドレスがきちんと保存されている。
次に、名前解決のステータスを確認してみた。

2. ステータス確認

sudo systemctl status systemd-resolved

このコマンドで、systemd-resolvedが active: inactive (dead) と表示されたので、次にアクティブ化するようにした。

sudo systemctl enable systemd-resolved
sudo systemctl start systemd-resolved

そしてもう一度ステータスを確認すると、アクティブ化された事を確認した。
次に、シンボリックリンクが間違っていないかを確認してみた。

3. シンボリックリンクの確認

ls -l /etc/resolv.conf

リンボリックリンクを確認すると、本来のリンク先とは違うパスが渡されていた。

runの後が一文字違い

correct
/run/systemd/resolve/stub-resolv.conf
incorrect
/run/sytemd/resolve/stub-resolv.conf

このように、リンク先に微妙な間違いがあったので、新たに作成し直した。

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

これでシンボリックリンクの修正が完了したが、依然としてIPv4アドレスは表示されないままであった。

4. 何故表示されないのか、さっぱりわからん

それから色々と設定を確認したり調べたが、やはりアドレスは表示されない。
ただ、一つ解決の糸口になりそうなログを発見した。

sudo resolvectl status

↓(一部抜粋)

Link 2 (enp0s1)
  Current scopes: none
  protocols: -defaultroute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

この結果について調べると、どうやらネットワークインターフェースに名前解決のためのDNSサーバーを所持していない、と言う意味らしい。と言うことは、DNS設定を見直せば解消出来るかもと希望が一筋見え始めた。

5. まずはDNSサーバーの設定

以下のコマンドで、DNSサーバーの設定を行う事から始めた。

sudo resolvectl dns enp0s1 8.8.8.8　* enp0s1 ← この部分は、自身の通信環境によって変化するので要確認

sudo resolvectl default-route enp0s1 yes
sudo systemctl restart systemd-resolved

これらのコマンドでも、まだ名前解決の問題はそのままだった。しかし、 sudo resolvectl status を入力すると Current Scopes: none はそのままであるが、 DNS Servers: 8.8.8.8 という項目が追加されたので、一定の進展があった。

6. 今度はIPアドレスの設定

sudo ip addr add 任意のIPv4アドレス/24 dev enp0s1
sudo ip route add default via 任意のデフォルトゲートウェイ
ping google.com

これでも、まだ接続は出来なかった。

7. systemd-resolvedの再起動で、ようやくIPv4アドレスの表示を確認

sudo nano /etc/systemd/resolved.conf でDNS・FallbackDNSサーバーの設定が問題無い事を確認して、以下のコマンドで名前解決システムの再起動を行った。

sudo systemctl restart systemd-resolved

これでようやくアドレスの表示を確認し、他の端末からもアクセス出来るようになった。長かった。

8. IPアドレスの固定化(静的化)を試みる

今回は名前解決の問題を解消出来たが、また一定時間後にIPアドレスが変更された際に同様の手順を踏むのは面倒である。
なので、ホストマシンや仮想サーバーを再起動してもIPアドレスが変化しないようにしてみた。
sudo nano /etc/netplan/01-netcfg.yaml を入力して、設定ファイルを開く。

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: false
      addresses:
        - 固定化したいIPアドレス/24
      gateway4: 任意のデフォルトゲートウェイ
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

その後 sudo netplan apply で設定を適用し、仮想サーバー・ホストマシンを再起動してもIPアドレスが固定化されているかを確認した。
すると、きちんと固定化されている事を確認した。

一つ疑問なのは、 dhcp4: false を設定しても動的IPアドレスが取得されている事である。これに関しては現時点で原因が分からないが、一先ず名前解決が上手く行ったのでこのままにしておく。
もしまた何かしたの問題が発生したら、その時に解決を試みる。
少し調べると、ネットワークモードがブリッジである事も影響している可能性がある事が示唆されていた。

9. 追記 ChatGPT:Deep Researchの調査内容

以下は、ChatGPTでDeep Researchを行った時の出力内容である。結果表示まで30 ~ 40分は掛かりそうだったので、自分は寝る前に質問しておいた。
朝に確認すると、大量のテキストが出力されており内容を詳細にまとめてくれたので、理解の促進に役立った。また時間を見つけては、少しずつ読み進めていく。

以下は原文そのままをコピペしたものである。

1. Wi-Fi環境でブリッジモードがIPv4を取得できない原因

UTMをM1 Macでブリッジモード動作させ、ホストがWi-Fi接続の場合、ゲストVMがIPv4アドレスを取得できなくなるのは珍しくありません。主な原因としては以下が考えられます。

macOSの仕様制限: Apple公式によれば、Wi-Fiインタフェースでは仮想ブリッジを使用できないとされています。これはWi-Fiのプロトコル上、クライアント側（Mac）が複数のMACアドレスを外部ネットワークに露出させることができないためです。その結果、ブリッジモードではVMが独自のMACアドレスで通信できず、DHCP要求が正常に届かないためIPv4の割り当てが失敗します。
仮想化ソフト側の挙動: Parallels社の知見によると、Wi-Fi経由のブリッジではVMはホストと同じMACアドレスを共有する方式になる場合があり、それでも仮想マシンにIPが割り当てられない事例があるとされています。このようにホストのネットワーク識別子を使って“便乗”する形になるため、DHCPサーバから見て既にホストにIPを払い出している状況では、VMには新たなIPv4が与えられず競合や拒否が発生します。
Wi-Fiデバイスとアクセスポイントの制約: VirtualBoxの事例でも、Wi-Fiへのブリッジは環境次第で動作が不安定（一部のホストでは有線でないと動かない）と報告されています。多くのWi-Fiルーター/APは、一つの無線クライアント（= Mac）から複数の端末(MACアドレス)が接続してくることを想定しておらず、2台目以降のデバイスのパケットを破棄することがあります。その結果、UbuntuゲストからのDHCPパケットがAP側で無視され、初期起動時にIPv4が取得できてもリース更新ができず時間経過や再起動でIPv4が消失する状況につながります。
共有ネットワークのポリシー: 賃貸マンション等の共用インターネットでは、接続台数やMACアドレスに制限がある場合があります。のように事前にデバイスのMACアドレス登録が必要だったり、各契約者あたりの接続端末数が制限されていることもあります。この場合、仮想マシンをブリッジ接続するとホストとは別のMACアドレスがネットワークに現れるため、ネットワーク側で追加端末とみなされブロックされる可能性があります（DHCPサーバが2台目にIPを割り当てない、一部または全ての通信を遮断するなど）。結果として、ゲストVMだけIPv4取得やDNS通信が失敗する状況になり得ます。

以上の要因により、Wi-Fi経由のブリッジ接続ではIPv6アドレスのみ取得しIPv4が得られない（リンクローカルやRA経由のIPv6は見えるが、IPv4はip aで表示されない）現象が起きます。IPv4がないためDNS問い合わせもできず、ping google.comで“Temporary failure in name resolution”というエラーが発生していました。つまり根本原因は物理的なWi-Fiブリッジの非対応とネットワーク側のIP払い出し制限にあり、DHCPによるIPv4割り当てが継続的に失敗していたのです。

2. Ubuntu Server 24.04における静的IPアドレスの設定方法 (systemd-networkd/netplan)

上記の問題に対処する一つの方法として、ゲストOS内でIPv4アドレスを固定設定することが挙げられます。Ubuntu Server 24.04 LTSではデフォルトでNetplan（バックエンドはsystemd-networkd）が使用されています。以下に、仮想マシン内で静的IPアドレスを設定する手順を示します。

1. インタフェース名の確認: Ubuntu内でip aコマンドを実行し、ネットワークインタフェース名（例: enp0s1 や eth0）を確認します。UTMの仮想NIC (virtio-net-pci) は通常enpXsY形式の名前になっています。ここでは仮にenp0s1を使用します。
1. Netplan設定ファイルの編集/作成: sudo nano /etc/netplan/01-netcfg.yaml 等のコマンドでNetplanのYAML設定ファイルを編集します（ファイル名は環境によって異なりますが、/etc/netplan/配下の.yamlファイルを1つ開けばOKです）。内容を以下のように静的IP設定に変更します（<...>部分は環境に合わせて置き換えてください）。

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: no
      addresses: [<固定したいIPv4アドレス>/24]
      gateway4: <デフォルトゲートウェイのIPv4アドレス>
      nameservers:
        addresses: [<DNSサーバ1のIP>, <DNSサーバ2のIP>]

上記は例としてdhcp4を無効化し、固定IPアドレス/サブネットマスク（CIDR表記）、ゲートウェイ, DNSサーバを指定しています。はUbuntu 18.04での例ですが、24.04でも書式は同様です。このとき、サブネットマスク・デフォルトゲートウェイ・DNSの値には、ホストMacがWi-Fi経由で取得しているネットワーク情報と同一のネットワークを設定してください。例えばホストが「192.168.1.0/24」ネットワークでIPを取得しているなら、ゲストにも192.168.1.xxx/24の未使用アドレスを割り当て、ゲートウェイやDNSはホストと同じ「192.168.1.1」（ルーターのIPなど）を指定します。静的IPはDHCPの割当範囲と衝突しない値を選ぶことも重要です。

1. 設定の適用: ファイルを保存したら、sudo netplan applyコマンドで設定を適用します。エラーが出なければNetplanによる新しいネットワーク設定が反映されます。続けてip aでインタフェースに期待したIPv4アドレスが設定されていること、ip routeでデフォルト経路(via <gateway>)が設定されていることを確認してください。
1. 永続性の確認: 再起動しても設定が維持されることを確認します。Netplanの設定ファイルに書いた内容は永続化されるため、再起動後もip aで同じ静的IPv4が表示されるはずです。もし表示されない場合はYAML書式の誤りなどを再チェックしてください。

これでUbuntuサーバー側は固定IPアドレスで動作するようになります。例えば上記の設定ではaddresses:に192.168.1.50/24、gateway4: 192.168.1.1、nameservers: 192.168.1.1, 8.8.8.8等を指定することで、DHCPサーバを介さずともインタフェースenp0s1がIPv4を持つようになります。

3. 静的IP設定によるDNS解決と外部アクセスの安定性

静的IPアドレスを設定することで、少なくとも仮想マシン内部ではIPv4アドレスが消失する問題は解消されます。具体的な効果と考慮点は以下の通りです。

名前解決エラーの解消: IPv4が失われていた原因はDHCP不良によるアドレス未取得でしたので、静的IPを割り当てることでインタフェースは常に有効なIPv4を持ち続けます。あわせてNetplanでDNSサーバのアドレスを指定したため、/etc/resolv.conf（systemd-resolved経由）にも適切なnameserverが設定されます。その結果、ping google.com等の名前解決も**「一時的な解決不能」エラーが発生せず安定**することが期待できます。実際、VirtualBox環境での類似ケースでも「Ubuntuのネットワーク設定で静的IPを正しく設定し、ホストと同じサブネット・ゲートウェイ・DNSを使えばよい」と助言されており、正しい設定下ではDNS問い合わせも正常に通るようになります。
外部からのアクセス性: ブリッジモードでゲストに固定IPを振った場合、同一ネットワーク内の他端末からゲストのIP宛に直接接続できる利点があります。例えばホストと同じサブネット上のPCやスマホから、Ubuntuサーバーの固定IP (192.168.1.50 など) に対してSSHやHTTPでアクセスできます。仮想マシンを再起動してもIPが変わらないため、常に同じアドレスでサービス提供が可能です。これはDHCPに頼る場合と比べて外部（同ネットワーク上のクライアント）から安定したアクセスを実現します。
安定動作の検証: 静的IP化によりネットワークが安定するかは環境依存ですが、一部ユーザからは「ブリッジ接続でうまくいかなかったVMが、静的IP割当によって解決した」という報告もあります。特に原因がDHCPサーバからのリース取得失敗だけであれば、静的設定で通信自体は成立する可能性が高いです。ただし後述するように、ネットワーク側でMACアドレス自体が制限されている場合は、静的IPを設定しても物理ネットワーク側でパケットが遮断されうる点に注意が必要です。
IPv6とDNSの補足: 仮想マシンが取得していたIPv6アドレス（リンクローカルやグローバル）は、Wi-FiブリッジでもルーターのRAを受け取れれば設定されることがあります。しかしDNSサーバがIPv4アドレスしか通知していない場合や、通信経路上に問題がある場合、IPv6があっても名前解決に失敗することがあります。今回の静的IP設定ではIPv4経由のDNSも明示しているため、そうした問題も回避できます。また必要に応じてnetplanでdhcp6: noにした上でaddresses:にIPv6のプレフィックスを指定し、IPv6アドレスも固定化することもできますが、一般的なマンションネットではIPv6の運用形態が不明な場合も多いため、まずはIPv4のみ固定で様子を見るとよいでしょう。

総じて、静的IP設定は仮想マシン内部におけるIP消失とDNS不安定の問題を解決する有力な手段です。ただし根本原因がネットワーク側の制限に起因する場合、静的IPを設定しても外部への通信ができない可能性があります。その場合は次の節の対応も検討してください。

4. マンション共用ネットワークでブリッジモード利用時の留意点

共用インターネット環境下でブリッジモードを使う際には、ネットワーク側の制限事項も考慮する必要があります。以下の点を確認してください。

MACアドレス制限: 前述の通り、一部のISPや共有ネットでは登録されたMACアドレス以外は接続できない仕組みがあります。この場合、仮想マシンのMACアドレスを事前に登録するか、登録が不可能ならブリッジ接続自体を諦める必要があります。管理者に問い合わせて追加デバイスとして承認してもらえるなら手続きを行ってください。さもなくば、ホストとゲストでMACアドレスを共有するモードが提供されていない限り（UTMにはその機能は基本ありません）、仮想マシンの通信はブロックされます。
同時接続台数制限: 共有回線では1契約あたりの端末台数上限が設けられていることがあります。例えば「最大4台まで」などの制限があると、5台目以降はDHCPでIPが貰えなかったり強制的にインターネットアクセスが遮断されます。ブリッジモードのVMはホストとは別端末と数えられるため、この台数制限に抵触する可能性があります。もしご自身の利用端末が既に上限に達している場合、VMは常にネットワークから締め出される状況になります。
DHCPサーバの動作とIPアドレス枯渇: マンション側のDHCPサーバが一度に払い出すIPアドレス数を制限していたり、リース期間の管理が厳しい場合も影響します。ホスト(Mac)が既に1つIPを取得している状態で、同一回線上で2つ目のIPを要求すると拒否されるケースがあります（ISP提供の回線などでは典型的です）。この場合静的IPを割り当てても、ルーター側が未承認のIPとしてパケットを破棄することもあります。加えて、共有ネットワーク全体でIPv4アドレスプールが不足している場合、追加デバイスにIPを割り当てられないことも考えられます。
セキュリティ（クライアントアイソレーション）: 共有Wi-Fiでは、利用者同士の通信を遮断する「クライアントアイソレーション」が有効になっていることもあります。その場合、たとえVMがブリッジで同一ネットワークに接続できても、他の部屋やデバイスからVMへのアクセスはブロックされます。マンション内の別の端末からサーバーを公開する目的には適さない可能性があります。この制限は利用者側では解除できません。

以上の点から、マンション共用回線でブリッジモードを利用するのは技術的・運用的ハードルが高いことが分かります。特にWi-Fiしかない環境では物理的制約もあり、安定運用が難しくなります。

5. 再起動後も安定したIPv4接続を維持する構成方法の提案

以上を踏まえ、UTM上のUbuntuサーバーをブリッジモードで運用しつつ再起動後も安定してIPv4を保持し、外部アクセスとDNS解決が可能となるような構成手順を提案します。

1. 可能なら有線接続を検討: 最も確実なのはホストMacをWi-Fiではなく有線LANでインターネット接続することです。Ethernet経由であればmacOSでも仮想ブリッジを構成できます。USB-Cアダプタなどで有線LANに接続し、UTMのネットワーク設定でNetwork Mode: Bridged (Advanced)かつBridged Interface: Ethernetを選択すれば、VMも問題なくIPv4を取得できるでしょう。マンションの壁のLANポート等が使える場合はこの方法を優先してください。
1. Wi-Fiブリッジを使う場合は環境確認: やむを得ずWi-Fiブリッジにする場合、まずマンション側のネット接続ルールを確認します。利用規約や案内にデバイス台数制限や登録手順について記載がないか調べましょう。必要に応じて仮想マシンのMACアドレスを登録できるなら事前に行ってください（UTMの仮想NICのMACアドレスは設定画面で確認可能です）。また、ホストMacがポータル認証しているWi-Fiの場合、ゲストVMも別途ポータル認証が必要になるかもしれませんが、一般的に仮想NICにはブラウザ認証の画面は出せないため、この場合はブリッジ接続は諦めて次の手段に移ります。
1. Ubuntuゲストに静的IPを設定: 上述した手順に沿ってゲストOS内でIPv4アドレスを固定します。のようにNetplanの設定ファイルを編集し、DHCPを無効化して手動でIPアドレスを割り当ててください。例えば以下のような設定です（環境に合わせて変更）。

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: no
      addresses: [192.168.1.50/24]    # ゲストに割り当てる固定IP
      gateway4: 192.168.1.1          # ルーター（ゲートウェイ）のIP
      nameservers:
        addresses: [192.168.1.1, 8.8.8.8]  # DNSサーバ（ルーターや公共DNS）

上記を適用後、Ubuntuが 192.168.1.50（例）という固定アドレスを持ち、192.168.1.1経由で外部に出てDNS解決できる状態になります。重要: 固定するIP (192.168.1.50の部分) はネットワーク内で重複していない値を選びましょう。不安な場合、一度ホストを含めた既存端末のIPリストを確認し、DHCPサーバの払い出し範囲の外かつ未使用のアドレスを指定するのが安全です。

1. ネットワーク疎通の確認: 静的IP設定後、仮想マシンからホストやルーター宛にpingを実行して疎通を確認します。次にping 8.8.8.8（DNSサーバへのICMP）やping google.comを試し、インターネット接続および名前解決が成功するかをチェックします。問題なく通信できる場合、VMの再起動やホストの再起動を行っても設定が保持されることを確認してください。もしここでまだ名前解決できない場合は、DNS設定が正しいか（例ではルーター経由かGoogle Public DNSを併記）や、ネットワーク側で仮想マシンの通信が遮断されていないかを再度確認します。
1. 外部からのアクセス性テスト: 同一ネットワーク上の別の端末（例えばホストMac自身やスマホ等）から、仮想マシンの固定IP宛にアクセスしてみます。UbuntuサーバーにSSHを入れているなら ssh <ユーザー>@192.168.1.50 のように接続、またはApache/Nginxを立てているならブラウザでhttp://192.168.1.50にアクセスし、サービスが外部から利用できるか確認します。ブリッジモード＋静的IPであれば、ホストからだけでなくLAN内の他端末からも直接アクセス可能なはずです。アクセスできない場合、ファイアウォール(UFWなど)やホスト側の設定を確認してください。
1. 代替策の検討: 万一、上述の手順でも安定した通信が得られない場合（例えばどうしてもDHCP以外認められず通信できない、ポータル認証が障害になる、など）、UTMのネットワークモードを「共有 (NAT)」に戻すことを検討します。共有ネットワーク(NAT)モードではホストMacがルーター代わりとなり、VMには192.168.64.xといった内部IPが付与されます。この場合、VMからインターネットへの接続は安定しますが外部から直接VMへはアクセスできません。しかしポートフォワーディングを設定することでホスト経由でのアクセスは可能です。で指摘されているように、MacのWi-Fi環境ではNATモードの方がトラブルが少ない傾向があります。どうしてもブリッジが無理な場合の妥協策として覚えておいてください。

以上の構成により、可能な限り現在のWi-Fi環境下でもUbuntuサーバーの仮想マシンが安定してIPv4アドレスを保持し続けることが期待できます。ポイントは、Mac側の物理的制約を回避しつつ、ネットワーク設定を手動調整してDHCP依存を減らすことです。今回提案した手順で環境を整えれば、再起動後でも仮想マシン上でip aにIPv4が表示され、DNSも引けてインターネットに接続可能な状態を維持できるでしょう。ぜひ一度お試しください。

参考文献・情報源: Appleサポート記事、Parallelsナレッジベース、Ubuntu公式ドキュメント、各種フォーラムの報告など。