電腦網路與 Internet 通訊

單元 22 至 30 解答與評量規準

這是解答。建議先完成對應的習題與實驗，再對照推理過程與評分規準。

單元 22

  1. 否，TCP 可分兩段，內層 TLS 仍由 C 到 S；TLS 終止需另行設計與驗證。
  2. 普通 CONNECT 是 TCP 隧道；UDP 需 CONNECT-UDP 等擴充，不是任意 IP 轉送。
  3. ATYP 域名可交 P 解析，送 IP 則名稱可能已在 C 解析；實際軟體選項需核對。
  4. P 是外層解密／代理請求端，需要知道目的，不因外層 TLS 而不知情。

單元 23

  1. salt／nonce 是衍生或加密材料，PFS 需長期祕密洩漏不能重建過去會話的 key establishment，單用 PSK 通常不滿足。
  2. 格式、key 來源與長度、ciphers、重放狀態、時間檢查及兩端支援，不能只看 AEAD 名稱。
  3. VMess 與 SS2022 都可有協定認證的時鐘條件；TLS 憑證則有信任／名稱／有效期條件；TCP 可達不表示它們成功。
  4. 否。外層與內層 key/端點不同，外層 PSK 洩漏可暴露代理目的等，但經正確臨時金鑰協商的內層 TLS 可仍有 PFS。

單元 24

  1. VLESS 為代理 protocol，TLS/REALITY 為 transport-security，Vision 為特定 flow，TUN 為 IP 接管介面。
  2. 基礎 none 層不加密，新擴充則有特定握手/保護與相容需求，不能把新能力推給全部舊版本。
  3. 原始 Trojan 把 UDP 資料報包進 TLS 記錄，再放進同一條 TCP 串流。TCP 依序交付：遺失的段重傳到達前，接收端不會把後面已收到的 bytes 交給上層，TLS 與 Trojan 也就拿不到之後的資料報，這是 20 講過的隊首阻塞。重傳成功後資料報仍會到達，但可能已超過播放期限，應用只能丟棄或忍受延遲。UDP 本身不重傳；經 TLS／TCP 承載後，反而變成可靠但可能過期的交付。常見錯誤是以為 Trojan 轉送 UDP 就保有 UDP 的遺失行為。

單元 25

  1. 否，transport/security 相容不等同 flow 相容，需查指定核心與組合。
  2. TLS 驗證預期同儕，保密/完整性保護通道；padding 只改部分長度外觀，不保證端點可信或無法辨識。
  3. 能由本單元引述的文件內容確認的只有 transport↔security：此次文件列 REALITY 可配 RAW。protocol↔transport 要在同一核心版確認 VLESS 可用 RAW；flow↔其餘條件不能由前兩層推出，要查該版本 Vision 對承載、security 與 payload 的要求。即使設定被接受，direct-copy 也只在內層 TLS 符合條件並完成切換後才成立。另要核對 REALITY 的伺服器 key 材料、shortId 與分發管道，以及 UDP/443 的處理。固定核心版並通過它的 validator 之前，只能說「引述的文件未見衝突」，不能說可用。常見錯誤是把某一層相容當成整組可用。

單元 26

  1. TCP 使用可靠 stream，UDP 走不重傳 DATAGRAM；fragment 遺失也可讓整份資料報丟失。
  2. 代理段可恢復遺失，卻使舊 UDP 內容延遲到達，需以 deadline 交付率衡量。
  3. 否。代理命令並行／免等待與 TLS 會話恢復、early-data 是不同層次，需獨立驗證。
  4. 過高固定速率／補償可使排隊、丟包和競爭加劇，不創造實體頻寬。應設競爭對照。

單元 27

  1. 否，OS 還需把封包送到 WG 介面，AllowedIPs 只在 WG 內選 peer 及驗內層來源。
  2. peer 解密後可能轉到明文目的，該段需另行保護；peer 知道目的 IP，端點與設定分發也有信任要求。
  3. IPv6 使用另一套位址/route，需要 ::/0 等有效策略及出口；IPv4 前綴不匹配 IPv6。
  4. 以 TCP 為外層的 IP VPN（如 OpenVPN TCP 模式）可將原始 TCP 段保留在外層 TCP 中產生雙重恢復；普通 TCP 代理終止原始 TCP 並轉 bytes，是不同模型。WireGuard 外層為 UDP，不形成 TCP-over-TCP。TLS 套 TLS 也不是雙重 TCP 的同義詞。

