ConoHaでIPアドレス追加してからのてんやわんや

[最終更新] 2017年2月12日

このサイトはConoHaのVPS上に構築しています。先日、興味本位でIPアドレスを追加し、「追加IPアドレスを使う|VPSならConoHa」にのっとって設定したところ、色々エラーが起きました。

なんとか落ち着いたと思うのですが、その顛末を。どうも、NetworkManagerは無効化しないほうがよさそうな感じです。

(2017/02/12)ConoHaのページを見ると、いつの間にかNetworkManager無効化の記述が消えていて、このページがよくわからんことになりました。以前はそういう記述があったのです。昔はそうする必要があったが、OS側の対応が進んだとかそういうことなのかもしれません。

スポンサーリンク

状況

追加IPアドレスを使う|VPSならConoHa」の手順にのっとって設定したところ、サーバーの起動から24時間経過した時点で、ネットワークインタフェースeth0が落とされるようになりました。/var/log/messagesに以下のようなログが残っていました。

ntpd[662]: Deleting interface #24 eth0, xxx.xxx.xxx.xxx#123, interface stats: received=498, sent=506, dropped=0, active_time=86400 secs

IPアドレスのところは伏せました。今後同じIPアドレスである保証はない、というか多分またコロコロ変わるで。

素直に読めば、ntpdによりeth0がdeleteされた。ただこれは文面どおりに受け取るべきではないようです(後述)。もう一つポイントは、今回追加したeth1はdeleteされていない点です。

発端

そもそもの発端は、network周りをいじったことです。このサイトではConoHaのVPSを利用していますが、ConoHaには350円/月の追加料金でIPアドレスが追加で一つもらえるというちょっと嬉しいサービスがあります。で、ものは試しと思って追加したのです。

手順については、公式ヘルプの「追加IPアドレスを使う|VPSならConoHa」を参照しました。トラブル発生のタイミング的に、ここでの作業が影響しているものと思います。CentOS 7の場合、以下の作業を行いました。

  • ネットワークインタフェースの設定ファイル/etc/sysconfig/network-scripts/ifcfg-eth1を編集する
  • 経路テーブル(/etc/iproute2/rt_tables)、ポリシールーティング(/etc/sysconfig/network-scripts/rule-eth1)を設定する
  • NetwrokManagerを無効化してnetworkサービスを再起動

eth1は死んでいないことから、新しく追加したネットワークインタフェースの設定周り自体は問題がないように思えます。怪しいのはNetworkManagerの無効化でしょうか。

CentOS 6までは、ネットワークの設定は/etc/sysconfig/network-scripts以下のファイルを直接編集することで行うのが普通だと思いますが、CentOS 7以降は、NetworkManagerの利用を推進されています。が、従来のやり方である、/etc/sysconfig/network-scriptsの変更を反映させるには、NetworkManagerが有効化されていると色々問題があるので、ConoHaのヘルプでは無効化させているのでしょうか。

このへんはsystemd周りでも似たようなことがあって、「Raspberry Pi にGPSモジュールをつけてStratum 0で時刻同期(スタンドアロン) – 或る阿呆の記」の記事では従来のgpsdを利用するため、systemdのサービスであるgpsd.serviceを無効化したりしています。こういうことがあるとモヤモヤします。

対応

/etc/sysconfig/ntpdのOPTIONS変更→ダメ

まずRedHatのドキュメント「Message similar to “ntpd Deleting interface #16 ethX:1 , x.x.x.x#123” in /var/log/messages – Red Hat Customer Portal」に従い、/etc/sysconfig/ntpdを編集して、OPTIONS=”-g”からOPTIONS=”-g -L”としました。これにより、NTPは仮想インタフェースを回避する、とあります。

しかし、これはダメでした。次の手を考えなくては。

etho0のIPを固定→DNSが参照できなくなった

今回編集したeth1はdeleteされず、元からあったeth0だけdeleteされるということで、/etc/sysconfig/network-scripts/ifcfg-eth0の設定ファイルに問題があるのだろうかと、中身を見てみました。

TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="eth0"

DEVICE="eth0"
ONBOOT="yes"

