LoginSignup
@takapan228

Are you sure you want to delete the question?

Leaving a resolved question undeleted may help others!

Ubuntuサーバー再起動後、dockerコンテナを立ち上げてもiptables にChain DOCKER などが作成されない

Q&A

Closed

LinuxnginxiptablesDockernginx-proxy

解決したいこと

dockerやnginxのリバースプロキシ、letsencryptを用いて構築しているUbuntuサーバーを再起動後、dockerがコンテナを立ち上げてもiptablesを更新しなくなりました。
恐らくですがその影響でkern.logやufw.logにdocker network関係の不審な通信のログが残っている状態です。
また、サーバーも思い通りに動作しなくなっています。
色々調べて試行錯誤しましたが、確信的な原因を見つけられませんでした。また、私自身dockerやサーバー管理初心者かつ、本サーバーも受け継いだものであり、正直下手なことができず、八方塞がりです。
そこで、大変恐縮ですがどなたかご支援いただけますと幸いです。

サーバー環境

OS Ubuntu20.04
docker snapでインストール 20.10.24

サーバーの説明

会社の部署でwebページを公開するために運用しています。
会社のHPがあり、そのサブドメインとして私の部署もWebページを公開しています。そのため、私の扱っているサーバーは会社のルーターのみと直接通信しています。ルーターはハードウェアのインターフェース(LANポート)eno1と接続しています。
ちなみにルーターのIPアドレス、MACアドレスは次のように表記しています。
IP 133,XXX,XXX,XXX
MAC 78:XX:XX:XX:XX:XX
また、eno1のMACアドレスは
f0:XX:XX:XX:XX:XXとなっています

試したこと一覧

sudo systemctl restart docker →　dockerというサービスが見つからないと言われエラー
sudo systemctl restart　snap.docker.dockerd.serviceコマンドでdocker再起動後、docker-compose-upでコンテナ立ち上げ →　何も変わらず
snap/docker/ 内にあるdaemon.jsonファイルの調査　→　特にiptables関連の項目は見つからず
iptablesのchainをクリアして、sudo systemctl restart　snap.docker.dockerd.service →　特に状況は変わらず

発生している問題・エラー

docker compose upでコンテナを立ち上げしてもiptablesにdockerのchainが追加されない
実行したコマンド

docker compose up
sudo iptables -L -n -v | grep -A7 "DOCKER"

出力結果

想定している出力結果の例 (一部)

2872K  961M DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2872K  961M DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      br-2e2f0e5dde0c  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      br-2e2f0e5dde0c  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  br-2e2f0e5dde0c !br-2e2f0e5dde0c  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  br-2e2f0e5dde0c br-2e2f0e5dde0c  0.0.0.0/0            0.0.0.0/0           
2480K  812M ACCEPT     all  --  *      br-76506fe0f613  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
61435 3686K DOCKER     all  --  *      br-76506fe0f613  0.0.0.0/0            0.0.0.0/0

kern.logやufw.logの状態

現在のログ(eno1がルーターと接続しているインターフェース、br-〇〇がdocker networkのブリッジです)

現在、つまり異常が発生しているログではIN=eno1 OUT=br-〇〇などのルーターと接続しているインターフェースに通信が出入りをブロックしているログやdocker networkのブリッジからの通信をブロックしているログが大量にあります。
また、通信の発生源がグローバルIPアドレスであるものがあり、セキュリティ的にも不安が残ります。
さらに、一番下の行を見るとdockerの内部通信もうまく行っていないという状態です。

