はじめに

Mac M4 の UTM で Kali Linux をセットアップするをおこなっていて

macbook 192.168.11.2
kali linux vm
- Shared Network 設定
- 192.168.64.2

という異なる CIDR になっている？ことが気になりました。

そのため、サイトや ChatGPT などに聞きながらどうやって異なる CIDR 間で通信できているのか追っていこうとおもいます。

url: https://docs.getutm.app/settings-qemu/devices/network/network/
title: "Network"
description: "Documentation for UTM virtual machines"
host: docs.getutm.app

前提条件

192.168.11.1 で Baffalo 無線 LAN ルータが動いており、家庭内の LAN の range は 192.168.11.0/24 です。

また、macbook は 192.168.11.2 というアドレスを 192.168.11.1 (ルータ) から DHCP で振られています。 macbook と無線 LAN ルータは Wi-Fi で繋いでいます。 NIC 名は en0 です。

Imgur

❯ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
        ether 
        inet 192.168.11.2 netmask 0xffffff00 broadcast 192.168.11.255
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

UTM で作成した Kali Linux VM の IP アドレスについて

Mac M4 の UTM で Kali Linux をセットアップするで Linux VM を立てたところ 192.168.64.2 で IP アドレスが振られました。これは 192.168.11.2/24 (Wi-FI) の Macbook と比較すると異なるネットワーク CIDR になっています。

