今年の4月頃からUbuntuを使っているのですが、そのネットワーク設定はよく理解しないままに、ネット上にあるものを適当に使っていました。
Ubuntuを使い始めた当初は、（正規表現っぽく表現すると）「Ubuntu nerwork [configuration|設定]」みたいなキーワードで検索して、Netplanというものがあるらしい、そしてそれはYAMLファイルで設定するらしい、という知識しか持たない状態で、YAMLファイルを適当にいじっていました。
しばらくはそのまま過ごしていたのですが、最近はLinuxに慣れて余裕が出てきたので、「コイツは何なんだ」とちょっとだけ真剣に調べてみました。きっと数日もすればその内容を忘れてしまうので、備忘録兼、誰かのお役立ち情報として記事にすることにしました。
この記事は基本的に公式ドキュメントを参照していますが、僕はLinuxを触り始めてまだ半年も経たない初心者なので、その内容を読み違えているかもしれません。ご注意ください。
※1. NetplanはUbuntu 17.10から利用され始めたということなので、この記事には、それ以前のUbuntuには当てはまらない内容も含まれていると思います。17.10以前の状況までは調べていないので、本当にこの記事の内容が完全に当てはまらないのかどうかまでは分かりません。
※2. ※1のような事情があるので、この記事内で「Ubuntu」と表記した場合はUbuntu 17.10以降を指すこととします。今であればほとんどの方が当てはまるのではないかと思います。
Ubuntuのネットワーク設定の基本構造
まずはNetplanなるコイツは何なんだという話から始めていきましょう。公式ドキュメントはコチラになります。基本的にはそちらを参照していただければいいのですが、とは言え、初めに抑えておくと理解しやすくなる前提知識というのもありますから、それを解説していきます。
Netplanを簡潔に言えば（=知っている人にしか伝わらない方法で、この節をまとめると）、Ubuntuのネットワーク設定を簡単に管理するための仕組みです。「簡単に」と言っても、十分にややこしいではないかと思われるかもしれませんね。その辺りの事情を説明していきます。
まず抑えておいていただきたいのは、Ubuntuではネットワーク設定はフロントエンド-バックエンド形式になっているということです（こちらのHow does it work?にそのようなことが書かれています）。Netplanはそのフロントエンドに当たります。
つまり、NetplanはUbuntuでネットワーク設定の変更や、起動時でのネットワーク設定などを行っているわけではないということですね。あくまでも、Netplanの目的はユーザーにとって分かりやすいインターフェイスを提供することであって、その設定を適用する機能は別に任せているということですね（ややこしく表現するなら、「ネットワーク設定ツールに渡すファイルを生成を制御する設定ツール」といった感じでしょう。わざわざこんなややこしい理解をしなくてもいいとは思いますが）。
そして、その設定の適用・運用を任されている側（バックエンド側）として、NetworkManagerとSystemd-networkd（以降、networkdと表記します）の2つがあると。こう見ると、Netplanは複数のネットワーク設定ツールに対して統一的なインターフェイスを提供していると考えられます。
その動作は、まずNetplanがユーザの書いた/etc/netplan/*.yamlファイルを参照して、その後NetworkManagerか、networkdか、どちらか指定された方の設定ファイルを生成するという流れになっています。
その仕組み上、NetworkManager等の設定ファイルが後からNetplanによって書き換えられてしまう可能性があるため、直接NetworkManagerやnetworkdの設定ファイルを編集するのは、あまりすべきではないように感じられます。公式がどのような見解を出しているのかまでは調べていないので（軽く調べてみたのですが、そのような記事を見つけられませんでした。もしご存知の方がいらっしゃったら、上方ソースを教えていただけるとありがたいです）、実際はそれらの設定ファイルを直接いじっちゃっても問題ないのかもしれませんが。
とりあえず、それがNetplanの立ち位置です。
後は、このNetplanをじゃあどう使えばいいのよって話だけです。
Netplanの使い方
公式ドキュメントにも書かれている通り、Netplanは設定ファイルが無いと何も行いません。その設定ファイルは/etc/netplan/ディレクトリ以下に置くということになっています。
/etcとは何か
netplanの設定ファイルを置くディレクトリとなっている/etcですが、これはstaticな設定ファイルを置くためのディレクトリとなっています。この役割はLinux Foundationによって管理されているFHSという標準仕様によって決められていているものです（あくまでも標準ということは、準拠するかどうかはディストリビューションによるのでしょう）。
staticとはどういうものか分からなかったので調べてみると、管理者によってしか変更されないファイルだということでした。また、同ページには/etcがunshareableだとも表記されており、その定義は、他のホストから利用可能ということでした。おそらくネットワークを介して利用できるかどうかといったことを表しているのだと思います。
以上をまとめると、/etcディレクトリは、ネットワークを介して共有できず、かつ、システム管理者しか変更してはいけない設定ファイルやスクリプトファイルを置いて、バイナリファイル（実行ファイル）は置かないと定められたディレクトリということです。
※1. ちなみに、/etcを説明しているページの注釈[2]にELFという単語がありますが、これはLinuxで実行可能なバイナリファイルの形式を表しています。WindowsではPEという形式のバイナリファイルを実行可能です。いわゆるexeファイルの中身はPEという形式に則っているということですな。このように、実行可能な形式が違っているから、Windowsで動かせる実行ファイルを、そのままLinuxで動かすことはできないのです。
閑話休題
先ほど、Netplanは/etc/netplan/*.yamlを参照すると説明しました。しかし、それは厳密には違うようです。
というのも、FAQのHierarchy of configuration filesという項目に、「設定ファイルは/run/netplan/*.yaml, /etc/netplan/*.yaml, /lib/netplan/*.yamlという3つの場所にあってもよい」とあるので、おそらくそれらすべてを読むのだろうと予想できるからです（面倒なので実験もしていなければ、それ以上の調査もしていませんが）。ですがそれらの内、/runは編集すべきではなく、/libも基本的にはユーザが直接編集すべきではないでしょうから、基本的には/etc以下にのみ注意しておけば十分ということなのでしょう。
同FAQに、「ファイルはアルファベット順に読み込まれ、それまでに読み込んだファイルと、新しく読み込んだファイルで、同じ項目に対して別々の定義を行っていたら、その後者が採用され、それ以外は今までに読み込んだファイルの設定が残り続ける」といったようなことが書かれています。要するに、設定が重複していると上書きして、重複が無ければ、ずっとその設定が引き継がれ続けるということですね。
例えば、IPv4のアドレスを192.168.0.1と定義しているファイルが先に読み込まれていて、後から192.168.0.2と定義しているファイルが出てきたとしましょう。すると、最終的なIPアドレスは192.168.0.2と設定されるということです。
ということは、ファイルの読み込まれる順番がとても重要になってきます。もしもこの順番が逆であれば、IPアドレスは192.168.0.1と設定されることになるからです。
先ほどのFAQでも「アルファベット順」と言及されていましたし、Netplanのドキュメントにも、その順番は辞書順と書かれています。
ここで一つ注意があります。仮に00.yaml, 1.yaml, 10.yaml, 50.yamlという4つのファイルがあったとしましょう。そのとき、まず読まれるのは00.yamlです。それに続いて順に、01、10、50と読まれます。
これは数字が大きくなる順に読み込まれているので分かりやすいですね。しかし、これはあくまでも文字列順に読み込まれています。つまり、数字の小さい方から順に読まれているわけではありません。
仮に00.yaml, 5.yaml, 10.yaml, 50.yaml（1を5に変更しました）というファイルがあった場合、直感的には「00→5→10→50」と読まれることを期待するでしょう。しかし、実際には「00→10→5→50」という順番で読み込まれることになります（検証はしていません）。
なので、読み込まれる順番には注意する必要があります。とは言え、設定を99-my-config.yamlといったように、99で始まる名前で保存すればそのような問題は起きないでしょうから、あまり気にすることでもないのかもしれません。
また、ドキュメントの書き方から推察すると、設定ファイルの名前に数字を使わないこともできるのだと思います（未検証）。しかしデフォルトで用意されている設定ファイルの名前は、数字から始まっています。アルファベットで始まるファイルと、数字で始まるファイルが混在していると、どちらが先に読まれるのか分かりづらいので、数字で開始するように統一すべきだと思います。
「そんなの面倒だ。一つのファイルに設定を書いて済ませてしまえば、ファイルの読み込まれる順番なんて気にする必要がなくて良いじゃないか」と考える方もいらっしゃるかもしれません。つまり、デフォルトのファイルを編集しようじゃないかと。
それは公式が明確に非推奨としているわけではなさそう（それなりに時間をかけて調べたのですが、それを明示的に非推奨とする記事を見つけられませんでした）なので、そのような考え方もありなのでしょうが、個人的にはあまりおすすめできません。
それには2つの理由があります。
公式ドキュメントによれば、cloud-initを利用していると、デフォルトのファイルが/etc/netplan/50-cloud–init.yamlであるらしく、そのファイルは再起動される度に初期化されるそうです。そこにも書かれている通り、デフォルトファイルを変更しても、永続的な変更とはなりません。「cloud-initを使っているかどうか」を意識しなければならないというのは面倒というのが1つ目の理由です。
2つ目の理由は、設定を間違えていたら、そのホスト上で動いているすべてのネットワーク通信が途切れてしまう可能性があるというものです。なので、設定を編集していて、元に戻せなければ、通信ができないままになります。しかし、設定を間違っていても、上手くいくファイルとは別に編集中のファイルを用意しておけば、最悪、その編集中のファイルを*.yamlから、*.yaml.failなどと変更すれば、設定を元に戻せます。
ちなみに、sudo netplan apply tryというコマンドで、YAMLファイルの内容を検査してくれますが、それはあくまでも文法的に正しいかどうかを検査してくれるだけです。その設定の正当性までは保証されません。なので、そのコマンドに頼ればいいというわけでもありません。
ということで、次の節で99-custom-configuration.yamlというファイルを作って設定を書いてみます。
チュートリアル
まず以下のことを行います。
sudo touch /etc/netplan/99-custom-configuration.yamlsudo chmod 600 /etc/netplan/99-custom-configuration.yaml
1で、公式ドキュメントで言われていたディレクトリ以下にYAMLファイルを作って、2で管理者のみが読み書きできるようにしています。これはvimなどでファイル名を指定して保存でも構いませんが、その後アクセス権限を変更する必要があるので、touchで作った方が（アクセス権限の変更忘れば無くなるので）良いと思います。
ちなみに、アクセス権限を変更していないと、sudo netplan tryを実行したときに、アクセス権限がガバガバすぎるぞと警告されます。その警告文は”Permissions for /etc/netplan/*.yaml are too open. Netplan configuration should NOT be accessbile by others.”というものでした。そんなときは、chmodでパーミッションを600に変更してやりましょう。
設定例
僕の環境では、無線LANと有線LANの両方を使っていて、個人的にサーバーを立てて実験したいときなんかは有線を、それ以外の一般用には無線をというように使い分けています。
そこで、仮に作業用PCの192.168.1.0/24を無線に割り当てて、192.168.2.0/24を有線に割り当てるという設定を行ってみることにします。作業用PCのIPアドレスは192.168.2.2/24として、サーバーPCのIPアドレスは192.168.2.3/24とします。そして、無線ルーターのIPアドレスは192.168.1.1、有線ルーターのIPアドレスは192.168.2.1とします。
この場合、宛先が192.168.2.0/24であれば有線LANを使って、それ以外の場合は無線LAN（WiFi）を使うと設定する必要があります。
また、サーバーの実験をするときはIPが固定されていた方が（トラブルシューティングが楽なので）嬉しいのですが、無線LANで想定しているような用途の場合は、自動的にIPが割り振られた方が嬉しいです。ということで、有線には固定IPアドレスを、無線はDHCPでIPアドレスを割り振ってもらうように、それぞれ設定することにします。
ここまで決めたら、後はファイルを編集するだけです。vimでもnanoでも好きなエディタで/etc/netplan/99-custom-configuration.yamlを編集しましょう。ただし、管理者しか読み書きできないようになっているので、sudoを付けてvimやnanoを実行する必要があります。
作業用PCの設定ファイルは次のようになります。
# 作業用PC
network:
version: 2
ethernets:
enp1s0f1:
dhcp4: false
addresses:
- 192.168.2.2/24
routes:
- to: 192.168.2.0/24
via: 192.168.2.1
wifis:
wlp2s0:
dhcp4: true
access-points:
Router1:
password: "123456789"
Router2:
password: "0123456789"
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 8.8.8.8色々と解説しないといけないポイントはあるのでしょうが、ここではdhcp4、addresses、routes、access-pointsという4つを解説します。
dhcp4は、dhcpからIPアドレスを受け取るかどうかを決めています。固定IPアドレスを設定しているときに、これをtrueにするとどうなるのかは分かりません。これはIPv4用の設定で、IPv6用にdhcp6という項目も用意されています。
addressesに、その機器の（より正確には、NIC一つ一つに割り当てる）IPアドレスを決めています。先ほどのDHCP設定では、IPv4用とIPv6用が分けられていましたが、addressesにはIPv4アドレスも、IPv6アドレスもまとめて書くことができます。
routesで、どの経路を使うかを書き、その内容としてtoには宛先IPアドレスを、viaにはどのIPアドレスへと送出するかを書きます。上にあるような設定で、サーバー（IPアドレス=192.168.2.3）宛てのパケットは、192.168.2.1へと送信されるという設定になります。
そしてaccess-pointsでは、無線LANルーターの名前と、そのルーターを利用するためのパスワードを記述します。ここでの注意点としては、ルーターの名前はダブルクォーテーションで囲む必要が無いけど、パスワードはダブルクォーテーションで囲む必要があるということです。
次に、サーバー側は次のようになります。
# サーバーPC
network:
version: 2
ethernets:
enp1s0f1:
dhcp4: false
addresses:
- 192.168.2.3/24
routes:
- to: default
via: 192.168.2.1先ほど解説したことばかりなので、これは解説しません。ですが、addressesが192.168.2.3となっていることにご注意ください。
これらの設定が終わったら、それぞれのPCでsudo netplan tryを実行しましょう。タイムアウトするまでにEnterキーを押せば、その設定が反映されます。タイムアウトはデフォルトでは120秒に設定されています。これが長いと感じるようであれば、例えばsudo netplan try --timeout 10などとすれば、タイムアウト値を10秒に変更できます。
デフォルトではNetworkManagerを利用するようになっていますが、networkdを使いたいのであれば、versionの次の行にrenderer: NetworkManagerと追加する必要があります。
Netplanによる設定は以上となります。
他にも設定例は公式ドキュメントに大量にありますから、何か実現したい設定があれば、そちらを読んでいただければと思います。
まとめ
具体的な設定については公式ドキュメントを読めば大量に書いてありますから、おそらくこの記事の一番大事な内容としては、「Ubuntuのネットワーク設定はフロントエンド-バックエンド形式になっている」ということだと思います。
Netplanの設定ファイルをおける場所としては3箇所あるけど、実際問題、気にする必要があるのは/etc/netplan/ディレクトリ以下だという話もしました。
そこには最初、デフォルトの設定ファイルがあって、それを直接編集するのは公式的には非推奨では無さそうだけど、個人的には非推奨だとも説明しました。そのため、”99-“で始まる名前のファイルを作って、それを編集するのが良いのではなかろうかという提案もしました。
しかしそのとき、新たに作ったファイルのアクセス権限を変更することはよく忘れると、設定を適用しようとしたときに”Netplan configuration should NOT be accesible by others.”と警告されます。なので予め、chmodコマンドでアクセス権限を600に変更しておきましょう。
それ以降は、ネットワークの具体的な設定を書きました。
とは言え、ネットワーク設定については、それなりにネットワーク関係の知識が無いと厳しい物がありますから、この記事の設定例を見ても何を言ってるか分からんと感じた方は、一度ネットワーク関係を勉強してみるのはアリだと思います（僕が間違ったことを言ってるせいで、「何を言ってるんだコイツは」と思われている可能性もありますが）。
以上がこの記事の内容でした。一緒にLinuxの世界を愉しんでいきましょう。
以降、インフラエンジニアに興味のある方必見の紹介です。
ご存知の方も多いと思いますが、このようなネットワーク周りの設定を管理したり、ネットワークの構造を設計したりといったような仕事をする人をインフラエンジニアと呼びます。
最近、そのインフラエンジニアに特化したササエルというスクールが出てきていて、個人的に面白いと感じました。というのも、インフラエンジニアとしての勉強をしようとすると、どうしても実際にルーターやスイッチといった機器を触る必要があります。
そういった機器を触るには、当然ながらそのような機器を用意する必要がありますが、結構な費用が必要です。
例えば、僕はアライドテレシス社製のAT-AR2050Vというルーターを使っているのですが、たしか5万円か6万円かくらいしたと思います。さらに、サーバー用のPCも買おうとすると、仮にRaspberry Piでも1万円以上（おそらく2万円くらい）はしますし、Raspberry Piは他のPCとは少し勝手が違うので、サーバー運用に慣れたいという目的で購入するのはあまりお勧めできません。
じゃあもうちょっと手軽なものといっても、Intel NUCでも5万円とかする上に、SSDとメモリを別途購入する必要があります。そうなると、サーバーPCとルーターを揃えるだけでも10万円以上は普通にかかります。
もちろん、もうちょっと安上がりに済ませることもできると思います。しかし、ルーターは安すぎると機能的に制限が多かったりして、安物外の銭失いとなってしまいそうな印象があります。
しかも、目的に沿わない機種を買ってしまって、余計な費用もかかるかもしれません。
ただインフラエンジニアとしての勉強をしてみたいというだけなのに（僕のようにサーバーを家で運用してみたいと思っているのであればともかく）、失敗のリスクを負ってまでそれほどのお金を使うのはあまり得策とは言えません。
しかし、ササエルではそのようなリスクなしに、サーバーを実際に操作しながら勉強することができるので、十数万円に比べれば、とても安上がりです。それにも関わらず、実際にサーバーを運用している会社が自社用に作っていたカリキュラムだということで、かなり実践的な内容を学べる講座でもあります。
なので、「インフラエンジニアになってみたい」や「インフラエンジニアとしてスキルアップしたい」と考えている方にとっては、これ以上にないくらい、おあつらえ向きの講座と言えるでしょう。
特に、これからの時代はAWSを提供しているAmazonや、Googleドライブを提供しているGoogleだけでなく、Apple、Microsoftなどがインフラエンジニアを解雇するとは考えづらいです。これからの時代はどこでも必要とされるエンジニアを目指すという意味でも、ササエルで勉強するというのは良いのではないでしょうか。
あなたはせっかくインフラエンジニアに興味を持っているのです。今勉強しておけば掴めたはずのチャンスが将来やって来るにも関わらず、今勉強しなかったために逃してしまうというのはとても勿体ないことだと思いませんか？とは言え、あなたの人生はあなたが主人公です。ここで勉強せずに今までどおりに生きていくのも、ここでスキルアップしてチャンスを掴むというのも、どちらでもお好きな方をお選びください。
