以下の IPv6 の確認手順は、Pingress を実行する Linux サーバーが対象です。
Pingress がゲートウェイのアドレスを記録するのはなぜですか？
IPv4 のみの docker_gwbridge は IPv6 接続を変換することがあり、ホストが IPv6 に対応していても、元のクライアントアドレスが失われます。前段に CDN や別のプロキシがある場合も、直接の接続元が変わります。Pingress はその接続元のアドレスを記録し、X-Real-IP と X-Forwarded-For に設定します。
インストーラーは IPv6 を自動で有効にしますか？
新規インストール時や参加時に、スクリプトはホストの IPv6 を検出し、デュアルスタックのゲートウェイの準備を試みます。選択を求められた場合は、1 で IPv4 のみで続行し、2 で終了して問題を解決します。既定は終了で、対話端末がない場合も同様です。
--no-ipv6 はゲートウェイの準備をスキップします。既存のデュアルスタックのゲートウェイで IPv6 を無効にするものではありません。macOS のネットワークは Docker の実行環境が管理します。
正常に動作しているか確認するには？
Pingress を実行するサーバーで、次を実行します。
ip -6 address show scope global
ip -6 route show default
docker network inspect docker_gwbridge --format '{{.EnableIPv6}}'最後のコマンドは true を返す必要があります。ただし、これは設定の確認であり、接続できることを示すものではありません。外部に公開する場合は、ドメインの AAAA レコードを、IPv6 経由で Pingress にアクセスできるアドレスに向けてください。
IPv6 に対応した別のマシンから、両方のプロトコルをテストします。例のドメインは実際のドメインに置き換えてください。
curl -4 --noproxy '*' -I https://app.example.com
curl -6 --noproxy '*' -I https://app.example.comPingress の client_ip、またはアプリケーションが受け取る転送ヘッダーが、接続元のクライアントアドレスと一致するか確認します。アプリケーションのソケットの接続相手は Pingress であり、元のクライアントではありません。
インストール後に IPv6 を有効にするには？
まず、ホストで IPv6 が使えるようにします。ゲートウェイがすでに true を返す場合は、接続と DNS を確認してください。まだ参加していないサーバーでは、インストールコマンドまたはサーバー一覧で取得した参加コマンドを、--no-ipv6 を付けずに実行します。
既存のインストールを再実行しても、ゲートウェイは更新されません。 稼働中のサーバーでゲートウェイが IPv4 のみの場合は、メンテナンスが必要です。
- ローカルデータをバックアップし、ノード ID、ロール、すべてのノードラベル、ゲートウェイの設定、そのノードに固定されたアプリケーション、Pingress、Insight を記録します。
- ワークロードを停止または移動します。マネージャーノードを離脱させる前に、過半数のマネージャーが正常に稼働し、別のノードで CDelivery のダッシュボードが使えることを確認してから、対象ノードを降格します。唯一のマネージャーをそのまま離脱させてはいけません。先に安全な引き継ぎ、またはバックアップと復旧の計画を用意してください。操作の詳細は Docker のノードメンテナンス手順を参照してください。
- ノードが離脱し、ゲートウェイを参照するコンテナがなくなったら、稼働中のダッシュボードから元のロールでの新しい参加コマンドを取得します。
--no-ipv6を付けずに実行すると、参加前にスクリプトが既定のゲートウェイを準備します。独自に設定したゲートウェイでは、元のサブネットとオプションを保持して、別途デュアルスタックのゲートウェイを準備してください。招待の有効期限は 30 分で、CDelivery が再起動または移動した場合も無効になります。 - 再参加すると新しいノード ID が作成されます。ボリュームの説明を含むすべてのラベルを復元し、古い ID に固定されたサービスの設定を修正します。ローカルボリュームを使うアプリケーションやローカルストレージを使う Insight は、画面でノードを切り替えるだけでは移せません。管理者による配置制約の修正が必要です。データは元のホストに残ります。
- サービスを復旧し、必要に応じて DNS を更新して、上記の IPv4、IPv6 接続とクライアントアドレスを再確認します。
別の方法として、IPv6 に対応したサーバーを追加し、そこで Pingress を実行して、DNS をそのサーバーに向けることもできます。
IPv6 のルーティングやファイアウォールに問題がある場合は？
転送を有効にすると、accept_ra=1 のインターフェースがルーター広告（RA）を受信しなくなり、デフォルトルートが失われることがあります。インターフェースを管理するネットワークマネージャーで、RA の設定を永続化してください。ifupdown では accept_ra 2、ifupdown-ng では ipv6-accept-ra 2 を使います。ネットワークマネージャー自身が RA を処理するインターフェースでは、accept_ra=0 を安易に上書きしないでください。インターフェースやホストの再起動後に、ルートを再確認します。
Docker の IPv6 ファイアウォール管理を有効に保ち（ip6tables を false にしないでください）、ホストとクラウドのファイアウォールで Pingress の HTTP/HTTPS ポートを許可します。ゲートウェイが true を返すだけでは、これらのルールや外部からの接続が正常であるとは確認できません。
その他のアクセス障害
DNS やルーティングの問題はドメインとルーティングに沿って確認してください。証明書の欠落、有効期限切れ、発行失敗は自動証明書と更新を参照します。アクセスログで、リクエストが入口に到達したか、アプリケーションに一致したか、上流から応答があったかを確認できます。