May 30 09:50:40 XXXXXX kernel: [72972.052621] [UFW BLOCK] IN=eno1 OUT=br-17dae58564d7 MAC=f0:XX:XX:XX:XX:XX:78:XX:XX:XX:XX:XX:08:00 SRC=160.XXX.XXX.XXX DST=172.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=19889 DF PROTO=TCP SPT=55327 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
May 30 09:51:00 XXXXXX kernel: [72991.940968] [UFW BLOCK] IN=br-17dae58564d7 OUT=eno1 MAC=02:XX:XX:XX:XX:XX:78:XX:XX:XX:XX:XX:08:00 SRC=172.XXX.XXX.XXX DST=172.XXX.XXX.XXX LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=9460 DF PROTO=TCP SPT=35444 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
May 30 09:51:21 XXXXXX kernel: [73012.586309] [UFW BLOCK] IN=eno1 OUT=br-17dae58564d7 MAC=f0:XX:XX:XX:XX:XX:78:XX:XX:XX:XX:XX:08:00 SRC=125.XXX.XXX.XXX DST=172.XXX.XXX.XXX LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=61729 DF PROTO=TCP SPT=56862 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
May 30 09:53:31 XXXXXX kernel: [153773.062592] [UFW BLOCK] IN=br-f034a823761c OUT=br-f034a823761c PHYSIN=veth96d198d PHYSOUT=veth57b7cd0 MAC=02:XX:XX:XX:XX:XX:02:XX:XX:XX:XX:XX:08:00 SRC=172.XXX.XXX.XXX DST=172.XXX.XXX.XXX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=10575 DF PROTO=TCP SPT=54758 DPT=3306 WINDOW=64240 RES=0x00 SYN URGP=0

正常に動作していたとき

一方、サーバー再起動前正常に動作していたときでは、会社のルーターのマルチキャスト通信をブロックしているだけのログだけがある状態でした。

May 28 08:44:29 XXXXXX kernel: [5493405.900600] [UFW BLOCK] IN=eno1 OUT= MAC=01:XX:XX:XX:XX:XX:78:XX:XX:XX:XX:XX:08:00 SRC=133.XXX.XXX.XXX DST=224.XXX.XXX.XXX LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=61544 PROTO=2
May 28 08:44:29 XXXXXX kernel: [5493405.900600] [UFW BLOCK] IN=eno1 OUT= MAC=01:XX:XX:XX:XX:XX:78:XX:XX:XX:XX:XX:08:00 SRC=133.XXX.XXX.XXX DST=224.XXX.XXX.XXX LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=18234 PROTO=2
May 28 08:44:29 XXXXXX kernel: [5493405.900600] [UFW BLOCK] IN=eno1 OUT= MAC=01:XX:XX:XX:XX:XX:78:XX:XX:XX:XX:XX:08:00 SRC=133.XXX.XXX.XXX DST=224.XXX.XXX.XXX LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=43274 PROTO=2

ログに関しては正常に動作していない時は会社のルーターのマルチキャスト通信をブロックするだけだったのですが、障害発生後は多くのグローバルIPアドレスからの通信をブロックした形跡があります。

原因が分からず本当に困っております。ご支援いただけますと幸いです。

0 likes

2Answer

HalHarada
@HalHarada
sudo systemctl restart dockerd
docker compose ls
cd .........
cat Dockerfile
cat docker-compose.yml
そして
docker compose stop
docker compose up -d
docker compose ps
もしくは
docker compose down
docker compose build 
docker compose up -d
docker compose ps

デタッチは!

nginxのリバースプロキシ、letsencryptを用いて構築80番portは空いていますか？301リダイレクトしても、80番portは空けてください。

ubuntuの場合ufwがiptableをバックエンドとして用いるのでは？ufwで再設定してはどうでしょうか？

apt remove -y snap
apt update -y ; apt upgreade -y
apt install -y snap

でしょうか？

私もdockerにてブリッジがおかしくなったことがあります。その時はホスト側の再起動とdocker側のbuildでなおりました。
　それ以来、nat設定からhost設定で構築してます。

1Like

Comments

  1. @takapan228

    Questioner

    回答ありがとうございます。
    回答の意味としては、ufwに反映させるルールをiptablesからnftablesに更新するという意味であってますでしょうか?
    また、回答の終盤にあるコマンドはsnapを更新するコマンドに見えるのですが、こちらのコマンドでufwの再設定を行えるのでしょうか?
    お手数ですが回答いただけますと幸いです。

  2. @HalHarada

    ubuntuはsnapをデフォルトでインストール済みですが、アップデートしていないとコンテナ環境(lxc)がおかしくなったことが有ります。ブリッジを作成、削除すると、macアドレスのテーブルが前のアドレスを覚えていると仮説を立てています。

    　iptablesからnftablesへの変更は不要ですが全てufwの操作か、ufwをdisableにして、ルーターのフィルタリングで補うほうが切り分けは簡単です。

    docker を利用するなら、host指定が安定してます。何故なら、ブリッジを持ちたnat設定は他のコンテナの生成時において同じブリッジを用いており、コンテナの生成と削除を繰り返していると、ダメダメになると仮説を立てています。