正直なんぞよくわかりません。まったくネットワーク周りは不勉強です。が、気を取り直して、比較のために今回作成した/etc/sysconfig/network-scripts/ifcfg-eth1を見てみます。

DEVICE=eth1
TYPE=Ethernet
HWADDR=hogehoge
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=xxx.xxx.xxx.xxx
NETMASK=255.255.254.0

こちらは随分シンプルです。IPv6周りがないからかな。で、大きな違いとして目立つのは、eth0はBOOTPROTO=dhcpであるのに対し、eth1はBOOTPROTO=staticであることでしょうか。

調べていると、「うるう秒をテストしたら仮想インタフェースが落ちた話 – Limitの日記」という記事があり、以下の記述が参考になりました。

どうやらleap-a-dayによって日付が進み、dhclientがDHCPのリース時間を大幅超過したとみなし、そのときのeth0およびaliasを一度全て落としてしまっているようです。

その後DHCPでeth0は再設定されますが、eth0:0は元に戻らないようです。

syslogにはntpdがinterfaceを削除したようなログが出ますが、ntpdが消すはずはもちろんなく、これはbindしているインタフェースが落とされたことを検知しているだけみたいです。

今回の私のケースとはまた状況が異なるのですが、dhclientがインタフェースを落とすこと、またログの文面ではntpdがdeleteしたみたいに書かれているがそうではないこと、の2点、参考になりました。

そしてまた調べていると、「networking – NTPD seems to delete all network interfaces – Server Fault」の記事を見つけました。これによると、BOOTPROTO=dhcpってあるけど、DHCP使ってるのか?マニュアル「13.2. Interface Configuration Files」によるとBOOTPROTO=noneでいいんじゃないのか、という記述があり、こちらがなんだか本質的であるように思います。

ということで、eth1の設定方法を参考にして、eth0のIPアドレスを固定にしてみました。

しかし……そうすると、今度は、サーバー側からDNSが参照できなくなりました。IPアドレスの固定自体はできて、外部からWebサーバーにアクセスすることはできるのですが……。うーん、どうも、何かの設定がまだ足りないのでしょう。

そもそも、ConoHaのネットワーク構成がどうなっているのかよくわかりませんが、DHCPを使っていないわけではないような気がする。さらに色々調べていると、「dhcp – Interface being deleted – Server Fault」という記事がありました。これによると、CentOS 7のVMでのみ同様の症状が起きているという報告があります。もしかしたらOSのバグである可能性があるのでしょうか。とすると、私の手には余る問題かも……。

NetworkManagerを有効化

もう元に戻そうかと半ば諦めかけつつ、そもそもCentOS 7は、ネットワーク周りはNetworkManagerを使うことを推奨されており、それを無効化してしまっているところに問題の一端があるのではないかと思い、有効化させました。

その状態で再起動したところ、今度はeth0について、DHCPでIPv4のIPアドレスが取得できていませんでした。やはりNetworkManagerを有効化させてはいけないのか?不可思議なのは、IPv6はちゃんと取得できていたことです。謎です。その状態で、いったんNetworkManagerを無効化させてnetworkサービスをrestartさせたところ、今度はIPv4のIPアドレスが取得できました。その状態で再びNetworkMaganerを有効化し、再度networkサービスをrestart。すると、これはIPアドレスをちゃんと取得している。うーん?

謎だなぁと思いつつ、NetworkManagerをenableにしたまま再起動をかけました。つまりさきほどと状況的には変わらない……はずなのですが、今度はIPアドレスをちゃんと取得していました。

謎です。いったい何故最初にやったとき取得できなかったのかわかりません。そしてその状態で1日経過しましたが、特に問題なくサーバーは稼働し続けています。

ううーーーん……。結果として、問題のない状態に落ち着いている、ように見えます。結果的に、やったことと言えば、NetworkMaganerの無効化と有効化を繰り返したことくらいです。しかし……それによっていったい何が変わったのだろう。うーん……勉強しつつ、もうしばらく様子を見ます。

(2016/12/28追記)あれからまたIPアドレスの付与などを色々試しました。どうやら、NetworkManagerは無効化しなければ特にトラブルは起きないようです。

関連コンテンツ

関連記事

スポンサーリンク

コメントを残す

メールアドレスが公開されることはありません。