$30 off During Our Annual Pro Sale. View Details »

謎は全て解けた!安楽椅子探偵に捧げる AWS ネットワーク分析入門 #CNDT2022 / CloudNative Days Tokyo 2022

y_taka_23
November 22, 2022

謎は全て解けた!安楽椅子探偵に捧げる AWS ネットワーク分析入門 #CNDT2022 / CloudNative Days Tokyo 2022

CloudNative Days Tokyo 2022 で使用したスライドです。

ネットワークのトラブルシューティングは辛い作業になりがちです。特に AWS の VPC ネットワークは多数の設定が必要であり、疎通ができない場合にその原因を発見・修正するためには往々にして高いスキルが必要となります。

このような状況に対処し、誰でも体系的にネットワーク不通の原因を解消できる助けにするため、AWS は VPC Reachability Analyzer と VPC Network Access Anazlyer という二つの機能を提供しています。この機能には「到達不可能な場合であっても、その原因部分を含め送信元から送信先への完全な経路が得られる」という特徴があります。

今回の講演ではこの点について、AWS から公開されている 2 本の論文をベースにして解説を行いました。

講演アーカイブ動画:https://event.cloudnativedays.jp/cndt2022/talks/1591
ブログ記事:https://ccvanishing.hateblo.jp/entry/2022/11/23/205855

y_taka_23

November 22, 2022
Tweet

More Decks by y_taka_23

Other Decks in Technology