┌──(ganyariya㉿utmkali)-[~]
└─$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.64.2  netmask 255.255.255.0  broadcast 192.168.64.255
        ether   txqueuelen 1000  (Ethernet)
        RX packets 70  bytes 22404 (21.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55  bytes 7091 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Network 設定は共有ネットワークになっていました。

Imgur

どうやって kali linux VM は macbook ならびにグローバルネットワークにアクセスできるのでしょうか。 SharedNetwork 設定における場合に、まずどう通信しているのかを見ていきます。

Imgur

各マシンがそれぞれ通信できるか調べる

Kali Linux VM から 192.168.11.2 = macbook に ping してみるとちゃんと通信が通ります。よって、 Kali Linux VM から macbook へはリクエストが送れます。

┌──(ganyariya㉿utmkali)-[~]
└─$ ping 192.168.11.2 -c 1
PING 192.168.11.2 (192.168.11.2) 56(84) bytes of data.
64 bytes from 192.168.11.2: icmp_seq=1 ttl=64 time=0.484 ms
 
--- 192.168.11.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.484/0.484/0.484/0.000 ms

また、実は 192.168.11.101 という固定 IP アドレスで ミニ PC にインストールされた Proxmox OS が有線で Baffalo ルータに接続されています。ここで Kali Linux VM から Proxmox OS ミニ PC へもリクエストが送れました。

┌──(ganyariya㉿utmkali)-[~]
└─$ ping 192.168.11.101 -c 1
PING 192.168.11.101 (192.168.11.101) 56(84) bytes of data.
64 bytes from 192.168.11.101: icmp_seq=1 ttl=63 time=3.61 ms

Imgur

一方で Proxmox OS から Kali Linux VM へ通信を送ってみます。 Proxmox → Kali Linux VM への通信は行えませんでした。

root@pve:~# ping 192.168.64.2 -c 1
PING 192.168.64.2 (192.168.64.2) 56(84) bytes of data.
 
--- 192.168.64.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Macbook → Kali Linux VM への通信は行えました。

gnovel on  main via .NET [☁️ ]
❯ ping 192.168.64.2 -c 1
 
PING 192.168.64.2 (192.168.64.2): 56 data bytes
64 bytes from 192.168.64.2: icmp_seq=0 ttl=64 time=0.676 ms
 
--- 192.168.64.2 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.676/0.676/0.676/nan ms

ここまでの通信の流れをまとめます。

Imgur

またそれぞれの nic もまとめておきます。

Kali Linux VM
- eth0: 192.168.64.2/24
Proxmox
- vmbr0: 192.168.11.101/24
Macbook
- en0: 192.168.11.2/24
- vmenet0
  - IP アドレスなし
- bridge100
  - 192.168.64.1/24
  - member: vmenet0

┌──(ganyariya㉿utmkali)-[~]
└─$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback  brd 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether  brd 
    inet 192.168.64.2/24 brd 192.168.64.255 scope global dynamic noprefixroute eth0
       valid_lft 2746sec preferred_lft 2746sec

root@pve:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback  brd 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether  brd 
3: wlp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether  brd 
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether  brd 
    inet 192.168.11.101/24 scope global vmbr0
       valid_lft forever preferred_lft forever

ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
        ether 
        inet 192.168.11.2 netmask 0xffffff00 broadcast 192.168.11.255
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active
 
vmenet0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        ether 
        media: autoselect
        status: active
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether 
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
        Configuration:
                id  priority 0 hellotime 0 fwddelay 0
                maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
                root id  priority 0 ifcost 0 port 0
                ipfilter disabled flags 0x0
        member: vmenet0 flags=3<LEARNING,DISCOVER>
                ifmaxaddr 0 port 21 priority 0 path cost 0
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

どうして proxmox から Kali Linux VM に通信が送れないのか (Kali Linux VM から proxmox へ通信が送れるのか)

Kali Linux VM → proxmox へどう通信が行われているか

Kali Linux VM → proxmox へ通信は行えています。この通信の流れを追ってみます。

traceroute してみると

162.168.64.1 ルータを経由して
192.1687.11.101 へ到達となっています。

ip route してみると 192.168.11.101 は routing-table にないことがわかります。よって default via 192.168.64.1 dev eth0 proto dhcp src 192.168.64.2 metric 100 でレコードを送ります。 192.168.64.2 を送信元として eth0 NIC から 192.168.64.1 ゲートウェイへ送信しています。

url: https://www.mtioutput.com/entry/iproute-cmd-howtosee
title: "【Linux】ip routeで表示されるdev,via,src,protoの意味と見方 - (O+P)ut"
description: "はじめに ip routeコマンドでよく見るタイトルの文言の意味とその見方を簡単に解説します。 尚、詳細が知りたければman ip routeでも確認可能です。 環境情報 Red Hat Enter Prise Linux Server 7.6 IP-ROUTE(8) dev/via/src/protoの意味 devはパケットを流すデバイス名を指定し dev NAME only list routes going via this device.viaはパケットを流すIPアドレスを指定し via [ FAMILY ] ADDRESS the address of the nexthop rou…"
host: www.mtioutput.com
favicon: https://www.mtioutput.com/icon/link
image: https://cdn.image.st-hatena.com/image/scale/7d3dc1fe316a49856d712b8fc2514921bcc22200/backend=imagemagick;version=1;width=1300/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmtiit%2F20181031%2F20181031093649.png

┌──(ganyariya㉿utmkali)-[~]
└─$ traceroute 192.168.11.101
traceroute to 192.168.11.101 (192.168.11.101), 30 hops max, 60 byte packets
 1  192.168.64.1 (192.168.64.1)  0.638 ms *  0.551 ms
 2  192.168.11.101 (192.168.11.101)  7.476 ms  7.469 ms  7.463 ms
                                                                                                              
┌──(ganyariya㉿utmkali)-[~]
└─$ ip route           
default via 192.168.64.1 dev eth0 proto dhcp src 192.168.64.2 metric 100 
192.168.64.0/24 dev eth0 proto kernel scope link src 192.168.64.2 metric 100

192.168.64.1 は macbook にある VirtualBridge （=スイッチ）です。仮想 L2 スイッチのようですが、 192.168.64.1 という IP が振られておりルータとして機能しているようです。

bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether 
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
        Configuration:
                id  priority 0 hellotime 0 fwddelay 0
                maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
                root id  priority 0 ifcost 0 port 0
                ipfilter disabled flags 0x0
        member: vmenet0 flags=3<LEARNING,DISCOVER>
                ifmaxaddr 0 port 21 priority 0 path cost 0
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

mac の routing-table を見てみると、 192.168.11.101 のときに送信する MAC アドレスがわかっています。そのため、 192.168.64.1 と 192.168.11.2 という 2 つの NIC をもつ Macbook から直接 192.168.11.101 (Proxmox) へ送信できます。

❯ netstat -rn
Routing tables
 
Internet:
Destination        Gateway            Flags               Netif Expire
default            192.168.11.1       UGScg                 en0
default            link#22            UCSIg           bridge100      !
127                127.0.0.1          UCS                   lo0
127.0.0.1          127.0.0.1          UH                    lo0
169.254            link#11            UCS                   en0      !
169.254.169.254    link#11            UHLSW                 en0      !
192.168.11         link#11            UCS                   en0      !
192.168.11.1/32    link#11            UCS                   en0      !
192.168.11.1         UHLWIir               en0   1145
192.168.11.2/32    link#11            UCS                   en0      !
192.168.11.2         UHLWI                 lo0
192.168.11.3       link#11            UHLWI                 en0      !
192.168.11.4         UHLWIi                en0   1184
192.168.11.7          UHLWI                 en0    149
192.168.11.8         UHLWI                 en0      !
192.168.11.17         UHLWI                 en0   1137
192.168.11.100        UHLWI                 en0      !
192.168.11.101        UHLWIi                en0   1181
192.168.11.255       UHLWbI                en0      !
192.168.64         link#22            UC              bridge100      !
192.168.64.2       5a.af.16.42.dc.ab  UHLWIi          bridge100    890

よって 192.168.64.2 から 192.168.11.101 へ通信できるのは想定どおりといえます。

┌──(ganyariya㉿utmkali)-[~]
└─$ traceroute 192.168.11.101
traceroute to 192.168.11.101 (192.168.11.101), 30 hops max, 60 byte packets
 1  192.168.64.1 (192.168.64.1)  0.609 ms  0.531 ms  0.518 ms
 2  192.168.11.101 (192.168.11.101)  8.098 ms  8.091 ms  8.083 ms

どうして proxmox から Kali Linux VM に通信が送れないのか

あらためて proxmox から

macbook bridge100 192.168.64.1
kali linux vm 192.168.64.2

へ通信は送れないことを確認しました。

192.168.64.2 へ traceroute したところ 192.168.11.1 ののち自宅に紐づくグローバル IP xx.xx.xx.xx つまり自宅の外へパケットが送られていました。

 
root@pve:~# ping 192.168.64.2 -c 1
PING 192.168.64.2 (192.168.64.2) 56(84) bytes of data.
^C
--- 192.168.64.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
 
root@pve:~# ping 192.168.64.1 -c 1
PING 192.168.64.1 (192.168.64.1) 56(84) bytes of data.
^C
--- 192.168.64.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
 
root@pve:~# traceroute 192.168.64.2
traceroute to 192.168.64.2 (192.168.64.2), 30 hops max, 60 byte packets
 1  buffalo.setup (192.168.11.1)  0.364 ms  0.384 ms  0.712 ms
 2  xx.xx.xx.xx (xx.xx.xx.xx)  5.671 ms  5.724 ms  5.738 ms
 4  * * *
 5  * * *

proxmox は 192.168.64.2 を知らないためデフォルトゲートウェイの 192.168.11.1 ルータへ転送します。

無線 Baffalo ルータは 192.168.11.0/24 をレンジとしており 192.168.64.0/24 というネットワークを知りません。そのため、グローバル側に流してしまいます。よって、そもそも macbook へ届くことがありません。

この問題を回避するために無線 Baffalo ルータに経路情報を追加してみました。 192.168.64.0/24 の問い合わせが来たら 192.168.11.2 (macbook) へ通信を流すようにしました。

Imgur

すると Proxmox (192.168.11.101) から 192.168.64.2 へパケットが送れました。

Baffalo ルータ 192.168.11.1 へパケットが届く
Baffalo ルータは routing-table を見て 192.168.64.0/24 向けのパケットのため 192.168.11.2 へ転送する
macbook は routing-table をみて 192.168.64.2 の宛先を知っているため bridge100 から kali linux vm へパケットを直接送る

という流れになります。

root@pve:~# ping 192.168.64.2 -c 1
PING 192.168.64.2 (192.168.64.2) 56(84) bytes of data.
64 bytes from 192.168.64.2: icmp_seq=1 ttl=63 time=3.43 ms
 
--- 192.168.64.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.427/3.427/3.427/0.000 ms
root@pve:~# traceroute 192.168.64.2
traceroute to 192.168.64.2 (192.168.64.2), 30 hops max, 60 byte packets
 1  buffalo.setup (192.168.11.1)  0.310 ms  0.604 ms  0.674 ms
 2  192.168.11.2 (192.168.11.2)  4.353 ms  4.344 ms  4.337 ms
 3  192.168.64.2 (192.168.64.2)  6.847 ms  6.839 ms  6.831 ms

❯ netstat -rn
Routing tables
 
Internet:
Destination        Gateway            Flags               Netif Expire
default            192.168.11.1       UGScg                 en0
default            link#22            UCSIg           bridge100      !
127                127.0.0.1          UCS                   lo0
127.0.0.1          127.0.0.1          UH                    lo0
...
192.168.64         link#22            UC              bridge100      !
192.168.64.2       hoge  UHLWIi          bridge100    892

よって、共有ネットワークであっても無線 Baffalo ルータへ強引に宛先設定を追加すれば Proxmox → Kali Linux VM へパケットが送れることが確認できました。

Imgur

ここまでのまとめです。

Kali Linux VM から Proxmox へはパケットが送れる
- Kali Linux VM から macbook へまずパケットを送る
- macbook はルーティングテーブルをみて直接 Proxmox へ転送する
Proxmox から Kali Linux VM は（デフォルトでは）パケットが送れない
- Proxmox (192.168.11.0/24) と Kali Linux VM (192.168.64.0/24) はネットワーク CIDR が異なる
- そのため Proxmox はデフォルトゲートウェイの 192.168.11.1 へ転送する
- Baffalo ルータは見知らぬネットワークパケットのためグローバル側へ送ってしまう→ Kali Linux VM へ届けない
Baffalo ルータに経路を追加で設定すれば Kali Linux VM へ通信が送れる
- 192.168.64.0/24 向けパケットを 192.168.11.2 へ転送するようにする
- すると 192.168.64.2 向けパケットをルータが macbook 192.168.11.2 へ転送してくれる

また、以下の事実もわかりました。

macbook では bridge100 と vmenet0 という NIC が作成されている
- vmenet0 には IP アドレスが振られていない
- bridge100 には 192.168.64.1 という 192.168.64.0/24 のデフォルトゲートウェイとなる IP が振られており、かつ member: vmenet0 という設定がなされている

この bridge100, vmenet0 とはなにかについては別の節で調べます。

SharedNetwork と Bridge Mode の違いについて

url: https://docs.getutm.app/settings-qemu/devices/network/network/#network-mode
title: "Network"
description: "Documentation for UTM virtual machines"
host: docs.getutm.app

ここまでで調査したときのネットワーク設定は SharedNetwork でした。他にも以下の設定があります。

Shared Network
- ホスト OS (mac) とゲスト OS (Kali Linux) がホストの VLAN でルーティングされる
- ゲスト VM 同士は追加設定なしに互いに通信できる
Host Only
- SharedNetwork とほぼ同じだが、ゲスト VM がインターネットにアクセスできない
Bridged
- ホスト OS がレイヤ２ブリッジを特定のインターフェースに向かって作成する

SharedNetwork ではホスト OS (mac) が独自の CIDR サブネットを発行するようです。

一方で Bridged はホスト OS (mac) がもともと所属するネットワーク、つまり今回であれば en0 192.168.11.2/24 と同じ CIDR のネットワークを利用するようです。 Bridged であれば 192.168.11.0/24 をそのまま利用するため Proxmox などから SSH がしやすいです。SharedNetwork の場合は Baffalo ルータに経路情報を追加しないといけないためです。

この理解であっているか確認するために SharedNetwork / Bridged Mode について検証を行います。

SharedNetwork のときに Kali Linux VM の IP アドレスを固定してみる

192.168.64.10 という IP アドレスに Kali Linux VM を固定してみます。 Kali Linux (GUI) は

/etc/network/interfaces
- Linux Kernel 自体が利用するネットワーク設定
network-manager
- RedHat 系列のディストリビューションが利用する追加のネットワークマネージャ

が使えるようです。 /etc/network/interfaces 側で設定した場合、 network-manager は上書きできないはずです。また Server など GUI を含まない場合の Kali Linux は systemd-networkd を利用し、 NetworkManager は利用しません。

今回は一時的な変更のため Network Manager (GUI) で 192.168.64.10 を設定しました。

Imgur

再起動すると 192.168.11.10 と正しく固定されていました。

┌──(ganyariya㉿utmkali)-[~]
└─$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether  brd 
    inet 192.168.64.10/24 brd 192.168.64.255 scope global noprefixroute eth0

また、 Proxmox から 192.168.64.10 にパケットを送れました。これは

macbook が 192.168.64.10 へのルーティングが行える
Baffalo ルータで設定した追加の経路情報が機能していることを表します。

root@pve:~# ping 192.168.64.10 -c 1
PING 192.168.64.10 (192.168.64.10) 56(84) bytes of data.
64 bytes from 192.168.64.10: icmp_seq=1 ttl=63 time=3.52 ms
 
--- 192.168.64.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.520/3.520/3.520/0.000 ms

よって、SharedNetwork で Kali Linux VM の IP アドレスを固定しても問題ないことがわかりました。ただし、 bridge100 (mac) の IP Range 192.168.64.0/24 が急に 192.168.32.0/24 などに切り替わってしまうとこの方法はうまく機能しなくなります。

❯ ifconfig bridge100
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether 
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255

Bridge モードを利用してみる

Imgur

bridge mode に変更すると、 macbook の bridge100 の内容が変わりました。

inet IPv4 192.168.64.0/24 の設定が消えた
member に en0 が増えた
- en0 = 192.168.11.2 であり macbook の Wi-Fi

macbook の Wi-Fi en0 を利用する設定になったようです。

vmenet0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        media: autoselect
        status: active
bridge100: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        member: en0 flags=8003<LEARNING,DISCOVER,MACNAT>
                ifmaxaddr 0 port 11 priority 0 path cost 0
        member: vmenet0 flags=3<LEARNING,DISCOVER>
                ifmaxaddr 0 port 21 priority 0 path cost 0
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

netstat で macbook のルーティングテーブルを見てみると 192.168.64.0/24 が消えました。また、 link#22 = bridge100 を利用する設定が消えました。

❯ netstat -rn -f inet
Routing tables
 
Internet:
Destination        Gateway            Flags               Netif Expire
default            192.168.11.1       UGScg                 en0
127                127.0.0.1          UCS                   lo0
127.0.0.1          127.0.0.1          UH                    lo0
169.254            link#11            UCS                   en0      !
169.254.169.254    link#11            UHLSW                 en0      !
192.168.11         link#11            UCS                   en0      !
192.168.11.1/32    link#11            UCS                   en0      !
192.168.11.1         UHLWIir               en0   1129
192.168.11.2/32    link#11            UCS                   en0      !
192.168.11.2         UHLWI                 lo0
192.168.11.4         UHLWI                 en0   1116
192.168.11.7          UHLWI                 en0   1042
192.168.11.8         UHLWI                 en0      !
192.168.11.17         UHLWI                 en0    382
192.168.11.101        UHLWIi                en0   1194
192.168.11.255       UHLWbI                en0      !

Kali Linux VM は 192.168.64.10/24 に固定されたままです。このとき、 192.168.11.101, 192.168.11.2 へそれぞれパケットが送れません。

これは macbook の bridge100 から 192.168.64.1 が消されてただの L2 スイッチになったためと考えられます。

┌──(ganyariya㉿utmkali)-[~]
└─$ ip addr show         
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.64.10/24 brd 192.168.64.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever

┌──(ganyariya㉿utmkali)-[~]
└─$ ping 192.168.11.101
PING 192.168.11.101 (192.168.11.101) 56(84) bytes of data.
^C
--- 192.168.11.101 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1023ms
 
                                                                                                                  
┌──(ganyariya㉿utmkali)-[~]
└─$ ping 192.168.11.2    
PING 192.168.11.2 (192.168.11.2) 56(84) bytes of data.
^C
--- 192.168.11.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1025ms

Bridge モードは en0 NIC と同じネットワークにしましょう、というものであるため Kali VM を 192.168.11.51 にしてみます。これでパケットが送れるようになるはずです。

Imgur

Kali VM を 192.168.11.51 に変更したところ各種 IP へパケットが送れました。

┌──(ganyariya㉿utmkali)-[~]
└─$ ping 192.168.11.2
PING 192.168.11.2 (192.168.11.2) 56(84) bytes of data.
64 bytes from 192.168.11.2: icmp_seq=1 ttl=64 time=0.694 ms
64 bytes from 192.168.11.2: icmp_seq=2 ttl=64 time=0.522 ms
^C
--- 192.168.11.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1034ms
rtt min/avg/max/mdev = 0.522/0.608/0.694/0.086 ms
                                                                                                                                  
┌──(ganyariya㉿utmkali)-[~]
└─$ ping 192.168.11.101
PING 192.168.11.101 (192.168.11.101) 56(84) bytes of data.
64 bytes from 192.168.11.101: icmp_seq=1 ttl=64 time=10.5 ms
64 bytes from 192.168.11.101: icmp_seq=2 ttl=64 time=7.42 ms
^C
--- 192.168.11.101 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 7.420/8.973/10.526/1.553 ms
                                                                                                                                  
┌──(ganyariya㉿utmkali)-[~]
└─$ ping yahoo.co.jp   
PING yahoo.co.jp (182.22.24.124) 56(84) bytes of data.
64 bytes from 182.22.24.124: icmp_seq=1 ttl=57 time=15.1 ms
64 bytes from 182.22.24.124: icmp_seq=2 ttl=57 time=12.1 ms
^C
--- yahoo.co.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 12.111/13.625/15.140/1.514 ms

よって以下のことがわかります。

Bridge モードにすると Guest OS は Host OS の特定の NIC と同じネットワークに属する
- Host OS(macbook) の en0 = 192.168.11.2/24 と同じネットワークに属する
Bridge モードにすると以下のようなネットワーク設定になる
- bridge100 から IP 設定が消えてただの L2 Switch になる
  - ルータ機能が消える
- bridge100 に member: en0 が追加される

また、以下のような結論になります。

SharedNetwork Mode を使う場合
- ゲスト OS に特定の IP アドレスを振らなくていい場合
- ホスト OS (mac) と異なるネットワークにゲスト OS を配置したい場合
Bridge Mode を使う場合
- ゲスト OS に特定の IP アドレスを振りたい場合
- Proxmox など、自宅ネットワークの好きな機器からゲスト OS に SSH したい場合

自分の場合、Proxmox OS など自宅ネットワーク機器から Kali Linux VM にアクセスしたいです。そのため、固定 IP かつ自宅ネットワークに直接配置したいです。よって、 Bridge Mode を使うのが最適といえます。

発展型: Kali Linux VM を Bridge Mode で動かしながら Ubuntu Server VM を SharedNetwork Mode で動かす

興味がでたため、表題の通りを試してみます。 Ubuntu Server VM を SharedNetwork Mode で動かしつつ、 Kali Linux VM を Bridge Mode で動かします。

Ubuntu Server VM
- SharedNetwork
- 192.168.64.4
Kali Linux VM
- Bridge
- 192.168.11.51

すると vmenet0, bridge100, vmenet1, bridge101 という 4 つの NIC が存在し、あらたに 101 が増えていました。

bridge100 には 192.168.64.1 が割り振られている、かつ vmenet0 が member になっています。一方 bridge101 には IP アドレスが割り振られておらず、かつ vmenet1, en0 が member になっています。

よって、Network Mode ごとに必要な NIC を UTM が用意するようです。

vmenet0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        media: autoselect
        status: active
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
        Configuration:
                id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
                maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
                root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
                ipfilter disabled flags 0x0
        member: vmenet0 flags=3<LEARNING,DISCOVER>
                ifmaxaddr 0 port 21 priority 0 path cost 0
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active
vmenet1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        media: autoselect
        status: active
bridge101: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        Configuration:
                id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
                maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
                root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
                ipfilter disabled flags 0x0
        member: en0 flags=8003<LEARNING,DISCOVER,MACNAT>
                ifmaxaddr 0 port 11 priority 0 path cost 0
        member: vmenet1 flags=3<LEARNING,DISCOVER>
                ifmaxaddr 0 port 23 priority 0 path cost 0
        media: autoselect
        status: active

ここまでまとめ

UTM をつかうと UTM によって macbook に複数のネットワーク設定が追加される
- bridge100 という NIC が作成される
  - 仮想の L2 スイッチ・ブリッジ
  - ただし、 SharedNetwork の場合はルータの機能も持ちデフォルトゲートウェイとなる 192.168.XX.1 が振られる
- vmenet0 という NIC が追加される
  - IP アドレスを持たない

bridge100 と vmenet0 とは何なのか？

挙動として SharedNetwork と Bridge Mode が何なのかを確認してきました。固定 IP を割り振り自宅ネットワークのサーバとして動かしたいのであれば Bridge のほうがよいということも見てきました。

ここで、 UTM が作成する bridgeX そして vmenetX とは何なのでしょうか。ここから書くのは ganyariya が思う想定であり、間違っていたらすみません。

bridgeX

bridgeX は仮想ブリッジであり L2 で動作するものです。ただし、仮想ブリッジとありますが実態としては仮想スイッチです。

また、 SharedNetwork モードの bridge100 を見るとわかるようにどうやら IP アドレスを降ることもできるようです。 その場合 L2 スイッチの機能に加えて network-router の機能も持つといえます。ルータ機能も持てるんですねぇ…。

member として vmenet0 をもち、 bridge100 スイッチのポートに vmenet0 という名前がついているといえます。

また NAPT 機能を UTM が実装していると考えられ、 VM eth0 から vmenet0 に通信が来たときにそれを NAPT として en0 から転送する、ということをやっていると思います。

vmenetX

url: https://gihyo.jp/admin/serial/01/ibm_kvm/0003#:~:targetText=%E4%BB%8A%E5%9B%9E%E3%81%AFKVM%E3%81%AE%E4%BB%AE%E6%83%B3,%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%82%82%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99%E3%80%82
title: "第3回　KVMのネットワーク構成 | gihyo.jp"
description: "今回はKVMの仮想ネットワークの構成について解説します。"
host: gihyo.jp
favicon: https://gihyo.jp/favicon.ico
image: https://gihyo.jp/assets/images/ICON/2011/801-ibm_kvm.png

Imgur

上記の記事における vnet0 = TAP-Device といえます。 L2 のイーサネットデバイスを仮想的にシミュレートするものだそうです。 https://ja.wikipedia.org/wiki/TUN/TAP https://hichtakk.hateblo.jp/entry/2016/04/04/062229

そのため、 vmenet0 は IP アドレスを持たず、イーサネットフレームを Kali Linux の eth0 へ流す、という機能だけを持っているようです。

bridge100 と vmenet0 を踏まえると SharedNetwork はどのような構成になっていたのか

SharedNetwork はおそらく以下のような構成になっていたと考えられます。

Kali Linux VM から Proxmox OS へリクエストを送るときを考えます。 192.168.11.101 は知らない IP アドレスのため Kali Linux VM のデフォルトゲートウェイ 192.168.11.1 へ送ろうとします。これは Kali Linux VM の eth0 (192.168.64.2) からイーサネットフレームを送ります。

bridge100 は内部的に UTM によって管理されており NAPT によって macbook en0 (192.168.11.2) から送信されたパケットとして扱われます。あとは macbook にルーティングテーブルがすでに構築されていれば直接 Proxmox OS へイーサネットフレームならびにパケットが送られます。

Imgur

また、 Bridge については以下のように構成になっていたと考えられます。

eth0 にはユーザが直接割り振った 192.168.11.51 が設定されています。 bridge100, vmenet0 には IP アドレスが振られておらず、 UTM によって en0 へパケットが流されそのまま en0 を経由して他機器へ転送されます。

Imgur

最後に

UTM のネットワーク設定について見てきました。 #VirtualNetwork について知識がなく、色々と回り道でしたが少しは知識がついたとおもいます。

ただ、仮想ブリッジ・TAP デバイスについて知識があやふやであり CTF をやりながらもっとつけていきたいです。

また、仮想ネットワークアプリをつかって大規模ネットワークを組む、ということもやってみたいです。

ganyariya note

エクスプローラー

UTM (Mac) の仮想ネットワークがどう動いているか調べる

はじめに

前提条件

UTM で作成した Kali Linux VM の IP アドレスについて

各マシンがそれぞれ通信できるか調べる

どうして proxmox から Kali Linux VM に通信が送れないのか (Kali Linux VM から proxmox へ通信が送れるのか)

Kali Linux VM → proxmox へどう通信が行われているか

どうして proxmox から Kali Linux VM に通信が送れないのか

SharedNetwork と Bridge Mode の違いについて

SharedNetwork のときに Kali Linux VM の IP アドレスを固定してみる

Bridge モードを利用してみる

発展型: Kali Linux VM を Bridge Mode で動かしながら Ubuntu Server VM を SharedNetwork Mode で動かす

ここまでまとめ

bridge100 と vmenet0 とは何なのか？

bridgeX

vmenetX

bridge100 と vmenet0 を踏まえると SharedNetwork はどのような構成になっていたのか

最後に

グラフビュー

目次

バックリンク