TLS/SSLおよびファイアウォールルールを使用してCoreOSクラスターを保護する方法
序章
共有データセンター内やパブリックインターネット全体など、制御外のネットワーク環境でCoreOSクラスターを実行することを計画している場合、etcd
が暗号化されていないHTTP要求を行うことによって通信することに気付いたかもしれません。 クラスター内の各ノードにIPTablesファイアウォールを構成することで、その動作のリスクを軽減することは可能ですが、完全なソリューションでは、暗号化されたトランスポート層を使用するのが理想的です。
幸い、etcd
はピアツーピアTLS/ SSL接続をサポートしているため、クラスターの各メンバーが認証され、すべての通信が暗号化されます。 このガイドでは、まず3つのメンバーで単純なクラスターをプロビジョニングし、次に各マシンでHTTPSエンドポイントと基本的なファイアウォールを構成します。
前提条件
このガイドは、このCoreOSシステムコンポーネントの概要およびこのガイドのDigitalOceanでのCoreOSクラスターのセットアップで説明されている概念に基づいています。
etcd
、fleetctl
、cloud-config
ファイルの基本と、検出URLの生成に精通している必要があります。
クラスタ内のマシンを作成してアクセスするには、DigitalOceanアカウントに関連付けられたSSH公開鍵が必要です。 DigitalOceanでのSSHキーの使用の詳細については、こちらを参照してください。
DigitalOcean APIを使用してCoreOSマシンを作成する場合は、書き込み権限を持つパーソナルアクセストークンを生成して使用する方法について、このチュートリアルを参照してください。 APIの使用はオプションですが、特に大規模なクラスターの構築が予想される場合は、長期的には時間を節約できる可能性があります。
新しい検出URLを生成する
ブラウザでhttps://discovery.etcd.io/new?size=3にアクセスし、表示されたURLをコピーして、Discovery.etcd.ioから新しい検出URLを取得します。 、またはローカルマシンの端末からcurl
を使用して:
curl -w "\n" "https://discovery.etcd.io/new?size=3"
返されたURLを保存します。 間もなくcloud-config
で使用します。
HTTPS構成を含むCloud-Configファイルを作成する
cloud-config
を書くことから始めましょう。 cloud-config
は、各サーバーを初期化するときにユーザーデータとして提供され、クラスターの重要な構成の詳細を定義します。 このファイルは長くなりますが、基本クラスターガイドのバージョンよりもはるかに複雑になることはありません。 fleet
にHTTPSエンドポイントを使用するように明示的に指示し、ファイアウォールに対してiptables-restore
というサービスを有効にし、etcd
とfleet
に指示する構成ファイルを書き出します。 SSL証明書を検索します。
ローカルマシンでターミナルを開き、ホームディレクトリにいることを確認し、nano
(またはお気に入りのテキストエディタ)を使用して~/cloud-config.yml
を作成して開きます。
cd ~ nano cloud-config.yml
以下を貼り付けてから、etcd2
セクションのhttps://discovery.etcd.io/token
を、前のセクションで要求した検出URLに変更します。
ファイアウォールを有効にしたくない場合は、iptables-restore
セクションを削除することもできます。
貼り付けるときはインデントに注意してください。 cloud-config
は、空白に敏感なYAMLで記述されています。 特定の行に関する情報については、ファイル内のコメントを参照してください。その後、いくつかの重要なセクションについて詳しく説明します。
〜/ cloud-config.yml
#cloud-config coreos: etcd2: # generate a new token for each unique cluster from https://discovery.etcd.io/new: discovery: https://discovery.etcd.io/token # multi-region deployments, multi-cloud deployments, and Droplets without # private networking need to use $public_ipv4: advertise-client-urls: https://$private_ipv4:2379,https://$private_ipv4:4001 initial-advertise-peer-urls: https://$private_ipv4:2380 # listen on the official ports 2379, 2380 and one legacy port 4001: listen-client-urls: https://0.0.0.0:2379,https://0.0.0.0:4001 listen-peer-urls: https://$private_ipv4:2380 fleet: # fleet defaults to plain HTTP - explicitly tell it to use HTTPS on port 4001: etcd_servers: https://$private_ipv4:4001 public-ip: $private_ipv4 # used for fleetctl ssh command units: - name: etcd2.service command: start - name: fleet.service command: start # enable and start iptables-restore - name: iptables-restore.service enable: true command: start write_files: # tell etcd2 and fleet where our certificates are going to live: - path: /run/systemd/system/etcd2.service.d/30-certificates.conf permissions: 0644 content: | [Service] # client environment variables Environment=ETCD_CA_FILE=/home/core/ca.pem Environment=ETCD_CERT_FILE=/home/core/coreos.pem Environment=ETCD_KEY_FILE=/home/core/coreos-key.pem # peer environment variables Environment=ETCD_PEER_CA_FILE=/home/core/ca.pem Environment=ETCD_PEER_CERT_FILE=/home/core/coreos.pem Environment=ETCD_PEER_KEY_FILE=/home/core/coreos-key.pem - path: /run/systemd/system/fleet.service.d/30-certificates.conf permissions: 0644 content: | [Service] # client auth certs Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem Environment=FLEET_ETCD_CERTFILE=/home/core/coreos.pem Environment=FLEET_ETCD_KEYFILE=/home/core/coreos-key.pem
オプションの手順として、cloud-config
を公式のCoreOSCloud Config Validator に貼り付け、 ValidateCloud-Configを押すことができます。
ファイルを保存して終了します。 nano
では、 Ctrl-X を使用して終了し、 y を使用してファイルの書き込みを確認し、Enterを使用してファイル名を確認します。保存する。
cloud-init.yml
のいくつかの特定のブロックを見てみましょう。 まず、fleet
の値は次のとおりです。
fleet: # fleet defaults to plain HTTP - explicitly tell it to use HTTPS: etcd_servers: https://$private_ipv4:4001 public-ip: $private_ipv4 # used for fleetctl ssh command
etcd_servers
がhttps
URLに設定されていることに注意してください。 プレーンHTTP操作の場合、この値を設定する必要はありません。 ただし、明示的な構成がないと、HTTPSは失敗します。 ($private_ipv4
は、CoreOS初期化プロセスによって理解される変数であり、変更する必要のある変数ではありません。)
次に、write_files
ブロックに移動します。 値は、ファイルシステムpath
、permissions
マスク、およびcontent
に分割されます。このマスクには、ファイルの目的の内容が含まれています。 ここでは、etcd2
およびfleet
サービスのsystemd
ユニットファイルが、生成するTLS/SSL証明書を指す環境変数を設定する必要があることを指定します。
write_files: # tell etcd2 and fleet where our certificates are going to live: - path: /run/systemd/system/etcd2.service.d/30-certificates.conf permissions: 0644 content: | [Service] # client environment variables Environment=ETCD_CA_FILE=/home/core/ca.pem ... - path: /run/systemd/system/fleet.service.d/30-certificates.conf permissions: 0644 content: | [Service] # client auth certs Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem ...
証明書ファイルの場所をサービスに通知しますが、ファイル自体を提供することはまだできません。 そのためには、各CoreOSマシンのプライベートIPアドレスを知る必要があります。これは、マシンが作成された後にのみ使用可能になります。
注: CoreOSドロップレットでは、ドロップレットの作成後にcloud-config
の内容を変更することはできず、ファイルは起動のたびに再実行されます。 クラスターの構築後に変更する予定の構成には、write-files
セクションを使用しないでください。これは、次にドロップレットが起動したときにリセットされるためです。
ドロップレットをプロビジョニングする
cloud-config.yml
が定義されたので、これを使用してクラスターの各メンバーをプロビジョニングします。 DigitalOceanでは、2つの基本的なアプローチをとることができます。Webベースのコントロールパネルを使用する方法と、コマンドラインからcURLを使用してDigitalOceanAPIを呼び出す方法です。
DigitalOceanコントロールパネルの使用
同じデータセンターリージョン内に3つの新しいCoreOSドロップレットを作成します。 毎回プライベートネットワークとユーザーデータを有効にするを確認してください。
- coreos-1
- coreos-2
- coreos-3
ユーザーデータフィールドに、上からcloud-config.yml
の内容を貼り付け、ファイルの上部にあるdiscovery
フィールドに検出URLを挿入したことを確認します。
DigitalOceanAPIの使用
フィールドへの繰り返しの貼り付けを節約できる代替アプローチとして、curl
を使用してcloud-config
を使用してDigitalOceanAPIから新しいドロップレットをリクエストする短いBashスクリプトを記述し、各液滴。 nano
(または選択したテキストエディタ)を使用して、makecoreos.sh
という新しいファイルを開きます。
cd ~ nano makecoreos.sh
次のスクリプトを貼り付けて保存し、クラスターに必要なregion
およびsize
フィールドを調整します(デフォルトのnyc3
および512mb
はデモンストレーションに適しています目的ですが、実際のプロジェクトでは別の地域またはより大きなドロップレットが必要になる場合があります):
〜/ makecoreos.sh
#!/usr/bin/env bash # A basic Droplet create request. curl -X POST "https://api.digitalocean.com/v2/droplets" \ -d'{"name":"'"$1"'","region":"nyc3","size":"512mb","private_networking":true,"image":"coreos-stable","user_data": "'"$(cat ~/cloud-config.yml)"'", "ssh_keys":[ "'$DO_SSH_KEY_FINGERPRINT'" ]}' \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json"
次に、環境変数$DO_SSH_KEY_FINGERPRINT
と$TOKEN
を、それぞれDigitalOceanアカウントとAPIパーソナルアクセストークンに関連付けられたSSHキーのフィンガープリントに設定しましょう。
パーソナルアクセストークンの取得とAPIの使用については、このチュートリアルを参照してください。
アカウントに関連付けられているキーのフィンガープリントを見つけるには、SSHキーの下にあるアカウント設定のセキュリティセクションを確認してください。 これは、公開鍵指紋の形式になり、43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
のようなものになります。
ここではexport
を使用して、makecoreos.sh
などのシェルの子プロセスが変数にアクセスできるようにします。 スクリプトを使用するときは常に、両方を現在のシェルに設定する必要があります。そうしないと、API呼び出しが失敗します。
export DO_SSH_KEY_FINGERPRINT="ssh_key_fingerprint" export TOKEN="your_personal_access_token"
注: APIのパーソナルアクセストークンを生成したばかりの場合は、手元に置いて安全に保管することを忘れないでください。 最初の作成時に表示された後でそれを取得する方法はありません。トークンを持っている人は誰でも、DigitalOceanアカウントを制御できます。
必要なクレデンシャルごとに環境変数を設定したら、スクリプトを実行して目的の各ドロップレットを作成できます。 makecoreos.sh
は、最初のパラメーターを使用して、APIの呼び出しでname
フィールドに入力します。
bash makecoreos.sh coreos-1 bash makecoreos.sh coreos-2 bash makecoreos.sh coreos-3
新しい各ドロップレットを説明するJSON出力が表示され、3つすべてがコントロールパネルのドロップレットのリストに表示されます。 起動が完了するまでに数秒かかる場合があります。
coreos-1にログインします
コントロールパネルとAPIのどちらを使用した場合でも、3つのドロップレットが実行されているはずです。 ここで、パブリックIPとプライベートIPをメモしてください。これらは、コントロールパネルの個々のドロップレットをクリックしてから、設定リンクをクリックすることで利用できます。 証明書を生成してファイアウォールを構成するときに、各ドロップレットのプライベートIPアドレスが必要になります。
ドロップレットをテストしてみましょう。 SSHキーがローカルSSHエージェントに追加されていることを確認してください。
eval $(ssh-agent) ssh-add
DigitalOceanコントロールパネルでcoreos-1のパブリックIPアドレスを見つけ、SSHエージェント転送をオンにして接続します。
ssh -A core@coreos-1_public_ip
クラスタのいずれかのメンバーに最初にログインすると、systemd
からエラーメッセージが表示される可能性があります。
OutputCoreOS stable (766.5.0) Failed Units: 1 iptables-restore.service
これは、ファイアウォールがまだ構成されていないことを示しています。 今のところ、このメッセージは無視しても問題ありません。 (cloud-config
でファイアウォールを有効にしないことを選択した場合、エラーメッセージは表示されません。 iptables-restore
サービスは後でいつでも有効にできます。)
ファイアウォールについて心配する前に、クラスターの各メンバーのetcd2
インスタンスが相互に通信できるようにしましょう。
CFSSLを使用して自己署名証明書を生成する
CFSSL は、CloudFlareによって公開されているTLS/SSL証明書を操作するためのツールキットです。 この記事の執筆時点では、OpenSSLや現在は廃止されているetcd-ca
よりも、自己署名証明書を生成するためにCoreOSメンテナーが選択したツールです。
ローカルマシンにCFSSLをインストールする
CFSSLをソースからインストールするには、Goのインストールが機能している必要があります。 Goをインストールするためのこのガイドを参照してください。
$GOPATH
が正しく設定され、$PATH
に追加されていることを確認してから、go get
を使用してcfssl
コマンドをインストールします。
export GOPATH=~/gocode export PATH=$PATH:$GOPATH/bin go get -u github.com/cloudflare/cfssl/cmd/cfssl go get -u github.com/cloudflare/cfssl/...
別のアプローチとして、事前に作成されたバイナリをpkg.cfssl.orgから取得できます。 まず、~/bin
が存在し、パス内にあることを確認します。
mkdir -p ~/bin export PATH=$PATH:~/bin
次に、curl
を使用して、プラットフォームのcfssl
およびcfssljson
の最新バージョンを取得します。
curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/R1.1/cfssl_linux-amd64 curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/R1.1/cfssljson_linux-amd64
cfssl
バイナリが実行可能であることを確認してください。
chmod +x ~/bin/cfssl chmod +x ~/bin/cfssljson
認証局を生成する
cfssl
コマンドがインストールされたので、それらを使用して、各CoreOSマシンの証明書に署名するために使用するカスタム認証局を生成できます。 これらのファイルを次の場所に格納するための新しいディレクトリを作成して入力することから始めましょう。
mkdir ~/coreos_certs cd ~/coreos_certs
次に、nano
(またはお気に入りのテキストエディタ)でca-config.json
を作成して開きます。
nano ca-config.json
cfssl
が署名を行う方法を構成する以下を貼り付けて保存します。
〜/ coreos_certs / ca-config.json
{ "signing": { "default": { "expiry": "43800h" }, "profiles": { "client-server": { "expiry": "43800h", "usages": [ "signing", "key encipherment", "server auth", "client auth" ] } } } }
ここで注目すべきは、現在43800時間(または5年)に設定されているexpiry
と、server auth
とclient auth
の両方の使用法を含むclient-server
プロファイルです。 。 ピアツーピアTLSには、これらの両方が必要です。
次に、ca-csr.json
を作成して開きます。
nano ca-csr.json
以下を貼り付けて、場所と組織に合わせてCN
とnames
アレイを調整します。 hosts
エントリ、場所、組織名には架空の値を使用しても安全です。
〜/ coreos_certs / ca-csr.json
{ "CN": "My Fake CA", "hosts": [ "example.net", "www.example.net" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "US", "L": "CO", "O": "My Company", "ST": "Lyons", "OU": "Some Org Unit" } ] }
これらをca-config.json
およびca-csr.json
のデフォルト値と比較する場合は、cfssl
を使用してデフォルトを印刷できます。 ca-config.json
には、次を使用します。
cfssl print-defaults config
ca-csr.json
には、次を使用します。
cfssl print-defaults csr
ca-csr.json
とca-config.json
を配置して、認証局を生成します。
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
CoreOSマシンの証明書を生成して署名する
認証局ができたので、CoreOSマシンのデフォルトを記述できます。
coreos-1.json
を作成して開きます:
nano coreos-1.json
以下を貼り付けて保存し、 coreos-1 のプライベートIPアドレスに合わせて調整します(個々のドロップレットをクリックすると、DigitalOceanコントロールパネルに表示されます)。
〜/ coreos_certs / coreos-1.json
{ "CN": "coreos-1", "hosts": [ "coreos-1", "coreos-1.local", "127.0.0.1", "coreos-1_private_ip" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "US", "L": "Lyons", "ST": "Colorado" } ] }
最も重要な部分は、ホスト名であるCN
と、次のすべてを含む必要があるhosts
アレイです。
- ローカルホスト名
127.0.0.1
- CoreOSマシンのプライベートIPアドレス(公開IPではない)
これらは、subjectAltNamesとして結果の証明書に追加されます。 etcd
接続(127.0.0.1
のローカルループバックデバイスへの接続を含む)では、証明書に接続ホスト名と一致するSANが必要です。
必要に応じて、names
配列を変更して現在地を反映することもできます。 繰り返しになりますが、地名には架空の値を使用しても安全です。
残りのマシンごとにこのプロセスを繰り返し、適切なhosts
エントリを使用して一致するcoreos-2.json
およびcoreos-3.json
を作成します。
注: coreos-1.json
のデフォルト値を確認したい場合は、cfssl
を使用できます。
cfssl print-defaults csr
次に、CoreOSマシンごとに、署名付き証明書を生成し、正しいマシンにアップロードします。
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-1.json | cfssljson -bare coreos chmod 0644 coreos-key.pem scp ca.pem coreos-key.pem coreos.pem core@coreos-1_public_ip:
これにより、3つのファイル(ca.pem
、coreos-key.pem
、およびcoreos.pem
)が作成され、キーファイルのアクセス許可が正しいことを確認し、scp
を介して[ coreos-1上のX149X]coreのホームディレクトリ。
コマンドを呼び出すたびに前の証明書ファイルのセットが上書きされることに注意して、残りのマシンごとにこのプロセスを繰り返します。
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-2.json | cfssljson -bare coreos chmod 0644 coreos-key.pem scp ca.pem coreos-key.pem coreos.pem core@coreos-2_public_ip:
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-3.json | cfssljson -bare coreos chmod 0644 coreos-key.pem scp ca.pem coreos-key.pem coreos.pem core@coreos-3_public_ip:
coreos-1のetcd2機能を確認してください
証明書があれば、coreos-1でfleetctl
を実行できるはずです。 まず、SSH経由でログインします。
ssh -A core@coreos-1_public_ip
次に、クラスター内のすべてのマシンを一覧表示してみてください。
fleetctl list-machines
プライベートIPアドレスとともにリストされた各マシンの識別子が表示されます。
OutputMACHINE IP METADATA 7cb57440... 10.132.130.187 - d91381d4... 10.132.87.87 - eeb8726f... 10.132.32.222 -
fleetctl
が無期限にハングする場合は、クラスターを再起動する必要がある場合があります。 ローカルマシンに戻ります。
exit
SSHを使用して、reboot
コマンドを各CoreOSマシンに送信します。
ssh core@coreos-1_public_ip 'sudo reboot' ssh core@coreos-2_public_ip 'sudo reboot' ssh core@coreos-3_public_ip 'sudo reboot'
しばらく待ってから、 coreos-1 に再接続して、fleetctl
を再試行してください。
クラスターメンバーにIPTablesファイアウォールを構成する
証明書が設定されていると、ローカルネットワーク上の他のマシンがクラスターを制御したり、etcd2
から値を抽出したりすることは不可能になります。 それでも、可能であれば、利用可能な攻撃対象領域を減らすことをお勧めします。 ネットワークの露出を制限するために、各マシンにいくつかの単純なファイアウォールルールを追加して、クラスター内のピア以外のソースからのほとんどのローカルネットワークトラフィックをブロックできます。
cloud-config
でiptables-restore
サービスを有効にした場合、CoreOSマシンに最初にログインしたときにsystemd
エラーメッセージが表示されることに注意してください。
OutputCoreOS stable (766.5.0) Failed Units: 1 iptables-restore.service
これにより、サービスは有効になっているのに、iptables-restore
が正しくロードされなかったことがわかります。 systemctl
を使用してこれを診断できます。
systemctl status -l iptables-restore
Output● iptables-restore.service - Restore iptables firewall rules Loaded: loaded (/usr/lib64/systemd/system/iptables-restore.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2015-11-25 00:01:24 UTC; 27min ago Process: 689 ExecStart=/sbin/iptables-restore /var/lib/iptables/rules-save (code=exited, status=1/FAILURE) Main PID: 689 (code=exited, status=1/FAILURE) Nov 25 00:01:24 coreos-2 systemd[1]: Starting Restore iptables firewall rules... Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Main process exited, code=exited, status=1/FAILURE Nov 25 00:01:24 coreos-2 systemd[1]: Failed to start Restore iptables firewall rules. Nov 25 00:01:24 coreos-2 iptables-restore[689]: Can't open /var/lib/iptables/rules-save: No such file or directory Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Unit entered failed state. Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Failed with result 'exit-code'.
ここには多くの情報がありますが、最も有用な行はiptables-restore[689]
を含む行です。これは、プロセスIDとともに実行しようとしたプロセスsystemd
の名前です。 これは、失敗したサービスの実際のエラー出力をよく見つける場所です。
cloud-config
でiptables-restore
を有効にしましたが、目的のルールを含むファイルがまだ提供されていないため、ファイアウォールを復元できませんでした。 ドロップレットを作成する前にこれを行うこともできますが、ドロップレットを作成する前に、どのIPアドレスがドロップレットに割り当てられるかを知る方法がありません。 各プライベートIPがわかったので、ルールセットを作成できます。
エディターで新しいファイルを開き、以下を貼り付けて、coreos-1_private_ip
、coreos-2_private_ip
、およびcoreos-3_private_ip
を各CoreOSマシンのプライベートIPアドレスに置き換えます。 Accept all TCP/IP traffic...
の下のセクションを調整して、クラスターから提供する予定の公共サービスを反映する必要がある場合もありますが、このバージョンはデモンストレーション目的でうまく機能するはずです。
/ var / lib / iptables/rules-保存
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Accept all loopback (local) traffic: -A INPUT -i lo -j ACCEPT # Accept all traffic on the local network from other members of # our CoreOS cluster: -A INPUT -i eth1 -p tcp -s coreos-1_private_ip -j ACCEPT -A INPUT -i eth1 -p tcp -s coreos-2_private_ip -j ACCEPT -A INPUT -i eth1 -p tcp -s coreos-3_private_ip -j ACCEPT # Keep existing connections (like our SSH session) alive: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Accept all TCP/IP traffic to SSH, HTTP, and HTTPS ports - this should # be customized for your application: -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT # Accept pings: -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT COMMIT
上記をクリップボードにコピーし、 coreos-1 にログインし、CoreOSのデフォルトのテキストエディターであるVimを使用してrules-save
を開きます。
ssh -A core@coreos-1_public_ip
sudo vim /var/lib/iptables/rules-save
エディター内に入ると、:set paste
と入力し、 Enter を押して自動インデントがオフになっていることを確認してから、 i を押して挿入モードに入り、ファイアウォールルールを貼り付けます。 Esc を押して挿入モードを終了し、:wqを押してファイルを書き込んで終了します。
警告:ファイルの最後の行に末尾の改行があることを確認してください。そうしないと、ファイル内のすべてのコマンドが正しいように見えても、IPTablesが混乱する構文エラーで失敗する可能性があります。
最後に、ファイルに適切な権限(ユーザーの場合は読み取りと書き込み、グループとワールドの場合は読み取り専用)があることを確認してください。
sudo chmod 0644 /var/lib/iptables/rules-save
これで、サービスを再試行する準備ができました。
sudo systemctl start iptables-restore
成功すると、systemctl
はサイレントに終了します。 ファイアウォールのステータスは2つの方法で確認できます。 まず、systemctl status
を使用して:
sudo systemctl status -l iptables-restore
次に、現在のiptables
ルール自体を一覧表示します。
sudo iptables -v -L
-v
オプションを使用して詳細な出力を取得します。これにより、特定のルールがどのインターフェイスに適用されるかがわかります。
coreos-1 のファイアウォールが構成されていることを確認したら、ログアウトします。
exit
次に、このプロセスを繰り返して、/var/lib/iptables/rules-save
をcoreos-2およびcoreos-3にインストールします。
結論
このガイドでは、3つのメンバーで基本的なCoreOSクラスターを定義し、それぞれに認証とトランスポートセキュリティ用のTLS / SSL証明書を提供し、ファイアウォールを使用してローカルデータセンターネットワーク上の他のドロップレットからの接続をブロックしました。 これは、共有ネットワークでのCoreOSの使用に伴う基本的なセキュリティ上の懸念の多くを軽減するのに役立ちます。
ここから、CoreOS の使用を開始する際に、このシリーズの残りの部分の手法を適用して、サービスを定義および管理できます。