ArchWiki - 利用者の投稿記録 [ja]

Kubernetes

2021-11-05T20:36:07Z

Grainrigi: 最新のパッケージに合わせ更新

[[Category:仮想化]]
[[en:Kubernetes]]
[https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ Kubernetes] はコンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するためのオープンソースシステムです。Kubernetes は k8s とも呼ばれます。

== Arch Linux の Kubernetes ==

=== Minikube ===

MiniKubeは[[VirtualBox]]などの仮想マシン上に小さなKubernetesクラスタを構築することが出来るプラットフォームです。
Kubernetesを試してみたいという場合、完全なインストールをいきなり用意するよりもMinikubeを利用するのが良いでしょう。

Arch LinuxでMinikubeを利用するには、{{Pkg|minikube}} パッケージおよび、{{Pkg|virtualbox}}などの仮想化環境をインストールします。

実際のminikubeの操作法については[https://kubernetes.io/ja/docs/setup/learning-environment/minikube/ 公式のチュートリアル]を参照してください。

=== 完全なインストール ===

Arch Linux で Kubernetes を使用するためには、{{AUR|kubelet-bin}}, {{AUR|kubeadm-bin}}, {{AUR|kubectl-bin}}をインストールします。
Kubernetesを実際に動作させるには、{{Pkg|docker}}や{{Pkg|cri-o}}などのコンテナランタイムも予めインストールしておく必要が有ります。

また、必要に応じて以下のパッケージをインストールします。

* {{AUR|cni-bin}}: [https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ CNI(Container Network Interface)プラグイン]を動作させるのに必要なバイナリパッケージ。標準のCNI(flannel等)を利用する場合、これは必須です。

== Arch Linux の Kubectl プラグイン ==

[https://kubernetes.io/docs/reference/kubectl/overview/ Kubectl] プラグインは独立したバイナリであり、サブコマンドを追加して Kubectl の機能を拡張します。

Arch Linux には Kubectl プラグインの AUR パッケージが存在します:

* {{AUR|kubectl-trace-git}}: kubectl を使って kubernetes クラスタの bpftrace プログラムをスケジュールします。

== 基本設定 ==

{{ic|kubeadm}} ヘルパーを使用するか手動で kubernetes クラスタを設定します。

=== kubeadm を使う ===

以下はマスターとスレーブがひとつずつの構成を取っており、両ノードとも {{ic|192.168.122.0/24}} ネットワーク内に存在し、マスターは kubernetes クラスタを {{ic|192.168.122.1}} でホストします。

また、ポッドに割り当てるIPアドレス範囲(CIDR)は利用するCNIプラグインに合わせて決定しますが、ここでは[https://github.com/coreos/flannel flannel]を利用するので、{{ic|10.244.0.0/16}} とします。

==== マスター ====

まず、マシンの[[スワップ]]を無効にします。Kubernetesを稼働させる全てのノードにおいて、これは必須です。
{{bc|# swapoff -a}}

次に、コンテナランタイムを開始させます。{{Pkg|docker}}を利用する場合、{{ic|docker.service}}を開始します。
{{bc|# systemctl start docker.service}}

それから、以下のコマンドを実行:
{{bc|# kubeadm init --apiserver-advertise-address=192.168.122.1 --pod-network-cidr=10.244.0.0/16}}

{{ic|kubeadm}}によってPKI(公開鍵基盤)とクライアント証明書が自動的に作成され、{{ic|kubelet.service}}が開始されます。

問題なく起動が完了したら、以下のようなメッセージが表示されます:

Your Kubernetes master has initialized successfully!

新しく作成した kubernetes クラスタの管理者としてアカウントを設定します:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

それからポッドネットワークをデプロイします。[https://kubernetes.io/docs/concepts/cluster-administration/addons/ こちら] に様々な方法が載っています。全ての方法にはそれぞれデフォルトのポッドネットワーク CIDR が存在します。{{ic|--pod-network-cidr}} で指定した値にあわせて設定を修正してください。

ここではflannelをデプロイするので、以下のコマンドを実行:

$ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
$ kubectl apply -f kube-flannel.yml

最後に、マスターの状態を確認:
$ kubectl get componentstatus

==== ノード ====

マスターの成功メッセージの最後の行に入力してクラスタに参加:
kubeadm join --token <token> 192.168.122.1:6443 --discovery-token-ca-cert-hash sha256:<hash>

== トラブルシューティング ==

=== settings behind proxy ===

{{ic|kubeadm}} は {{ic|https_proxy}}, {{ic|http_proxy}}, {{ic|no_proxy}} [[環境変数]]を読み込みます。Kubernetes の内部ネットワークは最後の環境変数に記述します。例:
export no_proxy="192.168.122.0/24,10.96.0.0/12,192.168.123.0/24"
2番目の CIDR がデフォルトのサービスネットワーク CIDR です。

また、CNI プラグインが追加で必要です:
$ go get -d github.com/containernetworking/plugins
$ cd ~/go/src/github.com/containernetworking/plugins
$ bash ./build_linux.sh
# cp bin/* /opt/cni/bin/

=== fatal error: runtime: out of memory ===
ソースから kubernetes をビルドしたときに発生します。{{ic|zram}} 領域を設定することで回避できます:
# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithm
# echo 16G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

=== error when creating "xxx.yaml": No API token found for service account "default" ===
[https://stackoverflow.com/questions/31891734/not-able-to-create-pod-in-kubernetes stackoverflow] を見てください。

=== Error: unable to load server certificate ===
サービスの起動時に発生することがあります。{{ic|*.key}} ファイルのパーミッションの設定が正しいか確認してください。

Kubernetes

2020-03-29T13:32:16Z

Grainrigi:

[[Category:仮想化]]
[[en:Kubernetes]]
[https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ Kubernetes] はコンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するためのオープンソースシステムです。Kubernetes は k8s とも呼ばれます。

== Arch Linux の Kubernetes ==

=== Minikube ===

MiniKubeは[[VirtualBox]]などの仮想マシン上に小さなKubernetesクラスタを構築することが出来るプラットフォームです。
Kubernetesを試してみたいという場合、完全なインストールをいきなり用意するよりもMinikubeを利用するのが良いでしょう。

Arch LinuxでMinikubeを利用するには、{{Pkg|minikube}} パッケージおよび、{{Pkg|virtualbox}}などの仮想化環境をインストールします。

実際のminikubeの操作法については[https://kubernetes.io/ja/docs/setup/learning-environment/minikube/ 公式のチュートリアル]を参照してください。

=== 完全なインストール ===

Arch Linux で Kubernetes を使用するためには、{{AUR|kubelet-bin}}, {{AUR|kubeadm-bin}}, {{AUR|kubectl-bin}}をインストールします。
Kubernetesを実際に動作させるには、{{Pkg|docker}}や{{AUR|cri-o}}などのコンテナランタイムも予めインストールしておく必要が有ります。

さらに、AURパッケージの依存関係が不完全なため、{{Pkg|ebtables}}, {{Pkg|ethtool}}, {{Pkg|socat}}, {{Pkg|conntrack-tools}}が追加で必要です。

また、必要に応じて以下のパッケージをインストールします。

* {{AUR|cni-plugins-bin}}: [https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ CNI(Container Network Interface)プラグイン]を動作させるのに必要なバイナリパッケージ。標準のCNI(flannel等)を利用する場合、これは必須です。

== Arch Linux の Kubectl プラグイン ==

[https://kubernetes.io/docs/reference/kubectl/overview/ Kubectl] プラグインは独立したバイナリであり、サブコマンドを追加して Kubectl の機能を拡張します。

Arch Linux には Kubectl プラグインの AUR パッケージが存在します:

* {{AUR|kubectl-trace-git}}: kubectl を使って kubernetes クラスタの bpftrace プログラムをスケジュールします。

== 基本設定 ==

{{ic|kubeadm}} ヘルパーを使用するか手動で kubernetes クラスタを設定します。

=== kubeadm を使う ===

以下はマスターとスレーブがひとつずつの構成を取っており、両ノードとも {{ic|192.168.122.0/24}} ネットワーク内に存在し、マスターは kubernetes クラスタを {{ic|192.168.122.1}} でホストします。

また、ポッドに割り当てるIPアドレス範囲(CIDR)は利用するCNIプラグインに合わせて決定しますが、ここでは[https://github.com/coreos/flannel flannel]を利用するので、{{ic|10.244.0.0/16}} とします。

==== マスター ====

まず、マシンの[[スワップ]]を無効にします。Kubernetesを稼働させる全てのノードにおいて、これは必須です。
{{bc|# swapoff -a}}

次に、コンテナランタイムを開始させます。{{Pkg|docker}}を利用する場合、{{ic|docker.service}}を開始します。
{{bc|# systemctl start docker.service}}

それから、以下のコマンドを実行:
{{bc|# kubeadm init --apiserver-advertise-address=192.168.122.1 --pod-network-cidr=10.244.0.0/16}}

{{ic|kubeadm}}によってPKI(公開鍵基盤)とクライアント証明書が自動的に作成され、{{ic|kubelet.service}}が開始されます。

問題なく起動が完了したら、以下のようなメッセージが表示されます:

Your Kubernetes master has initialized successfully!

新しく作成した kubernetes クラスタの管理者としてアカウントを設定します:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

それからポッドネットワークをデプロイします。[https://kubernetes.io/docs/concepts/cluster-administration/addons/ こちら] に様々な方法が載っています。全ての方法にはそれぞれデフォルトのポッドネットワーク CIDR が存在します。{{ic|--pod-network-cidr}} で指定した値にあわせて設定を修正してください。

ここではflannelをデプロイするので、以下のコマンドを実行:

$ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
$ kubectl apply -f kube-flannel.yml

最後に、マスターの状態を確認:
$ kubectl get componentstatus

==== ノード ====

マスターの成功メッセージの最後の行に入力してクラスタに参加:
kubeadm join --token <token> 192.168.122.1:6443 --discovery-token-ca-cert-hash sha256:<hash>

== トラブルシューティング ==

=== settings behind proxy ===

{{ic|kubeadm}} は {{ic|https_proxy}}, {{ic|http_proxy}}, {{ic|no_proxy}} [[環境変数]]を読み込みます。Kubernetes の内部ネットワークは最後の環境変数に記述します。例:
export no_proxy="192.168.122.0/24,10.96.0.0/12,192.168.123.0/24"
2番目の CIDR がデフォルトのサービスネットワーク CIDR です。

また、CNI プラグインが追加で必要です:
$ go get -d github.com/containernetworking/plugins
$ cd ~/go/src/github.com/containernetworking/plugins
$ bash ./build_linux.sh
# cp bin/* /opt/cni/bin/

=== fatal error: runtime: out of memory ===
ソースから kubernetes をビルドしたときに発生します。{{ic|zram}} 領域を設定することで回避できます:
# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithm
# echo 16G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

=== error when creating "xxx.yaml": No API token found for service account "default" ===
[https://stackoverflow.com/questions/31891734/not-able-to-create-pod-in-kubernetes stackoverflow] を見てください。

=== Error: unable to load server certificate ===
サービスの起動時に発生することがあります。{{ic|*.key}} ファイルのパーミッションの設定が正しいか確認してください。

Kubernetes

2020-03-29T13:24:43Z

Grainrigi: Minikubeに関する記述を追加

[[Category:仮想化]]
[[en:Kubernetes]]
[https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ Kubernetes] はコンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するためのオープンソースシステムです。Kubernetes は k8s とも呼ばれます。

== Arch Linux の Kubernetes ==

=== Minikube ===

MiniKubeは[[VirtualBox]]などの仮想マシン上に小さなKubernetesクラスタを構築することが出来るプラットフォームです。
Kubernetesを試してみたいという場合、完全なインストールをいきなり用意するよりもMinikubeを利用するのが良いでしょう。

Arch LinuxでMinikubeを利用するには、{{Pkg|minikube}} パッケージおよび、{{Pkg|virtualbox}}などの仮想化環境をインストールします。

実際のminikubeの操作法については[https://kubernetes.io/ja/docs/setup/learning-environment/minikube/ 公式のチュートリアル]を参照してください。

=== 完全なインストール ===

Arch Linux で Kubernetes を使用するためには、{{AUR|kubelet-bin}}, {{AUR|kubeadm-bin}}, {{AUR|kubectl-bin}}をインストールします。
Kubernetesを実際に動作させるには、{{Pkg|docker}}や{{AUR|cri-o}}などのコンテナランタイムも予めインストールしておく必要が有ります。

さらに、AURパッケージの依存関係が不完全なため、{{Pkg|ebtables}}, {{Pkg|ethtool}}, {{Pkg|socat}}, {{Pkg|conntrack-tools}}が追加で必要です。

また、必要に応じて以下のパッケージをインストールします。

* {{AUR|cni-plugins-bin}}: [https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ CNI(Container Network Interface)プラグイン]を動作させるのに必要なバイナリパッケージ。標準のCNI(flannel等)を利用する場合、これは必須です。

== Arch Linux の Kubectl プラグイン ==

[https://kubernetes.io/docs/reference/kubectl/overview/ Kubectl] プラグインは独立したバイナリであり、サブコマンドを追加して Kubectl の機能を拡張します。

Arch Linux には Kubectl プラグインの AUR パッケージが存在します:

* {{AUR|kubectl-trace-git}}: kubectl を使って kubernetes クラスタの bpftrace プログラムをスケジュールします。

== 基本設定 ==

{{ic|kubeadm}} ヘルパーを使用するか手動で kubernetes クラスタを設定します。

=== kubeadm を使う ===

以下はマスターとスレーブがひとつずつの構成を取っており、両ノードとも {{ic|192.168.122.0/24}} ネットワーク内に存在し、マスターは kubernetes クラスタを {{ic|192.168.122.1}} でホストします。

また、ポッドに割り当てるIPアドレス範囲(CIDR)は利用するCNIプラグインに合わせて決定しますが、ここでは[https://github.com/coreos/flannel flannel]を利用するので、{{ic|10.244.0.0/16}} とします。

==== マスター ====

まず、マシンの[[スワップ]]を無効にします。Kubernetesを稼働させる全てのノードにおいて、これは必須です。
{{bc|# swapoff -a}}

次に、コンテナランタイムを開始させます。{{Pkg|docker}}を利用する場合、{{ic|docker.service}}を開始します。
{{bc|# systemctl start docker.service}}

それから、以下のコマンドを実行:
{{bc|# kubeadm init --advertise-address=192.168.122.1 --pod-network-cidr=10.244.0.0/16}}

{{ic|kubeadm}}によってPKI(公開鍵基盤)とクライアント証明書が自動的に作成され、{{ic|kubelet.service}}が開始されます。

問題なく起動が完了したら、以下のようなメッセージが表示されます:

Your Kubernetes master has initialized successfully!

新しく作成した kubernetes クラスタの管理者としてアカウントを設定します:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

それからポッドネットワークをデプロイします。[https://kubernetes.io/docs/concepts/cluster-administration/addons/ こちら] に様々な方法が載っています。全ての方法にはそれぞれデフォルトのポッドネットワーク CIDR が存在します。{{ic|--pod-network-cidr}} で指定した値にあわせて設定を修正してください。

ここではflannelをデプロイするので、以下のコマンドを実行:

$ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
$ kubectl apply -f kube-flannel.yml

最後に、マスターの状態を確認:
$ kubectl get componentstatus

==== ノード ====

マスターの成功メッセージの最後の行に入力してクラスタに参加:
kubeadm join --token <token> 192.168.122.1:6443 --discovery-token-ca-cert-hash sha256:<hash>

== トラブルシューティング ==

=== settings behind proxy ===

{{ic|kubeadm}} は {{ic|https_proxy}}, {{ic|http_proxy}}, {{ic|no_proxy}} [[環境変数]]を読み込みます。Kubernetes の内部ネットワークは最後の環境変数に記述します。例:
export no_proxy="192.168.122.0/24,10.96.0.0/12,192.168.123.0/24"
2番目の CIDR がデフォルトのサービスネットワーク CIDR です。

また、CNI プラグインが追加で必要です:
$ go get -d github.com/containernetworking/plugins
$ cd ~/go/src/github.com/containernetworking/plugins
$ bash ./build_linux.sh
# cp bin/* /opt/cni/bin/

=== fatal error: runtime: out of memory ===
ソースから kubernetes をビルドしたときに発生します。{{ic|zram}} 領域を設定することで回避できます:
# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithm
# echo 16G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

=== error when creating "xxx.yaml": No API token found for service account "default" ===
[https://stackoverflow.com/questions/31891734/not-able-to-create-pod-in-kubernetes stackoverflow] を見てください。

=== Error: unable to load server certificate ===
サービスの起動時に発生することがあります。{{ic|*.key}} ファイルのパーミッションの設定が正しいか確認してください。

Kubernetes

2020-03-29T12:55:21Z

Grainrigi: Kubernetesのパッケージを動作するものに置き換え, kubeadmのチュートリアルを最新版(v1.18.0)で動作するものに変更

[[Category:仮想化]]
[[en:Kubernetes]]
[https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ Kubernetes] はコンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するためのオープンソースシステムです。Kubernetes は k8s とも呼ばれます。

== Arch Linux の Kubernetes ==

Arch Linux で Kubernetes を使用するためには、{{AUR|kubelet-bin}}, {{AUR|kubeadm-bin}}, {{AUR|kubectl-bin}}をインストールします。
Kubernetesを実際に動作させるには、{{Pkg|docker}}や{{AUR|cri-o}}などのコンテナランタイムも予めインストールしておく必要が有ります。

さらに、AURパッケージの依存関係が不完全なため、{{Pkg|ebtables}}, {{Pkg|ethtool}}, {{Pkg|socat}}, {{Pkg|conntrack-tools}}が追加で必要です。

また、必要に応じて以下のパッケージをインストールします。

* {{AUR|cni-plugins-bin}}: [https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ CNI(Container Network Interface)プラグイン]を動作させるのに必要なバイナリパッケージ。標準のCNI(flannel等)を利用する場合、これは必須です。

== Arch Linux の Kubectl プラグイン ==

[https://kubernetes.io/docs/reference/kubectl/overview/ Kubectl] プラグインは独立したバイナリであり、サブコマンドを追加して Kubectl の機能を拡張します。

Arch Linux には Kubectl プラグインの AUR パッケージが存在します:

* {{AUR|kubectl-trace-git}}: kubectl を使って kubernetes クラスタの bpftrace プログラムをスケジュールします。

== 基本設定 ==

{{ic|kubeadm}} ヘルパーを使用するか手動で kubernetes クラスタを設定します。

=== kubeadm を使う ===

以下はマスターとスレーブがひとつずつの構成を取っており、両ノードとも {{ic|192.168.122.0/24}} ネットワーク内に存在し、マスターは kubernetes クラスタを {{ic|192.168.122.1}} でホストします。

また、ポッドに割り当てるIPアドレス範囲(CIDR)は利用するCNIプラグインに合わせて決定しますが、ここでは[https://github.com/coreos/flannel flannel]を利用するので、{{ic|10.244.0.0/16}} とします。

==== マスター ====

まず、マシンの[[スワップ]]を無効にします。Kubernetesを稼働させる全てのノードにおいて、これは必須です。
{{bc|# swapoff -a}}

次に、コンテナランタイムを開始させます。{{Pkg|docker}}を利用する場合、{{ic|docker.service}}を開始します。
{{bc|# systemctl start docker.service}}

それから、以下のコマンドを実行:
{{bc|# kubeadm init --advertise-address=192.168.122.1 --pod-network-cidr=10.244.0.0/16}}

{{ic|kubeadm}}によってPKI(公開鍵基盤)とクライアント証明書が自動的に作成され、{{ic|kubelet.service}}が開始されます。

問題なく起動が完了したら、以下のようなメッセージが表示されます:

Your Kubernetes master has initialized successfully!

新しく作成した kubernetes クラスタの管理者としてアカウントを設定します:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

それからポッドネットワークをデプロイします。[https://kubernetes.io/docs/concepts/cluster-administration/addons/ こちら] に様々な方法が載っています。全ての方法にはそれぞれデフォルトのポッドネットワーク CIDR が存在します。{{ic|--pod-network-cidr}} で指定した値にあわせて設定を修正してください。

ここではflannelをデプロイするので、以下のコマンドを実行:

$ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
$ kubectl apply -f kube-flannel.yml

最後に、マスターの状態を確認:
$ kubectl get componentstatus

==== ノード ====

マスターの成功メッセージの最後の行に入力してクラスタに参加:
kubeadm join --token <token> 192.168.122.1:6443 --discovery-token-ca-cert-hash sha256:<hash>

== トラブルシューティング ==

=== settings behind proxy ===

{{ic|kubeadm}} は {{ic|https_proxy}}, {{ic|http_proxy}}, {{ic|no_proxy}} [[環境変数]]を読み込みます。Kubernetes の内部ネットワークは最後の環境変数に記述します。例:
export no_proxy="192.168.122.0/24,10.96.0.0/12,192.168.123.0/24"
2番目の CIDR がデフォルトのサービスネットワーク CIDR です。

また、CNI プラグインが追加で必要です:
$ go get -d github.com/containernetworking/plugins
$ cd ~/go/src/github.com/containernetworking/plugins
$ bash ./build_linux.sh
# cp bin/* /opt/cni/bin/

=== fatal error: runtime: out of memory ===
ソースから kubernetes をビルドしたときに発生します。{{ic|zram}} 領域を設定することで回避できます:
# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithm
# echo 16G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

=== error when creating "xxx.yaml": No API token found for service account "default" ===
[https://stackoverflow.com/questions/31891734/not-able-to-create-pod-in-kubernetes stackoverflow] を見てください。

=== Error: unable to load server certificate ===
サービスの起動時に発生することがあります。{{ic|*.key}} ファイルのパーミッションの設定が正しいか確認してください。

Iptables

2018-09-19T13:07:59Z

Grainrigi: 「基本概念」においてイタリック体が片仮名に適用されなかったので英単語を追加した

{{Lowercase title}}
[[Category:ファイアウォール]]
[[de:Iptables]]
[[el:Iptables]]
[[en:Iptables]]
[[es:Iptables]]
[[fr:Iptables]]
[[it:Iptables]]
[[ru:Iptables]]
[[sr:Iptables]]
[[zh-hans:Iptables]]
{{Related articles start}}
{{Related|ファイアウォール}}
{{Related|シンプルなステートフルファイアウォール}}
{{Related|Sysctl#TCP/IP スタックの防御}}
{{Related|Sshguard}}
{{Related|Fail2ban}}
{{Related|Nftables}}
{{Related|ポートノッキング}}
{{Related articles end}}

Iptables は [[Wikipedia:ja:iptables|netfilter]] プロジェクトの一つとして Linux カーネルに組み込まれている強力な[[ファイアウォール]]です。直接、または様々な[[ファイアウォール#iptables|フロントエンド]]や [[ファイアウォール#グラフィカルフロントエンド|GUI]] を使って設定することができます。[[Wikipedia:ja:IPv4|IPv4]] では iptables が、[[IPv6]] では ip6tables が使用されます。

いつかメインの Linux ファイアウォールユーティリティとして iptables を置き換えるものとして、[https://www.phoronix.com/scan.php?page=news_item&px=MTQ5MDU Linux カーネル 3.13] で [[nftables]] がリリースされています。

== インストール ==

標準の Arch Linux カーネルは iptables サポートを有効にしてコンパイルされています。必要なのは、[[公式リポジトリ]]の {{Pkg|iptables}} に入ってるユーザーランドユーティリティを[[インストール]]することだけです ({{Grp|base}} グループの {{Pkg|iproute2}} パッケージが iptables に依存しているため、あなたのシステムにはデフォルトで iptables パッケージがインストールされています)。

== 基本概念 ==

iptables は IPv4 パケットを検査・変更・転送・リダイレクト・拒否するのに使われます。IPv4 パケットをフィルタリングするコードはカーネルに含まれており、特定の目的ごとに''テーブル(tables)''としてまとめられています。テーブルは定義済みの''チェイン(chains)''のセットで出来ており、チェインを通過するルールが順番に含まれています。各ルールはマッチと対応するアクション (''ターゲット(targets)''と呼ばれます) の条件文からなり、条件が真のときに (つまり条件がマッチしたとき) 実行されます。iptables はそれらのチェインやルールを使うためのユーザーユーティリティです。ほとんどの新規ユーザーは linux の IP ルーティングの複雑性をとても難しく感じますが、一般的なユースケース (NAT や基本的なインターネットファイアウォール) では実はあまり複雑ではありません。

iptables の動作を理解するための鍵は [http://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg このチャート] です。上部の小文字の単語がテーブルで下部の大文字の単語がチェインになります。''あらゆるネットワークインターフェース''から来た IP パケットは全てこのフローチャートの上から下まで通過します。よくある勘違いの元は、内部インターフェースからのパケットがインターネットに接するインターフェースからのパケットと違ったふうに処理されることにあります。全てのインターフェースは同じように処理されます。それを別々に扱うようにルールを定義するのはあなた次第です。もちろんローカルプロセスのためのパケットというものが存在し、チャートの一番上から <Local Process> のところで止まり、一方ローカルプロセスによって生成されたパケットは <Local Process> からスタートしてフローチャートを下っていきます。このフローチャートの働きの詳しい説明は [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES こちら] から読めます。

ほとんどの使い方では ''raw'', ''mangle'', ''security'' テーブルを使うことは全くありません。従って、''iptables'' をネットワークパケットが通る様子を表すと以下のチャートのようになります:

{{bc|<nowiki>
XXXXXXXXXXXXXXXXXX
XXX Network XXX
XXXXXXXXXXXXXXXXXX
+
|
v
+-------------+ +------------------+
|table: filter| <---+ | table: nat |
|chain: INPUT | | | chain: PREROUTING|
+-----+-------+ | +--------+---------+
| | |
v | v
[local process] | **************** +--------------+
| +---------+ Routing decision +------> |table: filter |
v **************** |chain: FORWARD|
**************** +------+-------+
Routing decision |
**************** |
| |
v **************** |
+-------------+ +------> Routing decision <---------------+
|table: nat | | ****************
|chain: OUTPUT| | +
+-----+-------+ | |
| | v
v | +-------------------+
+--------------+ | | table: nat |
|table: filter | +----+ | chain: POSTROUTING|
|chain: OUTPUT | +--------+----------+
+--------------+ |
v
XXXXXXXXXXXXXXXXXX
XXX Network XXX
XXXXXXXXXXXXXXXXXX
</nowiki>}}

=== テーブル ===

iptables には5つのテーブルがあります:

# {{ic|raw}} は接続追跡の対象から外れるようパケットを設定するのに使われます。
# {{ic|filter}} はデフォルトのテーブルで、主としてファイアウォールが備えるべきアクションは全てここで行われます。
# {{ic|nat}} は[[Wikipedia:ja:ネットワークアドレス変換|ネットワークアドレス変換]]に使われます (例: ポートフォワーディング)。
# {{ic|mangle}} は特別なパケット変換に使われます ([[Wikipedia:Mangled packet|Mangled packet]] を参照)。
# {{ic|security}} は[[セキュリティ#強制アクセス制御|強制アクセス制御]]のネットワークルールに使われます (例: SELinux -- 詳しくは [https://lwn.net/Articles/267140/ この記事] を参照)。

ほとんどの場合、使用するテーブルは2つだけです: ''filter'' と ''nat''。他のテーブルは複数のルーターやルーティングの判定が関わる複雑な設定のためにあり、どちらにしろ導入の域を超えています。

=== チェイン ===

テーブルは''チェイン''で構成されています。チェインは順番に並べられたルールのリストです。デフォルトのテーブル、{{ic|filter}} には3つの組み込みチェインが含まれます: {{ic|INPUT}}, {{ic|OUTPUT}}, {{ic|FORWARD}}。[http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg フローチャート] で示されているように、パケットのフィルタリングプロセスの別々の場所で使われます。nat テーブルには {{ic|PREROUTING}}, {{ic|POSTROUTING}}, {{ic|OUTPUT}} チェインが含まれます。

他のテーブルの組み込みチェインの説明は {{ic|man 8 iptables}} を見て下さい。

デフォルトでは、チェインにはルールが何も入っていません。使用したいチェインにルールを追加するのはあなたの手に委ねられています。チェインにはデフォルトのポリシーが''存在''し、基本的には {{ic|ACCEPT}} に設定されていますが、あなたのルールセットを何も通り抜けられないようにしたい場合は {{ic|DROP}} に設定しなおすことができます。デフォルトのポリシーは常にチェインの一番最後に適用されます。故に、パケットはデフォルトポリシーの適用の前にチェインに存在するルール全てを通過する必要があります。

ユーザー定義チェインを追加すればルールセットをより効率的に、または簡単に修正できるようにすることができます。ユーザー定義チェインをどうやって使うかの例は[[シンプルなステートフルファイアウォール]]を見て下さい。

=== ルール ===

パケットフィルタリングは複数の''マッチ'' (ルールが適用されるパケットの条件) と一つの''ターゲット'' (パケットが全ての条件に一致したときのアクション) によって記された、''ルール''に基づきます。ルールがマッチするものはパケットが入ってくるインターフェース (例: eth0 または eth1) や、パケットのタイプ (ICMP, TCP, UDP)、パケットの送信先ポートなどになります。

ターゲットは {{ic|-j}} または {{ic|--jump}} オプションを使って指定します。ターゲットはユーザー定義チェイン (条件に一致した場合、次のユーザー定義チェインにジャンプしてそこから処理が続行される)、特別な組み込みターゲットのどれか、またはターゲットの拡張のいずれかになります。組み込みターゲットは {{ic|ACCEPT}}, {{ic|DROP}}, {{ic|QUEUE}}, {{ic|RETURN}} で、ターゲットの拡張は {{ic|REJECT}} や {{ic|LOG}} などです。ターゲットが組み込みターゲットだった場合、パケットの運命はすぐに決まり、現在のテーブルのパケットの処理は停止します。ターゲットがユーザー定義チェインだった場合で、さらにこの2番目のチェインをパケットが通過した場合、元のチェインの次のルールに移ります。ターゲットの拡張は''終了'' (組み込みターゲットと同じ) と''非終了'' (ユーザー定義チェインと同じ) のいずれも可能です。詳しくは {{ic|man 8 iptables-extensions}} を見て下さい。

=== チェインの通過 ===

あらゆるインターフェースで受け取られたネットワークパケットは [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg フローチャート] で示されている順番でテーブルのトラフィック制御チェインを通過していきます。最初のルーティングの決定はパケットの最終目的地がローカルマシンなのか (その場合パケットは {{ic|INPUT}} チェインを通過します) もしくは他のところなのか (その場合パケットは {{ic|FORWARD}} チェインを通過します) 判断するところからです。次のルーティングの決定は送出パケットにどのインターフェースを割り当てるかの決定を伴います。この経路にあるチェインごとに、全てのルールが順番に評価され、ルールが一致すれば、対応するターゲット・ジャンプのアクションが実行されます。最も一般的に使われるターゲットのビッグスリーは {{ic|ACCEPT}} と {{ic|DROP}}、そしてユーザー定義チェインへのジャンプです。組み込みチェインにはデフォルトポリシーを設定できますが、ユーザー定義チェインではできません。ジャンプした先のチェインのルールがどれも完全一致しないときは、パケットは [http://www.frozentux.net/iptables-tutorial/images/table_subtraverse.jpg こちら] に描かれているように元のチェインに戻ります。{{ic|DROP}} ターゲットのルールで完全一致があった場合は即座にパケットは拒否され、先の処理は行われません。チェインの中でパケットが {{ic|ACCEPT}} されると、全ての上位のチェインでパケットが {{ic|ACCEPT}} され、上位チェインを通過しなくなります。ただし、他のテーブルのチェインは全て通常通りにパケットが通過するので注意してください。

=== モジュール ===

connlimit, conntrack, limit, recent など多数のモジュールを使うことで iptables を拡張することができます。これらのモジュールは新しい機能を追加して複雑なフィルタリングルールを可能にします。

== iptables の設定と実行 ==

iptables は [[systemd]] のサービスであり次のように起動できます:

# systemctl start iptables

ただし、このサービスは {{ic|/etc/iptables/iptables.rules}} ファイルがないと起動せず、Arch の {{Pkg|iptables}} パッケージにはデフォルトの iptables.rule ファイルは付いていません。したがって初めてサービスを起動する場合:

# touch /etc/iptables/iptables.rules
# systemctl start iptables

または:

# cp /etc/iptables/empty.rules /etc/iptables/iptables.rules
# systemctl start iptables

他のサービスと同じように、起動時に iptables が自動的にロードされるようにしたいときは、有効化してください:

# systemctl enable iptables

=== コマンドラインから ===

==== 現在のルールを表示する ====

次のコマンドを使うことで現在のルールセットとルールごとのヒット数を確認できます:

{{hc|# iptables -nvL|Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination}}

上のように出力された場合、ルールは存在しません。何もブロックされません。

ルールを表示する際に行番号を表示するには、{{ic|--line-numbers}} をコマンドに追加してください。個々のルールを削除したり追加するときに便利です。

==== ルールをリセットする ====

以下のコマンドを使えば iptables をデフォルトに戻すことができます:

# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -t raw -F
# iptables -t raw -X
# iptables -t security -F
# iptables -t security -X
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT

引数を付けない {{ic|-F}} コマンドは現在のテーブルの全てのチェインを削除します。同じく、{{ic|-X}} はテーブル内の空の (デフォルトでない) チェインを全て削除します。

{{ic|[chain]}} 引数を付けて {{ic|-F}} や {{ic|-X}} を使うことでチェインを個別に削除することもできます。

==== ルールを編集する ====

ルールの追加は、チェインにルールを付け足すか、またはチェインの特定の位置にルールを挿入することで行います。ここでは両方の方法を用います。

まず最初に、わたしたちのコンピュータはルーターではありません (もちろん、[[ルーター]]なのであれば話は別ですが)。{{ic|FORWARD}} チェインのデフォルトポリシーを {{ic|ACCEPT}} から {{ic|DROP}} に変更します:

{{bc|
# iptables -P FORWARD DROP
}}

{{warning|このセクションは iptables のルールに関する構文と構想を伝えるためにあります。サーバーのセキュリティを確保するための方法を記述しているわけではありません。システムのセキュリティを向上させる方法については、最小限セキュアな iptables の設定について書かれた[[シンプルなステートフルファイアウォール]]や、一般的な視点で Arch Linux のセキュリティを上げる方法を説明している[[セキュリティ]]のページを参照してください。}}

[[Dropbox]] の LAN 同期機能は認識された全てのコンピュータに[https://isc.sans.edu/port.html?port=17500 30秒毎にパケットを送信します]。Dropbox クライアントで LAN を使っていてこの機能を利用しない場合、このパケットは拒否すると良いでしょう:

{{bc|
# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
}}

{{hc|
# iptables -nvL --line-numbers
|
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

}}
{{note|ここでは {{ic|DROP}} ではなく {{ic|REJECT}} を使用していますが、これは [https://tools.ietf.org/html/rfc1122#page-69 RFC 1122 3.3.8] がパケットをドロップする代わりに出来る限り ICMP エラーを返すことをホストに要求しているためです。実際には、サーバーの存在を知るべきホストからのパケットは {{ic|REJECT}} して、サーバーの存在すら知るべきでない (もしくは何か良からぬことを企んでいる) ホストからのパケットは {{ic|DROP}} するのがベストです。}}

そして今度は、Dropbox に関する考えをあらためてコンピュータに Dropbox をインストールすることを決めたとします。LAN 同期も行いますが、ネットワーク上の特定の一つの IP しか使いません。そこで {{ic|-R}} を使って古いルールを置き換える必要があります。{{ic|10.0.0.85}} は別の IP です:

{{bc|
# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable
}}

{{hc|
# iptables -nvL --line-numbers
|
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
}}

オリジナルのルールをコンピュータのポート {{ic|17500}} に {{ic|10.0.0.85}} がアクセスできるようにルールを置き換えました。しかしながらここで、このルールは扱いづらいということに気づきました。フレンドリーな Dropbox ユーザーがデバイスのポート {{ic|17500}} にアクセスしようとしたときに、すぐにそのユーザーを許可したいわけで、その後のファイアウォールルールで彼をテストしたくないということです。

信頼されているユーザーはすぐ許可するように、新しいルールを書き込みます。{{ic|-I}} を使って古いルールの前に新しいルールを挿入:

{{bc|
# iptables -I INPUT -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"
}}

{{hc|
# iptables -nvL --line-numbers
|
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */
2 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
}}

そして2番目のルールを、ポート {{ic|17500}} で全てを拒否するルールに置き換えます:

# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable

最終的なルールは以下のようになりました:

{{hc|
# iptables -nvL --line-numbers
|
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */
2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
}}

=== 設定ファイル ===

Arch Linux のデフォルトでは、iptables のルールは {{ic|/etc/iptables/iptables.rules}} に保存されます。ただし、ルールは自動でロードされません。代わりに起動時にこのファイルを読み込んでルールをロードする {{ic|iptables.service}} を有効にすることができます:

# systemctl enable iptables
# systemctl start iptables

IPv6 の iptables ルールは、デフォルトで、{{ic|/etc/iptables/ip6tables.rules}} に保存され、このファイルは {{ic|ip6tables.service}} によって読み込まれます。このサービスを起動する方法は上と同じです。

{{Note|1=iptables 1.4.21-1 パッケージの {{ic|iptables.service}} と {{ic|ip6tables.service}} ファイルは古くなっています。systemd 214 からセキュリティ上の理由で、ネットワークが設定される前にファイアウォールが実行するように、ファイアウォールは {{ic|network-pre.target}} ターゲットの前に起動することが推奨されています。iptables がアップデートされるまで、ドロップインディレクトリ {{ic|/etc/systemd/system/iptables.service.d}} を作成して、その中に {{ic|00-pre-network.conf}} ファイルを使って以下のスニペットを記述して下さい:

[Unit]
Wants=network-pre.target
Before=network-pre.target

システムが {{ic|ip6tables.service}} を使っている場合、{{ic|/etc/systemd/system/ip6tables.service.d}} ドロップインディレクトリで同じことを行なって下さい。このことに関する詳細は [https://bugs.freedesktop.org/show_bug.cgi?id=79600 systemd のバグレポート], [https://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html systemd のリリースアナウンス], {{Bug|33478}} を参照。}}

コマンドラインでルールを追加した後、設定ファイルは自動では変更されません — 手動で保存する必要があります:

# iptables-save > /etc/iptables/iptables.rules

設定ファイルを手動で編集したら、リロードしてください:

# systemctl reload iptables

もしくは iptables を使って直接ロードすることもできます:

# iptables-restore < /etc/iptables/iptables.rules

=== ガイド ===

* [[シンプルなステートフルファイアウォール]]
* [[ルーター]]

== ログ ==

{{ic|LOG}} ターゲットを使うことでルールにヒットしたパケットを記録することができます。{{ic|ACCEPT}} や {{ic|DROP}} など他のターゲットとちがって、パケットは {{ic|LOG}} ターゲットにヒットした後もチェインを通過します。つまり拒否されたパケットを全て記録するためには、それぞれの DROP ルールの前に同じ {{ic|LOG}} ルールを追加する必要があります。これだと事態がややこしくなり効率的でなくなるので、代わりに {{ic|logdrop}} チェインを作成します。

チェインを作成:

# iptables -N logdrop

新しく作成したチェインに以下のルールを追加:

# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
# iptables -A logdrop -j DROP

{{ic|limit}} や {{ic|limit-burst}} オプションの説明は[[#ログ出力の上限を設定する|下のセクション]]にあります。

これで、パケットを拒否してイベントを記録したいときは、毎回 {{ic|logdrop}} チェインにジャンプするようにします。例えば:

# iptables -A INPUT -m conntrack --ctstate INVALID -j logdrop

=== ログ出力の上限を設定する ===

上記の {{ic|logdrop}} チェインは limit モジュールを使うことで ''iptables'' のログが大きくなりすぎたり不必要なハードドライブの書き込みが発生するのを防ぐことができます。上限を設定していないと、誤って設定したサービスが接続を試行したり、攻撃者によって、iptables のログへの書き込みでドライブ (少なくとも {{ic|/var}} パーティション) が埋まってしまう可能性があります。

limit モジュールは {{ic|-m limit}} で呼び出すことができます。そして {{ic|--limit}} を使うことで平均レートを、{{ic|--limit-burst}} を使うことで最初のバーストレートを設定することができます。上記の {{ic|logdrop}} のサンプルなら:

# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG

これで通過する全てのパケットを記録するルールが追加されます。最初の連続する10のパケットが記録され、それから1分ごとに5のパケットだけ記録されます。"limit burst" のカウントは log アクティビティがノーマルに自動的に戻って "limit rate" が壊れない度にリセットされます。

=== 記録されたパケットを表示する ===

記録されたパケットは [[systemd#Journal|systemd の journal]] でカーネルメッセージとして見ることができます。

マシンが最後に起動したときから記録されたパケットを全て表示するには:
# journalctl -k | grep "IN=.*OUT=.*" | less

=== syslog-ng ===

[[syslog-ng]] を使っている場合、iptables のログ出力先をコントロールすることができます:
filter f_everything { level(debug..emerg) and not facility(auth, authpriv); };
を
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables); };

これで iptables による {{ic|/var/log/everything.log}} へのログ出力が停止されます。

iptables に {{ic|/var/log/iptables.log}} 以外のファイルにログを出力して欲しい場合は、destination {{ic|d_iptables}} の file の値を変更するだけで可能です ({{ic|syslog-ng.conf}} にあります):
destination d_iptables { file("/var/log/iptables.log"); };

=== ulogd ===

[http://www.netfilter.org/projects/ulogd/index.html ulogd] は netfilter のための特別なユーザースペースパケットログデーモンで、デフォルトの {{ic|LOG}} ターゲットを置き換えることができます。{{Pkg|ulogd}} パッケージは {{ic|[community]}} リポジトリから入手可能です。

== 参照 ==
{{Wikipedia/ja|iptables}}
* [http://www.netfilter.org/projects/iptables/index.html iptables 公式ウェブサイト]
* [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html iptables Tutorial 1.2.2] by Oskar Andreasson
* [https://wiki.debian.org/iptables iptables Debian] Debian wiki