メインコンテンツまでスキップ

CloudEdge プロトコル透過性の受け入れ検証

CloudEdge プロトコル透過性プローブの FTP、NFS、バルク転送、PMTU、ソース IP 保持、no-NAT エビデンスの流れ

CloudEdge mobility が、NAT、ヘルパー ALG、動的ポート、MTU/PMTU の振る舞いに敏感なコネクション指向プロトコルに対して透過的であることを検証するための、クラウドを使わないハーネス計画です。実際のライブランはラボ運用者が後日実施します。このドキュメントと scripts/ 配下のスクリプトは、契約とエビデンスの形式を準備するだけです。

目標​

論理共有サブネット（デモでは 10.77.60.0/24）上のトラフィックについて、以下を証明します:

  • NAT なし: サーバーがクライアントサイトの mobility /32 をピアアドレスとして認識する。
  • クライアントのデフォルトゲートウェイがローカルサイトから変更されていない。
  • FTP アクティブモードとパッシブモードの両方で、NAT ALG なしにデータ転送が完了する。
  • rpcbind 経由の RPC エンドポイント探索と、NFSv3 のマウント/読み書きがサイト間で動作する。
  • 大容量転送が PMTU ブラックホールなしに完了する。
  • MSS/PMTU エビデンスがオーバーレイ MTU、ルート MTU/advmss（利用可能な場合）、設定済み MSS clamp 値を記録する。

最小限のライブマトリクス​

通常の D3 方向付きマトリクスがすでにグリーンになった後で、プロトコルプローブを実行します。代表的な 2 ペアを使用します:

ペア理由
aws -> azure両端でクラウドプロバイダートラッピングを行うクラウド間オーバーレイパス
aws -> onpremon-prem 側で proxy-ARP/VRRP 権限を持つクラウド-on-prem 間パス

シナリオカタログでは、これを examples/cloudedge-acceptance-scenarios.json の d11-protocol-transparency としてエンコードしています。

パリティ検証を拡大する場合は azure -> oci、oci -> aws、逆方向などを追加できますが、最小限の受け入れ検証は 1 回の 4 サイトラボウィンドウ内で実行できる規模に収めるべきです。

ハーネス​

ラッパーは以下の通りです:

PROTOCOL_PROBE_RUNNER=scripts/runners/cloudedge-protocol-runner.sh \
  scripts/cloudedge-protocol-probe.sh \
    --pairs aws:azure,aws:onprem \
    --bytes 104857600 \
    --out evidence/protocol-probe.json

完全な受け入れシナリオは同じラッパーを以下のように使用します:

PROTOCOL_PROBE_RUNNER=scripts/runners/cloudedge-protocol-runner.sh \
MATRIX_RUNNER=scripts/runners/cloudedge-matrix-runner.sh \
scripts/cloudedge-acceptance.sh run \
  --scenario d11-protocol-transparency \
  --out evidence/d11-protocol \
  --commit <routerd-commit>

出力は scripts/cloudedge-protocol-result-schema.json で検証され、result.json の protocols オブジェクト配下に取り込まれます。

ランナーコントラクト​

scripts/runners/cloudedge-protocol-runner.sh は PROTOCOL_PROBE_RUNNER を実装します。意図的に環境変数でパラメーター化されており、プロバイダーアカウント ID、リソース ID、秘密情報は含まれていません。

サイトごとに必要な設定:

export CE_AWS_CLIENT_SSH_HOST=<ssh-host-or-user@host>
export AWS_CLIENT_IP=10.77.60.11
export CE_AZURE_CLIENT_SSH_HOST=<ssh-host-or-user@host>
export AZURE_CLIENT_IP=10.77.60.12
export CE_ONPREM_CLIENT_SSH_HOST=<ssh-host-or-user@host>
export ONPREM_CLIENT_IP=10.77.60.10
export SSH_KEY_FILE=<private-key>
export SSH_USER=ubuntu
export CLIENT_SSH_USER=ubuntu

プロトコル関連の変数:

export CE_PROTOCOL_INSTALL=1
export CE_PROTOCOL_CONFIGURE_SERVICES=1
export CE_PROTOCOL_FTP_PASSIVE_PORTS=40000:40100
export CE_PROTOCOL_BULK_BYTES=104857600
export CE_PROTOCOL_PMTU_SIZE=1300
export CE_PROTOCOL_OVERLAY_IFACE=wg-hybrid
export CE_PROTOCOL_MSS_CLAMP=1340

各オペレーションはランナーを編集せずにオーバーライドできます:

export CE_PROTOCOL_FTP_ACTIVE_COMMAND='...'
export CE_PROTOCOL_NFS_COMMAND='...'

ラッパーはペアごとに以下のオペレーションを呼び出します:

オペレーションアサーション
setup有効時に vsftpd、rpcbind、NFS サーバー/クライアントツール、iperf3 をインストール/設定
ftp-activeFTP PORT モードデータチャネルが完了
ftp-passiveFTP パッシブモードデータチャネルが完了
nfsNFSv3 マウント + 要求バイト量の書き込み/読み取りが完了
rpcrpcinfo -p が rpcbind と少なくとも 1 つの動的 RPC/NFS ポートを検出
bulkiperf3 -n <bytes> が完了し、スループット/再送を記録
pmtuDF ping が成功し、オーバーレイ MTU、ルート MTU/advmss、MSS clamp を記録
source-preservedサーバー側 SSH がクライアントの mobility /32 をピア IP として認識
no-nat同じピア IP チェックを、明示的な no-NAT アサーションとして記録

Forcefrag / MSS の比較​

通常の実行では routerd 導出の MSS clamp で問題なくパスするはずです。ラボで P2-b の force fragmentation 動作を証明する必要がある場合は、同じ D11 ペアセットを 2 回実行します:

  1. forceFragmentIPv4: false（デフォルト）: TCP 転送は MSS clamp で通過するはず。オーバーサイズの DF 非 TCP はアンダーレイの PMTU に依存して失敗する場合があります。
  2. 該当する OverlayPeer または TunnelInterface で forceFragmentIPv4: true: 同じ DF プローブがパスし、ルーターエビデンスに routerd_forcefrag が表示されるはずです。

force fragmentation をグローバルに有効化しないでください。パススコープに限定し、before/after の設定ダイジェストをエビデンスバンドルに記録してください。

エビデンスレビューチェックリスト​

protocol-probe.json の各ペアについて:

  • checks.ftpActive、ftpPassive、nfs、rpc、bulkTransfer、pmtu、sourceIpPreserved、noNat がすべて pass。
  • details.sourceIpPreserved.peer_ip がクライアントサイトの mobility /32 と一致。
  • details.rpc.dynamic_port が存在し、111 ではない。
  • iperf3 が利用可能な場合、details.bulkTransfer.retransmits が記録されている。
  • details.pmtu.overlay_mtu、route_mtu または route_advmss、mss_clamp が記録されている。

外側の result.json には以下のパスアサーションを含める必要があります:

  • protocol_transparency
  • ftp_active_passive
  • nfs_rpc
  • bulk_transfer_pmtu
  • protocol_source_ip_preserved
  • protocol_no_nat

SAM E2EハーネスはFTP、NFS、CIFSの読み取り・書き込み内容を完全一致で確認します。failover転送には既知の64 MiBペイロードを使い、ダウンロード後のサイズとSHA-256を照合します。故障注入前に今回の転送jobが実行中で部分データが到着していることを確認し、進行を取得できなければ未判定として停止し、故障注入や再試行を行いません。開始、結果、失敗試行の証跡を保持します。任意の転送観測と性能値は通常の故障後matrixの合否から分離します。deployでは今回専用ディレクトリを使い、必須copy/setupの失敗を伝播し、サービス再起動前にインストール済みbinaryと設定を今回のペイロードと照合します。