shigeokamoto
@shigeokamoto

もともと(動いていたころ)はsudo iptables -L -n -v | grep -A7 "DOCKER"でルールを確認できていたのでしょうか？

focalにsnap版dockerをインストールしてみましたが、以下のようにnftを明示しないとルールは確認できませんでした。

sudo iptables-nft -L -n -v | grep -A7 "DOCKER"

これでDOCKER関連のルールを確認できないでしょうか？

ufwのログも外部へ公開しているサーバーなのであれば外部からアクセスがあっても不思議ではないと思いますから通信できないのが問題なのでしょう。

sudo systemctl restart docker →　dockerというサービスが見つからないと言われエラー

以前はこのコマンドが使えていたのであれば、snap版ではなくaptでインストールしていたのかもしれません。
少なくとも何かを変えてしまったから挙動が変わってしまったのだと思います。
作業内容を一つづつ振り返ってみればなにか見つかるのではないでしょうか？

0Like

Comments

  1. @takapan228

    Questioner

    回答有難うございます。
    動いてた頃に`sudo iptables -L -n -v | grep -A7 "DOCKER"` コマンドは実行したことがないので、ルールが確認できていたかは分かりません。
    しかし、Ubutu22.04で作成した検証環境ではDOCKERルールの確認はできており、正常に動作している状態です(ローカルで)。
    また、dockerですが恐らくではありますが今までもsnapでインストールされていると思います。ただlinuxの/etc/apt/apt.conf.d/20auto-upgradesによって自動upgrade機能がオンになってしまっていたため、そこで何か変わってしまったのかなと考えています。
    また、回答で提示して頂いた`sudo iptables-nft -L -n -v | grep -A7 "DOCKER"`のコマンドでDockerのルールが表示されました。
    しかし、Dockerのufwルールが存在するのに、docker networkの通信が上手くいかない理由がよくわかりません。私の調べた結果、近年、iptablesの代わりにnftablesが使われているとあるのですが、そちらと何か関係があるのでしょうか? (例えばdockerではnftablesが使われているなど)

  2. @shigeokamoto

    Ubuntsuのiptablesは legacy とnft がインストールされていて、20.04はlegacyがデフォルトになっていました。(iptablesの使い方は同じでバックエンドが異なる)
    20.10あたりから nft がデフォルトに変わったと思いますので、22.04で作成された検証環境では普通に iptables を使用すると iptables-nft が使われます。
    この為、検証環境では追加されたDOCKERのchainが確認できたのでしょう。

    例えばdockerではnftablesが使われているなど

    iptables-legacy (20.04の標準iptables)でdocker関連のルールが確認できないのでdockerではiptalbes-nftが使われているのだとは思いますがそれ自体は問題なさそうです。

    対して ufw は iptables に対してルールを設定するようなので、ルールがlegacy, nft に散らばってしまっているのではないでしょうか？

    現在の iptables の状態は以下のコマンドで確認できます。

    update-alternatives --query iptables

    Value: /usr/sbin/iptables-legacy になっているはずです

    iptables-nftをデフォルトに変更するには以下のコマンドを入力します。

    sudo update-alternatives --set iptables /usr/sbin/iptables-nft

    これでiptables = iptables-nft になるので、再起動後 iptables の状態を検証用22.04と同様になっているか確認してください。
    なぜ(何をしたから)正常に動作しなくなったかは不明ですが、これでなおりそうな気がします。

    後戻りできないと不安でしょうから、iptablesを元に戻す方法ですが、以下のコマンドを入力すればiptables-legacyがデフォルトになります。(20.04の標準状態)

    sudo update-alternatives --set iptables /usr/sbin/iptables-legacy

  3. @takapan228

    Questioner

    回答ありがとうございます。
    回答の通りにコマンドを実行すると接続が上手くいき、ufw.logも正常なものとなりました。
    ご助力頂きましてありがとうございました。

Your answer might help someone💌

LoginSign Up