單元 28

  1. 否，TUN 只提供 IP 介面；通道保護、路由、雙協定和 policy 需另行檢查。
  2. 系統 proxy 依應用遵守，UDP 支援還依 app 與 relay，未接管資料可走原出口。
  3. DoH/DoT 僅改變 DNS 的傳送保護，實際出口仍由路由與接管決定，resolver 仍見查詢。
  4. 單次網站測試不能確認所有 apps、UDP、IPv6、DNS、DoH、LAN、P endpoint 和故障 fallback。
  5. 先用 LAN 入口與代理上游各自的連線 ID 整理日誌，再依時間與端點關聯前後相接的兩段連線（§22.5，注意時鐘誤差），比對兩段的來源四元組、OS 查表與實體出口。代理新建的上游連線不一定沿用入口的 ID；兩段 socket 屬代理模型；不能由 LAN 客戶端來源規則推論上游匹配。涉及 mark 時要說明設定與恢復時機。

單元 29 開放題範例

  1. 可反駁假設：「L09 的源站 peer 等於 P 上游 socket 而非 C source」，以端點日誌比對反駁。
  2. 設計 A 顯式 SOCKS 入口；B 為 IP VPN 的離線推演，分別列 app 繞過和 OS route 缺口。
  3. L09 證明兩段 TCP 端點，L13 證明 TLS 名稱/信任；它們分開執行，不能證明已部署了一個有 TLS 的 SOCKS 代理。
  4. 控制源站與 payload；未控制 OS 背景排程與 CPU 競爭，計時需多次與分布。

選 D、E 兩個 LAN 題目時，kind=model 的模型結果與實測分開給分；圖表再完整，也不能取代路徑證據。

