もう20年近くUbuntuで生活して来たわけですが、ついにWindowsとの共存を考えるに至りました。
というのも、マイナンバーカードを使って公的認証サービス(便利!)を利用する際にはどうしてもWindows前提の利用者クライアントソフト(クソアプリ)を使わないといけないのです。WineではICカードリーダーを認識せず挫折。
もうひとつ理由があって、最近のUbuntuは知らない間に魔改造されすぎ。
昔の知識が使えなくなったり似たようなツールをたくさん作りすぎて知識が分散してしまいもう手に負えない。この調子だとUbuntu捨てるかも。
Ubuntuメインか。Windowsメインか。
もうWindowsでいいかな
アプリはWindowsでもLinuxでも同じものが使えるし。むしろドライバ系がちゃんと用意されているWindowsは魅力。
UbuntuでもプリンタやUSBカメラは汎用ドライバでだいたい動くけど、Canon専用紙とかWindows or Mac向けのツールでできるような細かい設定(余白の設定とか)はできない。
そしてWLS2(Windows Subsystem for Linux 2)の出来栄えがかなり良いらしく、アプリケーションとしてUbuntu 20.04が起動できるらしい。Dockerの開発ができるのは嬉しい。
内部的にはHyper-vを使って準仮想化してるので、Windowsの干渉を受けずにUbuntuがそのまま動作するイメージ。ただGUIは使えずコンソール1画面ぽい。
https://docs.microsoft.com/ja-jp/windows/wsl/tutorials/wsl-containers
やっぱりUbuntuメインかなぁ
マルウェアの恐怖を感じながら使うのはちょっとね。Windows 10のパッチが当たるとUbuntuが動かなくなったりしそうだし。
案の定、問題が起きてました。累積パッチを当てるとWSL2が破壊されるとのこと(ﾜﾗ)
https://japan.zdnet.com/article/35159439/
あとはまあ、やっぱり開発がね。
アプリ開発もさることながら、ちょっとした作業を自動化するのにbashからperlやらpythonやら呼び出してちょいちょいってできるのがUNIX系の魅力なので。
WindowsのBatとかpowershellとかもうね、精神衛生的に無理。
昨今のUbuntu界隈はもうついていけないのでそのうち離脱するとして、Windowsに行くかと言うとまあそれも微妙。CentOSかDebianかなぁ。
今回作った環境
KVMでWindows 10を浮かべました。まあそれだけです。Windowsが必要になった時だけ呼び出す感じで。
KVMはVT-xを使えるようにしたカーネルの機能。通常はCPU→OS→仮想CPU→仮想OS→アプリという順番でアプリが動作するためオーバーヘッドが大きい。そこで、インテルはCPU→仮想CPU→仮想OSという動作ができるようにOS層をすっ飛ばすAPIを作りました。これがVT-x。
OS層をすっとばすにはVT-xに直接接続できる機能がLinux Kernel内に必要。これがKVM。最近のLinux Kernelは最初からKVMが取り込まれている。
QEMUは仮想マシンを動かすエミュレータ。ぶっちゃけKVMがなくてもQEMUだけで仮想化はできる。でも前述のとおりめっちゃ遅い。そこでできたのがqemu-kvm。OSをすっ飛ばしてKVM経由でCPUを直接使えるようにカスタマイズされたQEMUと思えばいいです。
Ubuntuで仮想マシンを作る前に
KVMやらQEMUやらの前にLinuxのネットワーク構成とツールのお話しをしましょう。というかこれを理解しないとあとでわけがわからなくなります。
LinuxのNIC設定のおさらい
古典的なUNIX
NICの設定は/etc/rc.config.d/netconfに記載していました。IPアドレスやルーティングテーブル、デフォルトゲートウェイなどはここに記載しておけば、OS起動時にinitから起動されたnetプロセスが設定を読み込んでよろしくやってくれるのでした。
RedHat Linuxは設定をNICごとに分ける方針へ
その後init.dの仕組みが少しかわり、デフォルトGWの設定は/etc/sysconfig/networkへ、NICごとの設定は/etc/sysconfig/network-script/ifcfg-ethx へと移行しました。Red Hat Linux系はこの方式を採用しています。
設定ファイルはNICごとにバラバラになってしまいましたが、OS起動時にnetworkプロセスが設定を読み込むというnetに近い動作をしていました.
しかしRedHat 7以降はsystemctlというシステム管理コマンド経由でnetworkプロセスに設定を読み込ませるという動きに変わっています。
Debianは設定ファイルは１つにするものの制御方式を変更
Debian系のOSは/etc/network/interfacesへと移行しました。考え方はnetconfのように1つのファイルに複数のNICの設定を記載しておくものですが、ifupやifdownというネットワーク設定用の専用コマンドが読み込む定義ファイルとして使われるようになりました。
Ubuntuは18.04移行、netplanという方法を採用しています。
netplanは/etc/netplan/xxx.yamlにNICの設定を記載します。この記載方法はやや特殊でphtyonの様に段落でスタンザを記載します。その後 netplan generateコマンドを実行して/run/systemdの下にあれやこれや設定ファイルを作るという仕組みです。
そしてネットワークの起動はsystemctlに似たserviceというサービス制御コマンドから行います。ややこしい。
更にわかりにくことに、Ubuntu 20.10では以下のとおり”ネットワークの設定はNetwork Managerにおまかせします"という設定になっています。
Network Managerには賛否ありますが、とりあえず設定ファイルがどれかわからなくなってしまうのはシステム移行時にとても困るはずです。
Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager
Linuxのネットワーク系コマンドのおさらい
今も現役 net-tools
UNIXのネットワーク系コマンドと言えばnet-toolsでした。ifconfigやarp、routeコマンドはよく知られている強力なコマンドです。ありがたいことにnet-toolsは今でも現役で使うことができます。
使いやすくなったiproute2
net-toolsに続いて出てきたのがiproute2というツールです。こちらはnet-toolsの軽量版といったところです。
iproute2はifconfig を "ip a"、arpを"ip n"、routeを"ip r"の様に"ip x"というコマンドに統一しようという意図が見えます。
ただ、iproute2は機能が少なく、net-toolsを置き換えるほどの勢いはありません。通常の構築ならiproute2、ネットワークのテストやセキュリティ系の技術を身につけるならnet-toolsの様に棲み分けがあります。
オペレーションの統一なるか Network Manager
現在、Network Managerというツールが普及し始めています。内部的にnet-toolsやiproute2のコマンドをコールしています。
Network Managerの設定ファイルはどこに保存されるかわかりません。ディストリビューションや環境に依存します。逆に言うと環境が違っても同じコマンド(nmcli)で運用できます。
Linuxのネットワークオペレーションを統一してくれるかもしれませんが、設定ファイルがどこにあるかわからないのは気持ちが悪い。
その他の*ctl系コマンド達
nmcliの他にブリッジ(後述)に特化したbrctr、TUN/TAP(後述)に特化したtunctl等の*ctlも使われるようになりました。*ctlでできることはnmcliでもできますが、*ctlはより少ないオプションで同じ機能を提供しています。
疑似ネットワークのおさらい
NICの性能向上と仮想化の進歩により、疑似ネットワークが作られるようになりました。
古典的には１つのNICに複数のIPアドレスを割り当てるIPエイリアスがありましたが、現在は仮想HUBとして使う"ブリッジ"やブリッジに接続できる仮想ネットワークデバイスであるTUN/TAPが使える様になりました。
疑似ネットワークの構成
疑似ネットワークの構成は以下のとおりです。virbr0とかはまだ出てきません。
仮想ブリッジ
仮想的に作られたHUBです。HUBでありながらIPアドレスを持つことができるためブリッジと呼ばれています。
仮想ブリッジを作っただけでは内部ネットワークでしか利用できません。外部と通信する際は物理NICに接続する必要があります。
ブリッジの作成と物理NICへの接続はnmcliかbrctlでできます。通常、ブリッジ名はbr0から順に最後の1桁を追番にします。
TAPデバイス
正式にはTUN/TAPデバイスと呼ばれます。仮想ネットワークインタフェースなのですが、少し変わった特性を持っています。
ブリッジに接続するとブリッジからはHUBのポートとして見えます。一方、仮想マシンに接続すると仮想マシンからはNICに見えます。
この特性を利用して、ブリッジと仮想マシンの両方に接続することで仮想LANを構成できます。
TAPデバイスはifconfigかtunctlで作成できます。おそらくnmcliでも作成できるはずです。
TAPデバイスとブリッジはnmcliかbrctlで接続できますが、仮想マシンとの接続は仮想マシンを管理しているqemuが行います。(後述)
ブリッジやTAPを作ってみる
$ brctl addbr br0 ← ブリッジ作成
$ brctl addif br0 eths25 ← ブリッジと物理NICを接続
$ tunctl -t vnet0 ←TUN/TAPデバイスを作成
$ brctl addif vnet0 br0 ←TUN/TAPデバイスをブリッジに接続
$ nmcli device ←確認
DEVICE TYPE STATE CONNECTION
lo loopback 管理無し --
eths25 ethernet 接続済み 有線接続 1
br0 bridge 接続済み (外部) br0 ←ブリッジができてる
vnet0 tun 管理無し -- ← TUN/TAPができてる
$ brctl show ←確認
bridge name bridge id STP enabled interfaces
br0 8000.5254008a9192 yes eths25 ← br0と物理NICが接続
vnet0 ←br0とTUN/TAPが接続
上記の例ではbr0(bridge)とvnet0(tun)が作成でき、br0とNIC,TUN/TAPが接続されていることがわかります。
仮想マシンを作るとどうなるか
やっと仮想マシンの話にたどり着きました。今まで長々と話してきたのにはわけがあります。
仮想マシンを作るにはvirshというコマンドを使うのですが、このvirshコマンドは裏でいろんなことをします。
virshはKVMだけでなくVMwareやXen等も同じコマンドで管理できる便利なツールです。virshはCLIツールですが、virt-managerというGUIツールもあります。
virshやvirt-managerといった仮想マシン管理ツールはlibvirtというライブラリを使用しています。このライブラリを使えば誰でもvirshのような仮想マシンを管理するツールを開発できます。
https://ja.wikipedia.org/wiki/Libvirt
あまりにいろんなことを勝手にやるので、使っていくうちにどこまでがOSの設定なのかわからなくなり、知らない間にQEMU環境を壊しかねません。
そうならないように、先にOSの機能を説明したのでした。
というわけでvirshを使用した場合の疑似ネットワークです。
DHCPが追加されている
前述のOSだけの疑似ネットワークと比べて大きく違っている点は、DHCPとNATが追加されていることです。
virshやvirt-managerを導入すると自動的にブリッジがvirbr0という名称で作成され、libvirtが提供しているDHCPサーバと接続されます。
ちなみにこのDHCPサーバはdnsmasqというプロセス名で起動しており、設定ファイルは/var/lib/libvirt/dnsmasq/default.confにあります。
$ sudo cat /var/lib/libvirt/dnsmasq/default.conf strict-order user=libvirt-dnsmasq pid-file=/run/libvirt/network/default.pid except-interface=lo bind-dynamic interface=virbr0 ← virbr0に接続 dhcp-range=192.168.122.2,192.168.122.254,255.255.255.0 ← dhcpレンジの割当て dhcp-no-override dhcp-authoritative dhcp-lease-max=253 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
NATが設定されている。ということは...
virber0にはIPアドレスが割り当てられ、iptablesにNATの設定が追加されています。
ということは... そうです。仮想マシンから見てvirbr0のIPアドレスはデフォルトGWに見えるんです。
TUN/TAPデバイスはありません
TUN/TAPデバイスは仮想マシンを起動したタイミングで自動的に作成され、停止とともに削除されます。これらの制御はvirshやvirt-managerが行います。
最後に仮想ネットワークについて
virshを導入すると、疑似ネットワークにはない新しい概念、「仮想ネットワーク」が作成されます。
仮想ネットワークはブリッジ、DHCP、NATをすべてひとまとめにした概念で、最初はdefaultというネットワーク名が割り当てられます。
このネットワークはあとで追加できます。
$ virsh net-list Name State Autostart Persistent -------------------------------------------- default active yes yes $ virsh net-info default Name: default UUID: 0059aa64-3fa8-4ddc-afa7-6ec756219701 Active: yes Persistent: yes Autostart: yes Bridge: virbr0 $ virsh net-dumpxml default | grep "ip address" ip address='192.168.122.1' netmask='255.255.255.0' $ virsh net-dumpxml default | grep "forward mode" forward mode='nat' $ virsh net-dumpxml default | grep "range" range start='192.168.122.2' end='192.168.122.254' $ virsh net-dhcp-leases default Expiry Time MAC address Protocol IP address Hostname Client ID or DUID ----------------------------------------------------------------------------------- 仮想マシンが起動するとここに割り当て済IPアドレスが表示される
上記の例ではdefaultという名称のネットワークにはvirbr0というブリッジがあり、192.168.122.1というIPアドレスが設定されています。
また、NAT機能とDHCP機能を持っており、DHCPレンジは192.168.122.2〜254であることがわかります。
おさらいはここまで
以上、Linuxのネットワーク関連のおさらいとvirshが作る疑似ネットワークのお話しでした。
長かった。しかもここまでの話は全く知らなくてもvirshやvirt-managerを使えば簡単に仮想マシンを作れちゃいます。
では引き続き仮想マシンを作ってWindows 10をインストールします。
仮想マシンを作る
疲れたから後日
Windows 10をインストールする。
疲れたから後日
利用者クライアントソフトをインストールする
疲れたから後日