Transcript

  1. 謎は全て解けた! 安楽椅子探偵に捧げる AWS ネットワーク分析入門 #CNDT2022 #CNDT2022_B チェシャ猫 (@y_taka_23) CloudNative Days

    Tokyo 2022 22nd Nov. 2022
  2. 繋がらないネットワークの 「犯人」を見つけられるか?

  3. 本日のコンテンツ • 2 種類の VPC Network Analyzer の概要 ◦ ネットワーク到達可能性が全自動で検査できる

    • SAT ソルバと SMT ソルバ ◦ VPS Network Analyzer を支える要素技術 • SMT ソルバによるネットワークのエンコーディング ◦ VPC の到達可能性をどうやって表現するのか
  4. 安楽椅子探偵の洞察 1. Reachability Analyzer と Network Access Analyzer

  5. Instance A Subnet X Instance B Instance C Subnet Y

    In: 127.0.0.0/16: TCP 22 Out: 0.0.0.0/0: All SecurityGroup 1 In: 127.0.0.0/16: TCP 22 Out: 127.0.0.1/32: All SecurityGroup 2 VPC (127.0.0.0/16) RouteTable 0.0.0.0/0 (Public IP: true) SSH Internet Gateway SG SG
  6. Instance B から C に SSH 繋がらないんだけど

  7. インターネットにアクセスできる ルートを塞ぎたいんだけど

  8. Instance A Subnet X Instance B Instance C Subnet Y

    In: 127.0.0.0/16: TCP 22 Out: 0.0.0.0/0: All SecurityGroup 1 In: 127.0.0.0/16: TCP 22 Out: 127.0.0.1/32: All SecurityGroup 2 VPC (127.0.0.0/16) RouteTable 0.0.0.0/0 (Public IP: true) SSH Internet Gateway SG SG SecGrp の ルールが 間違い Public IP が 自動で付与 されている
  9. ネットワークのトラブルシュート • 実際に通信してみて確認 ◦ traceroute、nc コマンドや E2E テストなど ◦ 疎通不能な箇所はわかっても修正方法が不明

    • 実際の通信は行わず、設定の状況を確認 ◦ マネジメントコンソールからアタリをつける ◦ 多数の設定の相互作用を完全に把握する必要がある
  10. もっと労せず確実に「推理」したい

  11. ふたつの VPC Network Analyzer • VPC Reachability Analyzer ◦ 二点間を与えると、その間を繋ぐ経路を自動探索

    ◦ 到達不可能な場合は原因のコンポーネントを指摘 • VPC Network Access Analyzer ◦ 条件を与えると該当する経路を自動で列挙 ◦ 意図せず繋がってしまっている経路を検知できる
  12. Q: Instance A から C への TCP 22 による通信は到達可能か? A:

    可能。実際の経路は以下の通り VPC Reachability Analyzer
  13. Q: Instance B から C への TCP 22 による通信は 到達可能か?

    A: 不可能。 SecurityGroup 2 を 修正する必要がある 「犯人」の指摘 VPC Reachability Analyzer
  14. Q: Internet Gateway に対して アクセスできるインスタンスと その経路を全て列挙せよ A: Instance C から次のような

    インターネットアクセスが存在 VPC Network Access Analyzer
  15. よく考えるとこの機能はかなり不思議

  16. Q: Instance B から C への TCP 22 による通信は 到達可能か?

    A: 不可能。 SecurityGroup 2 を 修正する必要がある 要修正ポイント以降も 想定経路が検出されている
  17. ? SG • Packet Probing (例:traceroute) による経路探索 ◦ 最初の不通ポイントまでの情報しか得られない •

    VPC Reachability Analyzer による経路探索 ◦ 不通ポイントを含むが最後まで繋がった経路が見つかる SG SG
  18. つまり実際のパケットを 送出している訳ではない

  19. まるで安楽椅子探偵の如き推理

  20. Section 1 のまとめ • VPC ネットワークのトラブルシュートの難しさ ◦ 設定が多数あって原因箇所が特定しづらい • VPC

    Network Analyzer による到達可能性判定 ◦ 条件を与えれば自動で経路を探索してくれる • 修正すべき点も含めて送信先までの経路を提示 ◦ 実際のパケット送出による経路探索ではない
  21. 安楽椅子探偵の頭脳 2. SAT ソルバと SMT ソルバ

  22. SAT ソルバ • 命題論理の充足可能性(SATisfiability)を検査 ◦ 各変数に真偽を割り当てて全体を真にできるか? • 例 1:(P ∨

    Q) ∧ (P ∨ ¬Q) ∧ (¬P ∨ ¬Q) ◦ 答:充足可能(P = True, Q = False) • 例 2:(P ∨ Q) ∧ (P ∨ ¬Q) ∧ (¬P ∨ ¬Q) ∧ (¬P ∨ Q) ◦ 答:充足不可能(どう割り当てても無理)
  23. SMT ソルバ • SAT ソルバは命題論理しか扱えない ◦ 命題論理で書き直すと問題のサイズが爆発しがち ◦ 元の問題の性質(例:不等号の推移性)が失われる •

    特定領域の理論ソルバを外部実装して組み合わせる ◦ 整数の算術、文字列、ビットベクトル、など ◦ ∧ や v など論理部分は SAT ソルバが担当
  24. SMT ソルバ • 例 1(整数の算術) ◦ 問:(x < y +

    2) ∧ (x = 2z + 10) ∧ (y + z >= 10) ◦ 答:充足可能(例:x = 12, y = 11, z = 1) • 例 2(文字列) ◦ 問:str ++ "b" = "a" ++ str ◦ 答:充足不可能(先頭の a の個数が合わない)
  25. どうやって組み合わせるのか?

  26. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 P: True, Q: True R: True, S: True 真偽割り当ての可能性 充足可能 理論ソルバで解く問題 x > 0, y - 2z ≧ 0, y = z, z ≧ x Boolean Abstraction Refinement
  27. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 理論ソルバで解く問題 x > 0, y - 2z ≧ 0, y = z, z ≧ x (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) ∧ ¬(P ∧ Q ∧ R ∧ S) 充足不可能なので ¬(P ∧ Q ∧ R ∧ S) を追加 P: True, Q: True R: True, S: True 真偽割り当ての可能性 Boolean Abstraction Refinement Theory Learning
  28. ((x > 0) ∨ (y - 2z ≧ 0)) ∧

    (¬(x > 0) ∨ (y = z)) ∧ (¬(x > 0) ∨ (z ≧ x)) P: x > 0 Q: y - 2z ≧ 0 R: y = z S: z ≧ x もともと解きたい問題 SAT ソルバで解く問題 (P ∨ Q) ∧ (¬P ∨ R) ∧ (¬P ∨ S) ∧ ¬(P ∧ Q ∧ R ∧ S) P: False, Q: True R: True, S: True 真偽割り当ての可能性 充足可能 理論ソルバで解く問題 x ≦ 0, y - 2z ≧ 0, y = z, z ≧ x x = 0 y = 0 z = 0 充足可能 Boolean Abstraction Refinement
  29. AWS のどこで使われているのか?

  30. Tiros(本日のテーマ!) • ネットワーク設定に関するクエリに答える ◦ 例:EC2 インスタンス A から B に

    SSH 可能か? ◦ 実際のパケットは送出せず、設定のみから推論 • いくつかの AWS サービスのバックエンドとして稼働中 ◦ VPC Network Analyzers、Inspector ◦ 一部のユーザには直接 API を提供している
  31. Zelkova • アクセス制御に関するクエリに答える ◦ 例:S3 Object が外部から読み取り可能か? ◦ 実際のアクセスは行わず、設定のみから推論 •

    セキュリティ系のサービスに統合されている ◦ IAM Access Analyzer、AWS Config、Macie など ◦ 内部的には Lambda Function として稼働
  32. 参考:CI/CD Conference 2021 での Zelkova 解説スライド https://speakerdeck.com/ytaka23/cicd-conference-2021

  33. Section 2 のまとめ • SMT ソルバによる充足可能性判定 ◦ 現実の問題に対して SAT は表現力が不足

    ◦ 用途特化した理論ソルバを別途組み合わせる • AWS でも SMT ソルバベースの機能を提供 ◦ Tiros:ネットワークに関する検査 ◦ Zelkova:アクセス制御に関する検査
  34. 安楽椅子探偵の思考 3. ネットワークの意味論と検査

  35. Reachability Analysis for AWS-Based Networks Backes J. et al. 2019

    https://doi.org/10.1007/978-3-030-25543-5_14
  36. 3 種類のバックエンド候補 • Soufflé (https://souffle-lang.github.io) ◦ Datalog 言語(Prolog の亜種)の処理系 •

    MonoSAT (https://github.com/sambayless/monosat) ◦ グラフ理論の特化ソルバを搭載した SMT ソルバ • Vampire (https://vprover.github.io) ◦ 一階述語論理の自動定理証明器
  37. 各バックエンドのベンチマーク • Vampire は遅すぎて論外 • ほとんどのケースにおいて Soufflé より MonoSAT が速い

    • 10 万インスタンスで 数 100 秒 〜 1,000 秒 • MonoSAT は複数経路に弱い (Backes J. et al. 2019, Fig. 4)
  38. MonoSAT • グラフ理論に関する特化ソルバ搭載の SMT ソルバ ◦ ユーザはグラフのエッジの候補を入力 ◦ MonoSAT は実際に繋げるエッジを解として返す

    ◦ 到達性判定の他、最小スパニング木なども可能 • ビットベクトルの理論も実装している ◦ エッジに重みを定義することもできる
  39. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  40. g = Graph() n1 = g.addNode() n2 = g.addNode() n3

    = g.addNode() e1 = g.addEdge(n1, n2) e2 = g.addEdge(n2, n3) e3 = g.addEdge(n1, n3) Assert(Not(And(e1, e2, e3))) Assert(Or(e1, e3)) Assert(g.reaches(n1, n3)) => e1: False, e2: False, e3: True n1 n2 n3 e1 e2 e3 • e1, e2, e3 の 3 辺のうち 少なくとも 1 辺は通行不能 • e1, e3 の 2 辺のうち 少なくとも 1 辺は通行可能 • n1 から n3 へは到達可能
  41. どうやってグラフ理論を使うのか?

  42. VPC ネットワークのエンコーディング • VPC のネットワークをグラフで表現 ◦ ノード:ネットワークコンポーネント ◦ エッジ:所属もしくはアタッチされている関係 •

    CIDR に対する条件はビットベクトルで表現 ◦ SecurityGroup や RouteTable など ◦ クエリと条件が合致しない場合はエッジを繋がない
  43. Instance A Subnet X Instance B Instance C Subnet Y

    In: 127.0.0.0/16: TCP 22 Out: 0.0.0.0/0: All SecurityGroup 1 In: 127.0.0.0/16: TCP 22 Out: 127.0.0.1/32: All SecurityGroup 2 VPC (127.0.0.0/16) RouteTable 0.0.0.0/0 (Public IP: true) SSH Internet Gateway SG SG
  44. RouteTable X NW ACL X SecGrp 2 SG ENI B

    Instance B ENI C Instance C ENI A Instance A SecGrp 1 SG RouteTable Y NW ACL Y
  45. Packet Header protocol: TCP srcAdr: 172.0.1.1 dstAdr: 172.0.3.1 port: 22

    e1 e2 e3 e4 Ingress: 172.0.0.0/16:TCP22 ENI SecGrp NW ACL SG
  46. Packet Header protocol: TCP srcAdr: 172.0.1.1 dstAdr: 172.0.3.1 port: 22

    e1 e2 e3 e4 Assert( Implies( Or(srcAdr & 0xFFFF0000 != 0xAC000000, protocol != TCP, port != 22) , And(Not(e1), Not(e2)))) Ingress: 172.0.0.0/16:TCP22 ENI SecGrp NW ACL SG
  47. RouteTable X NW ACL X SecGrp 2 SG ENI B

    Instance B ENI C Instance C ENI A Instance A SecGrp 1 SG RouteTable Y NW ACL Y Q: Instance A から C へは到達可能か?
  48. RouteTable X NW ACL X SecGrp 2 SG ENI B

    Instance B ENI C Instance C ENI A Instance A SecGrp 1 SG RouteTable Y NW ACL Y Out: 127.0.0.1/32 Q: Instance B から C へは到達可能か?
  49. 残る謎は「最後までの経路」の探索

  50. Debugging Network Reachability with Blocked Paths Bayless S. et al.

    2021 https://doi.org/10.1007/978-3-030-81688-9_39
  51. Blocked Path Analysis • Blocked Path: 不通ポイントを除けば完全なパス ◦ traceroute では最初の不通ポイント以後が不明

    ◦ 不通の原因となっている設定を指摘したい • 到達させるための修正候補が複数あり得る ◦ ユーザが修正できない原因は表示しても仕方がない ◦ 複数あるなら修正可能なものを優先したい
  52. Minimal Correction Subset (MCS) • いわば「修正不可避な条件」の集合 ◦ MCS に属する条件を除外すれば残りは充足可能 ◦

    MCS に属する条件を一つでも追加すると充足不可能 • Tiros は FastDiag アルゴリズムを採用 ◦ 二分探索のようなイメージで MCS の範囲を絞り込む • MCS は「極小」なので複数の取り方があり得る
  53. P ∨ Q P ∨ ¬Q ¬P ∨ ¬Q ¬P

    Q 元の問題 P ∨ Q P ∨ ¬Q ¬P ∨ ¬Q 充足可能 P ∨ Q P ∨ ¬Q ¬P ∨ ¬Q ¬P 充足不可能 P ∨ Q P ∨ ¬Q ¬P ∨ ¬Q Q 充足不可能 MCS
  54. 可能ならユーザが修正可能な 条件のみで MCS を探したい

  55. 制約のクラス分け • H: Hard Constraints ◦ ユーザから不可視の条件(例:SMT の内部変数) • N:

    Non-Configurable Constraints ◦ ユーザが変更不可能な AWS の仕様(例:local route) • U: User-Configurable Constraints ◦ ユーザが変更可能な設定(例:SecurityGroup)
  56. Blocked Path の検出 (1) • まず H だけで充足可能かどうか調べる • H

    が充足不可能ならユーザの設定では解消できないので Tiros は諦め、他の方法で原因を確認 N U H
  57. Blocked Path の検出 (2) • MCS N := MCS(H ∪

    N) を求める • H は充足可能なので MCS N ≠ ∅ なら原因は N 側にある • この場合、最初の不通ポイントまでのルートを返す MCS N H N U
  58. MCS N Blocked Path の検出 (3) • MCS U :=

    MCS(((H ∪ N) \ MCS N ) ∪ U) を求める • (H ∪ N) \ MCS N は MCS の定義から充足可能なので MCS U ≠ ∅ なら原因は U 側にある MCS U H N U
  59. MCS N MCS U Blocked Path の検出 (4) • (H

    ∪ N ∪ U) \ (MCS N ∪ MCS U ) は MCS の定義から 充足可能なので、その解を Blocked Path とする • MCS U ⊆ U がユーザに提示される「犯人」となる H N U
  60. Section 3 のまとめ • VPC ネットワークの SMT エンコーディング ◦ MonoSAT

    はグラフ理論用の特化ソルバ内蔵 ◦ コンポーネントをノードで、接続をエッジで表現 ◦ 疎通に条件がいる部分はビットベクトルで表現 • ユーザが修正可能な条件を優先してフィードバック ◦ 制約を H、N、U に分類して順次 MCS を詰めていく
  61. 安楽椅子探偵の回想 4. 本日のまとめ

  62. 本日のまとめ • VPC Reachability / NW Access Analyzer の機能 ◦

    実際のパケット送出は行わず設定のみから検査 • SMT ソルバによる充足可能性判定 ◦ SAT ソルバ + 特定領域専用の理論ソルバ • Tiros による VPC ネットワークの意味論 ◦ MonoSAT のグラフ表現 + MCS による修正箇所特定
  63. It’s Elementary, My Dear AWS Network! Presented By チェシャ猫 (@y_taka_23)