單元 30 期末 100 分

  1. 12 分：203.0.113.30 依 OS 路由進 wg0，但 WireGuard 依內層目的找不到 AllowedIPs 涵蓋它的 peer，封包被丟棄，不會自動退回實體出口（2 分）。172.16.4.9 進 wg0 後匹配 peer 的 172.16.0.0/12，外層 UDP 送往 198.51.100.7，因 /32 例外經實體出口，不會遞迴進自己的隧道（2 分）。2001:db8:5::30 只匹配實體介面的 ::/0，不經隧道、不受隧道保護；名稱若同時有 A 與 AAAA，應用可能優先走這條 IPv6 路徑（2 分）。雙協定全隧道要改兩處查表：peer 的 AllowedIPs 加入 0.0.0.0/0 與 ::/0，OS 的 IPv6 預設路由改到 wg0（2 分）；還要保留 endpoint 例外（endpoint 若用 IPv6 也要有例外）、指定並驗證 DNS 路徑，確認 peer 端轉送兩種位址族並能回程，以及隧道 MTU（4 分）。wg-quick 等工具可能另建路由，要看最終的路由表與 peer 設定。
  2. 10 分：VLESS 為代理 protocol，TLS／REALITY 為 transport security，Vision 為 flow，WebSocket 為 transport；TUN 為 IP 接管介面，WireGuard 為 IP VPN（七個名稱分類共 5 分，錯一個扣 1 分，扣完為止）；說明 TUN／WG 不能與 VLESS 同欄替換（2 分）；此次文件 WebSocket＋REALITY 不相容，transport/security 支援也不保證 flow 支援，需指定版本核對（3 分）。
  3. 10 分：分別說明 PSK 與臨時協商／PFS 條件（4 分）、獨立重放狀態（3 分）、代理需知目的（3 分）。不得以 AEAD 直接推 PFS。
  4. 12 分：QUIC stream 在同一 stream 內可靠、有序，遺失會重傳，後面的資料要等缺口補齊；DATAGRAM 受壅塞控制，但不重傳、可能遺失；Hysteria 2 以 stream 轉送 TCP，以 DATAGRAM 轉送 UDP（3 分）。乙要切成 3 個 DATAGRAM，任一片遺失，接收端就丟棄整份，QUIC 也不重傳任何一片：完整到達率 0.98×0.98×0.98≈94.1%，整份遺失約 5.9%，接近單片遺失率的 3 倍（3 分）。甲適合不重傳的 DATAGRAM：遺失的一份很快被下一份取代，可靠重傳反而讓過時的位置晚到，還拖住後面的更新；用最新狀態的延遲（新鮮度）或期限內的更新率評估（3 分）。乙要完整、可晚到，適合可靠承載，例如應用改走 TCP、由代理以 stream 轉送，或用 TUIC 的可靠 stream 模式，也可把快照縮到一個 DATAGRAM 內並在應用層補送；用 1 秒內的完整到達率與有效 bytes 評估（3 分）。只比最終到達率或平均延遲都不夠。
  5. 8 分：1450−40−8−16−16=1370 bytes（5 分）；外層條件、padding、實際 PMTU 及內層 IPv6（不得低於 1280）等限制（3 分）。
  6. 12 分：分段與證據邊界（4 分）：瀏覽器驗證的是 CDN 出示的 shop.test 憑證，只證明用戶端到 CDN 這段的身分與保護；CDN 到源站是另一條 TLS，由 CDN 驗證源站憑證。502 由 CDN 這個 HTTP 中繼產生，表示它沒有從上游取得有效回應，不是源站的業務錯誤。最低修正並保留驗證（5 分）：讓 CDN 能驗證源站憑證，例如源站改用 CDN 信任的 CA 簽發、名稱涵蓋 origin.shop.test 並送出完整鏈的憑證；或在 CDN 支援時，只為這個源站加入內部 CA 作為信任來源。不得關閉驗證，也不得改用明文 HTTP 連源站來繞過。後續驗證（3 分）：從受控主機用與 CDN 相同的信任設定，以 origin.shop.test 驗證源站憑證鏈（正對照）；拿掉該信任來源或改用錯誤名稱時仍應失敗（負對照）；再經 CDN 重測，確認 CDN 日誌不再有驗證錯誤、回應來自源站，並記錄憑證指紋與有效期。
  7. 12 分：IP 檢查頁只證明這次瀏覽器的 HTTP 請求經系統代理從 P 出口，不能證明其他應用、UDP、IPv6、DNS 或直接 IP 的連線也經 P（3 分）。可區分的假設例如：一、會議軟體的控制連線遵守系統代理（P 日誌裡那一條 TCP），媒體卻用 UDP 直接送出；系統代理只是應用層的約定，軟體或本機客戶端不一定支援 SOCKS5 UDP ASSOCIATE。證據是在實體介面擷取到該軟體的 UDP 以本地位址送往媒體伺服器，P 端沒有對應的 UDP 轉送。二、媒體改走 TCP 或 IPv6 直連而繞過代理；證據是同一時間的擷取中，傳輸協定、位址族與目的都和 P 日誌對不上。每個假設連同能區分它的證據各 3 分（6 分）。修正：改用能接管 UDP 的入口（例如 TUN 搭配能轉送 UDP 的通道），或確認應用與 P 兩端都支援 UDP 轉送；做不到就依政策明確阻擋，並說明 fallback。修正後逐項核對 TCP／UDP、IPv4／IPv6、DNS／DoH 與 P endpoint，以本機擷取與 P 日誌在同一時間比對（3 分）。
  8. 12 分：Dijkstra（4 分）：確定 R1 後，R2=1、R3=4；確定 R2 後，R3 降為 3（經 R2），R4=8（經 R2）；確定 R3 後，R4 降為 6（經 R3），R5=8（經 R3）；確定 R4 後，R5 降為 7（經 R4）；最後確定 R5（每輪暫時成本 3 分）。R1 到 R5 為 R1-R2-R3-R4-R5，成本 7；R1-R3-R4-R5 與 R1-R2-R3-R5 都是 8（1 分）。斷線與收斂（4 分）：重算得 R2=1、R3=3（經 R2）、R4=8（經 R2）、R5=8（經 R3），R1 到 R5 改走 R1-R2-R3-R5，成本 8；R1-R2-R4-R5 與 R1-R3-R5 都是 9（2 分；只看重算結果與路徑，不要求逐輪表）。R3、R4 先由鄰接中斷（hello 逾時或介面狀態）得知，再泛洪新的鏈路狀態，其他路由器收到後各自重算。偵測與重算完成前，R3 可能仍把往 R5 的封包送上已斷的鏈路而遺失，形成暫時黑洞；各路由器的資料庫不一致時，一般拓樸也可能出現暫態迴路（2 分）。BGP 政策（4 分）：LOCAL_PREF 是本地政策，比 AS_PATH 長度先比較；經乙的 LOCAL_PREF 200 較高，所以選經乙的路由，即使它的 AS_PATH 較長（2 分）。AS_PATH 只數經過的 AS，不代表路由器跳數、物理距離或延遲，較短不保證較快；宣告可達也不等於資料實際照此轉送，要另外量測（1 分）。不當 transit：對甲、乙都只宣告企業自己的前綴，用輸出過濾擋下從另一個上游學到的路由；否則甲可能經企業把流量送往乙（1 分）。常見錯誤是以為 BGP 一律選 AS_PATH 最短的路由，或用 Dijkstra 的成本解釋跨組織選路。
  9. 12 分：對映（2 分）：同一內部端點在 1 秒內送往兩個目的，得到不同的外部埠。題設已排除探測期間對映到期與 NAT 設定改變，所以 61001 不是原對映到期後重建的結果，而是 NAT 為不同目的另建的對映：不是 EIM，對映依目的而定，屬位址相關或位址與埠相關對映。報告寫實測條件，不只貼 symmetric 之類的標籤。尚未確定的行為（4 分）：X1、X2 的 IP 不同、埠相同，分不出位址相關與位址與埠相關對映；從同一內部端點再送往 X1 的另一個埠（例如 192.0.2.31:3479），外部埠不變表示位址相關，改變表示位址與埠相關（1 分）。過濾行為無法由對映推得（§16.2），這兩次只觀察到對映，所以 Y 能否送達要分條件：若過濾是 EIF 且 61000 的對映仍有效，Y 的封包可能送達；若是 ADF 或 APDF，而筆電沒有先送封包給 Y，就會被拒絕（2 分）。要知道是哪一種，必須另外測試過濾：讓 X1 從筆電沒送過的另一個埠，以及一個筆電沒聯絡過的位址，各送封包到 61000（需要伺服器配合從其他位址或埠回送）；沒聯絡過的位址也能送達表示 EIF，只有 X1 的另一個埠能送達表示 ADF，兩者都不能送達表示 APDF（1 分）。即使筆電先送往 Y，非 EIM 的 NAT 也會為 Y 另建對映，外部埠要以 Y 實際收到的來源埠為準，不能沿用 X1 回報的 61000；所以只靠 STUN 回報的候選不保證連得上，要由 ICE 做連通性檢查、試其他候選，必要時改用 TURN 中繼。對映與過濾的逾時、TCP 的行為也不能由這兩次推論。常見錯誤是由「不是 EIM」推斷 Y 一定或多半會被擋；寫出上述條件即得該 2 分，只寫「多半被丟棄」不給分。靜默後收不到（6 分）：這組證據支持對映重建。最直接的解釋是家用 NAT 的 UDP 對映在約 45 秒的靜默中逾時被刪除：S 送往舊外部端點的封包在 NAT 找不到對映而被丟棄；筆電再送出時 NAT 建了新對映、配到新埠，S 改回送新端點後恢復。若只有過濾狀態逾時、對映仍在，筆電再送出時會沿用原外部埠；所以「外部來源埠變了」表示對映被重建，不只是過濾狀態被更新（2 分）。要排除的假設例如上游還有一層 CGNAT 而且逾時更短，或筆電主機防火牆的 UDP 狀態也逾時。在同一時間擷取家用 NAT 的 WAN 側、LAN 側與筆電介面，並查 NAT 的連線狀態表：封包到了 WAN 卻沒出現在 LAN、表中已無這筆對映，指向家用 NAT；到了筆電介面卻沒交給應用，指向主機防火牆；S 確實送出而 WAN 沒收到，指向上游的 CGNAT 或路徑（2 分）。修正：應用以短於最短逾時、留有餘裕的間隔送 keepalive，代價是流量與耗電；若能管理這臺 NAT，可把 UDP 對映逾時調長（RFC 4787 要求一般不短於 2 分鐘，建議預設 5 分鐘以上）。不能把過濾改成任意來源可入站，也不能關閉防火牆。驗證：逐步改變靜默時間（例如 20、30、40、50 秒）找出逾時邊界；啟用 keepalive 後靜默超過該邊界，S 的日誌顯示外部埠不變，封包也送達應用（2 分）。

LAN 替代題以替換為原則：第 1、7 題各自可改作 LAN 題，可只換一題，也可兩題都換；作了 LAN 題就不作該題原題，配分沿用原題的 12 分，總分與課程比例不變。第 8、9 題沒有 LAN 替代題。

LAN 替代第 1 題 12 分：

LAN 替代第 7 題 12 分：

專題另依單元 29 的 100 分規準。開放設計可多解；必要的是明確假設、重現方法與符合證據範圍的推論。