L2 qualificationには同じproviderと閾値設定によるbefore/afterの両観測と抑制機構の記録が必要です。beforeの取得成功は次の操作を許可しますが、保存した集計はafter取得まで未判定で、afterは集計合否を終了コードに反映します。failoverの経過時間は単調時計で計測し、journal照合用UTCを別記録します。providerのVM停止実装はstop-activeを扱います。drainには明示的なCE_<PROVIDER>_DRAIN_INJECT_COMMANDまたはCE_DRAIN_INJECT_COMMANDが必要で、on-premisesの停止にも明示的なnode-stop commandが必要です。keepalivedの停止だけでnode停止のqualificationを成立させません。

Federation qualificationの証跡​

scripts/cloudedge-federation-qualification.shのrelease qualificationには正のcyclesと全8シナリオが必要です。--allow-skipで開発用の部分集合を実行できますが、その結果はreleaseを認定しません。試行ごとに新しい証跡ディレクトリとevent IDを使い、commandのstdout/stderr/終了コードを保持します。workerはcleanupを含む既存の--duration予算で停止します。失敗、観測不足、cleanup未確認なら、再試行せず後続の故障とcycleを止めます。残った故障markerは次の試行前に運用者が確認します。

TTL refreshは今回のreceiver eventのExpiresAtをsenderの延長値と照合します。古いdelivered行や欠けたstaleTTLは証明になりません。subscriptionの失敗・復旧は今回のevent IDとreceiver側の注入後時刻に束縛します。partitionの分離はA/Bの正常baseline、A故障中の今回のB配送、group/peerを限定したSLO違反とremediation、設定閾値の対応を記録します。同一閾値も有効です。securityは正しく署名した壊れたbodyと、不正署名を付けた有効bodyを使います。期待するHTTP 400/401、receiverでの未受理、今回の有効event配送が必要で、transport errorや5xxを拒否成功と扱いません。

OTelの可用性、sample、labelは診断情報です。欠損は未判定のまま保持し、数値ゼロや製品不合格に置換しません。保存するbinary SHA-256と製品source commitはQA repository commitと区別します。deploy済みsource identityが不明または不一致ならscenario故障前に停止します。終了1は観測したassertion不合格、2は不正入力/setup、3は観測またはprovenance不足です。変更はoffline境界検証済みであり、providerやreleaseのqualificationを成立させたものではありません。

開発用partition部分実行でmulti-groupを選ばない場合、B groupは要求しません。実機のGoは任意です。CE_BINARY_PROVENANCE_FILEには既存prepared/release contractを指定でき、routerdArtifact.commitとexecution.candidate_binary_hashesを今回のbinary SHA-256と照合します。runtimeのcommit表示との矛盾やhash不一致は未確認として保存し、commit引数だけでidentityを確認済みにしません。

eventdのdigestは対象systemd unitのMainPIDが実行する/proc/<pid>/exeから取得し、取得後にprocessと実行binaryを再確認します。processの欠損や変化は未確認として保持し、PATH上のbinaryで稼働中サービスのidentityを代用しません。成功応答でも空のOTel label配列は診断未判定です。

既存offline assertionはWireGuard peer blockと完全resource snapshot、各leafに復旧した正確な7 peer、注入したtransition eventのidentity・時刻、transportのpeer・address対応を照合します。SSEのrequest deadlineはblockした本文readを中断します。active-stable guardは指定fileの存在とversion tokenごとの一致を確認します。PoC bundleはschema検証をvalidated・unavailable・invalidとして記録し、新しいvalidator必須gateは設けません。capture stopでは既存のtypedな4 point recordを確認し、欠損・不正stateはPARTIALのままstop/copyを行いません。AWS fabricは要求したsecondary addressと最長一致routeを照合し、raw factsとPARTIAL/NOT-RUNを保持します。labctlは一致するcleanな現checkoutだけをbuildし、commit/tree identityを記録します。dry runやprebuilt入力はbuild完了・要求source使用を主張しません。RR stageの必須rowの重複・矛盾を拒否し、report gateは確認したoutcomeから導出します。実機qualificationを成立させる検証ではありません。