CloudStack4.3にしたらSNATされなくなった

closeこれは 2 年 10 ヶ月 26 日 前に投稿されたものです。最新のものではありませんので、間違っているかも知れません。

先日(3月中)、構築していたCloudStack4.2 + KVM環境。
Advancedなゾーンで喜んでいたが、4.3にバージョンアップしてさらに喜んでいた。

しかし、二週間後くらいから「インスタンスから外部へ通信ができない」という障害が出始めた。
(ポートマッピングでの)外部からインスタンスへの通信は大丈夫であり、どうやら送信元NATが機能していない様子。

それからさらに三週間後くらいの今日、ようやく問題の解決ができたので書く。

詳細な内容

すべて仮想ルータのもの。

「eth0」「eth1」「eth2」以外のインターフェースが出来る
よく出るのが「eth3」とか。「eth3」から「eth8」まで出来ていたことがあった。IPアドレスは、すべてeth2と同じ。
ルーティングテーブルがおかしい
デフォルトルート「eth2」、パブリックネットワーク「eth2」でこれは正しいけど、「eth3」もパブリックネットワークとして設定されてしまう。これによる実害はなかったけどきもちわるい(CV.鹿倉胡桃)
iptablesの設定がおかしい
非常に困る。SNAT用設定が、本来「eth2」となるところが「eth3」となってしまう。これによってSNATされずに外に出てしまう。困る。なお、「eth8」まで出来ていたときは「eth3、eth4、eth5...eth8」と何行も設定されていました。

困る。それっぽいのも見つけたけど、未解決のようでうーん。

Re: Cloudstack 4.3 instances can't access outside world
[CLOUDSTACK-6464] [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used - ASF JIRA

試したこと

AgentやManagementの再起動、仮想ルータの破棄…なんかで上手く行ってたらわざわざ記事にしないので、全く効果なかった。

そこで、DBを見てみることにした。。
データベース「cloud」内、「nics」表にNICの情報が書いている。
ここで、仮想ルータのidを調べ、device_id("eth" + device_id で使われる)を見てみたが、「0」「1」「2」とまぁ普通。

そこで、「2」を「3」に変えてみた。
すると、「eth3は作成されなくなり、SNATデバイスもeth2になったが、デフォルトルートが登録されない」という状況に。わけがわからない…。

解決策

もう無理だと判断し、ソースコードを改変し「eth3を作成しようとしていたらeth2に強制変更」という手段を取ることにした。さすがに強引すぎるとは思うが…4.3.1出たらすぐ更新しますから…ということで見逃してほしい。

それがこのパッチです。

仮想ルータに限らずすべてのインスタンスが対象なので、NICを4個以上積むインスタンスにとっては危ない。

さらに、「@@ -2024,6 +2024,7 @@ ServerResource {」の変更は要らないかも知れない。ちょっと下がれば「VPC」って書いているし。
ただ、「devNum++;」したものを普通に使うってどうなんでしょう?「devNum--;」しないとダメじゃないですかね?あ、ちなみに「devNum--;」だけ(@@ -2135,6 +2136,7を触れず)の変更ではダメでした。

もっとも、このソースコード(LibvirtComputingResource.java)が原因というよりは、別のところから渡ってくるパブリックアドレスのリスト(DB?)が原因っぽいのでそれを直さないことには根本的解決にはならなさそう。

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>