緯育 2026-0314.2 - 修訂歷史

Kuyohong：/* 實作與觀察（WireShark + ping） */

2026-04-07T09:54:12Z

實作與觀察（WireShark + ping）

←上個修訂		於 2026年4月7日 (二) 09:54 的修訂
行 208：		行 208：
	=== 實作與觀察（WireShark + ping）===		=== 實作與觀察（WireShark + ping）===
	* 前置檢查與清快取		* 前置檢查與清快取
	** 以圖形化介面或命令列查看本機DNS伺服器（Windows: ipconfig /all ~~或類似；講義提到「iafconfig、ipconfig~~ /~~o」為口誤或簡寫，重點在確認DNS設定）。~~		** 以圖形化介面或命令列查看本機DNS伺服器（Windows: ipconfig /all 或類似；講義提到「ifconfig、ipconfig /all」為口誤或簡寫，重點在確認DNS設定）。
	** 執行ipconfig /flushdns，顯示「成功清除DNS的快取」，避免快取影響觀測。		** 執行ipconfig /flushdns，顯示「成功清除DNS的快取」，避免快取影響觀測。
	* 抓包與過濾		* 抓包與過濾
	** 開啟WireShark，同步在命令列ping「WireShark.~~org」（講師口語亦稱wirehack.org，皆為示例目標；可替換其他網站）。~~		** 開啟WireShark，同步在命令列ping「WireShark.org」。
	** 停止抓取後設定過濾條件（Filter由學員自行研究，講師稍後提供指引）。		** 停止抓取後設定過濾條件（Filter由學員自行研究，講師稍後提供指引）。
	** 預期封包序列：前兩個為DNS（查詢與回覆），接著約八個ICMP（ping的往返），最後可能再有兩個DNS（情境變化）；若出現ARP，多為本機向Gateway詢問MAC位址。		** 預期封包序列：前兩個為DNS（查詢與回覆），接著約八個ICMP（ping的往返），最後可能再有兩個DNS（情境變化）；若出現ARP，多為本機向Gateway詢問MAC位址。
	** 觀察：DNS回覆之IP可能變動屬正常，尤其在低TTL與負載平衡策略下。		** 觀察：DNS回覆之IP可能變動屬正常，尤其在低TTL與負載平衡策略下。

	=== 進階課程預告與資安提示 ===		=== 進階課程預告與資安提示 ===
	* 進階DNS風暴觀察		* 進階DNS風暴觀察

Kuyohong：/* 中國網路封鎖與VPN管理 */

2026-03-17T04:51:51Z

中國網路封鎖與VPN管理

←上個修訂		於 2026年3月17日 (二) 04:51 的修訂
行 324：		行 324：
	=== 中國網路封鎖與VPN管理 ===		=== 中國網路封鎖與VPN管理 ===
	* DNS阻擋如「拉警戒線」；更強封鎖（長城防火牆）需VPN等「架梯子」越過。		* DNS阻擋如「拉警戒線」；更強封鎖（長城防火牆）需VPN等「架梯子」越過。
	* ~~合規VPN需交鑰匙，政府可解密檢視內容；測試右下（中國系）DNS對Google~~/Facebook等可達性可區分DNS層與更高層封鎖。		* 合規VPN需交鑰匙，政府可解密檢視內容；測試教材表格右下（中國系）DNS對Google/Facebook等可達性可區分DNS層與更高層封鎖。
	[[檔案:2026-0317-04.png\|800px]]		[[檔案:2026-0317-04.png\|800px]]

Kuyohong：/* 中國網路封鎖與VPN管理 */

2026-03-17T04:49:48Z

中國網路封鎖與VPN管理

←上個修訂		於 2026年3月17日 (二) 04:49 的修訂
行 325：		行 325：
	* DNS阻擋如「拉警戒線」；更強封鎖（長城防火牆）需VPN等「架梯子」越過。		* DNS阻擋如「拉警戒線」；更強封鎖（長城防火牆）需VPN等「架梯子」越過。
	* 合規VPN需交鑰匙，政府可解密檢視內容；測試右下（中國系）DNS對Google/Facebook等可達性可區分DNS層與更高層封鎖。		* 合規VPN需交鑰匙，政府可解密檢視內容；測試右下（中國系）DNS對Google/Facebook等可達性可區分DNS層與更高層封鎖。
			[[檔案:2026-0317-04.png\|800px]]

Kuyohong：/* DNS 伺服器的選擇與影響 */

2026-03-17T04:44:46Z

DNS 伺服器的選擇與影響

←上個修訂		於 2026年3月17日 (二) 04:44 的修訂
行 279：		行 279：
	** 可將電腦 DNS 設定為不同伺服器，並用 Wireshark 觀察回應的 IP 數量與內容，以評估服務品質。		** 可將電腦 DNS 設定為不同伺服器，並用 Wireshark 觀察回應的 IP 數量與內容，以評估服務品質。
	[[檔案:2026-0317-03.png\|800px]]		[[檔案:2026-0317-03.png\|800px]]
			=== 網路故障排除與侷限 ===
			* 基本建議（線材、燈號、IP設定、重開電源）對有基礎者效益有限；ping 127.0.0.1不具判斷外網連線意義。
			* 採批判性閱讀論壇建議：以封包流向與TCP/IP邏輯為分析基礎，不盲從。
			=== 調參降延遲的風險 ===
			* 常見「降高 ping」做法為縮短等待/重傳偵測時間；微軟預設基於統計與設計，貿然調整效果不保證且可能加劇競逐。
			* 不建議使用一鍵調參軟體，幫助有限，應以封包擷取與針對性檢測為主。
			=== LAN中逾時與延遲尖峰的診斷 ===
			* 案例：連續 ping（如 -n 100）在區網出現封包遺失與偶發尖峰，推估Windows逾時約5秒；「每個都很短，偶爾一個極長」屬不尋常。
			* 檢測方向：伺服器、網路設備/拓撲、OS、NIC。更換NIC後吞吐與逾時改善，但尖峰仍偶發，顯示潛在根因未盡除。
			* NIC選型：避免舊規格，直接升級至1G等更高等級並做更換前後對比測試。
			=== NAS/路由設備與延遲機制 ===
			* NAS帳號驗證與檔案加密/解密吃CPU，會造成封包延滯（超過5秒可能仍回應）；加RAM無助，應升級CPU。
			* 路由/閘道記憶體不足可能直接不收後續封包，導致完全無回覆。
			=== Wi‑Fi診斷與設備負載 ===
			* 以持續 ping AP，從遠到近測距離與訊號品質；靠近仍大延遲則檢查AP連線數與CPU負載。
			* 家用級AP在高並發（20→50→100人）易超載；需分流或更換企業級設備。
			* 無線瞬斷兩大成因：過熱與電源老化；以手感溫度、燈號重啟、可調式變壓器替換測試判斷。
			=== 用 ping 與封包推理的通則 ===
			* 先驗檢查：抓封包確認是否有回應。仍有回應偏向CPU忙；完全無回應偏向記憶體或丟包。
			* 閱讀平均、最小/最大與分佈，維持測試條件一致，避免以極端值做結論。
			=== 封包路徑與TTL推理 ===
			* 常見初始TTL（64/128/255）；觀察扣減推估Hop數並綜合延遲判斷地理位置與ISP。
			* 範例：到Google扣8推論跨國約7–8站；中華電信DNS到家若多Hop，可能因跨ISP繞路。
			=== DNS選擇：速度、隱私與安全 ===
			* 不同DNS可能解析至不同CDN節點，影響下載/瀏覽速度；依環境用DNS Benchmark等工具自測首查與快取回應時間。
			* 建議設定至少兩個DNS，優先包含自身ISP DNS以減少跨ISP延遲，另配公共DNS備援；避免僅設單一DNS。
			* 安全與隱私迷思：僅換DNS不等於更安全；未使用DoH/DoT仍是明碼。Quad9以導頁阻擋惡意站，TWNIC 101.101主打隱私，公共DNS免費多為資料蒐集與服務優化。
			=== 加密DNS（DoH/DoT）技術與平台支援 ===
			* DoT（TCP 853）以TLS加密；DoH（TCP 443）將DNS封裝在HTTPS中，外觀如一般網頁流量。
			* 在高管制環境下可能封鎖853/TCP，DoH因443/TCP封鎖成本高而更易存活。
			* 平台支援：
			** Windows 11內建DoH；Windows 10需第三方常駐軟體代理（例如AdGuard）。
			** Firefox/Edge支援安全DNS（瀏覽器可獨立於OS DNS設定）。
			** Android 9起支援DoT；需選擇支援端點。
			** 蘋果生態宣稱支援曾見蛛絲馬跡，但以實際系統設定為準。
			* 啟用加密DNS後，封包分析將看不到明文DNS；需據此調整抓包與判讀。
			=== DNS測試與快取行為 ===
			* 首次查詢可見DNS封包與TTL；短時間再次 ping 同網域通常因快取不再產生DNS查詢。
			* 測不存在網域時DNS回覆「查不到」，終端呈現類似但封包細節有別。
			=== 廣告阻擋：外掛 vs DNS層 ===
			* 瀏覽器外掛以大型黑名單比對，可能影響效能但能清理版面。
			* DNS層過濾可達約八成阻擋率、可全域套用（家用分享器設定），但非百分百且應留意應用相容性（遊戲/影音獎勵流程可能阻塞）。
			* iOS多以「VPN」形式上架達到阻擋；被過濾的版位可能仍保留可點擊區域，需避免誤觸。
			=== 中國網路封鎖與VPN管理 ===
			* DNS阻擋如「拉警戒線」；更強封鎖（長城防火牆）需VPN等「架梯子」越過。
			* 合規VPN需交鑰匙，政府可解密檢視內容；測試右下（中國系）DNS對Google/Facebook等可達性可區分DNS層與更高層封鎖。

Kuyohong：/* 進階課程預告與資安提示 */

2026-03-17T02:57:29Z

進階課程預告與資安提示

←上個修訂		於 2026年3月17日 (二) 02:57 的修訂
行 219：		行 219：
	** 本課只看用戶端到ISP DNS的風暴；後續課程將演示DNS間的遞迴／權威查詢風暴，包含若本機能加入特定節點時可見更完整流程。		** 本課只看用戶端到ISP DNS的風暴；後續課程將演示DNS間的遞迴／權威查詢風暴，包含若本機能加入特定節點時可見更完整流程。
	[[檔案:2026-0317-02.png\|800px]]		[[檔案:2026-0317-02.png\|800px]]
			=== 封包結構分析（以 Wireshark 為例）===
			* IP 層
			** 初學者可展開查看細節；有經驗的分析師通常關注來源與目的地 IP 位址。
			** IP 層協定欄位指示上層協定，例如 Protocol: UDP 表示承載的是 UDP 封包。
			* UDP 層
			** UDP 標頭核心資訊為來源埠（Source Port）與目的埠（Destination Port）。
			** UDP 標頭無欄位直接指明承載的應用層協定（如 DNS）；Wireshark 依埠號解析應用層協定。
			** 送出封包時，Wireshark 檢查目的埠；若為 53，則解析為 DNS。
			** 接收封包時，Wireshark 檢查來源埠；若為 53，則解析為 DNS。
			* 應用層協定的埠號
			** 更改標準埠號（如將 FTP 的 21 改為 2100）技術上可行，但客戶端需知悉新埠號才能通訊。
			** 分析工具依賴標準埠號解析協定；使用非標準埠號可能導致 Wireshark 誤判、分析錯誤或顯示大量錯誤訊息（黑色標示）。
			=== DNS 查詢封包（Query）===
			* DNS 標頭欄位
			** Transaction ID：隨機數（如 8102），用於匹配查詢與回應；回應封包使用相同 ID。
			** Flags：包含多個標誌位。
			** QR（Query/Response）：查詢封包為 0。
			** Standard Query：常見查詢類型，Flags 通常為 0x0100。
			** Counters：
			** Question Count：通常為 1。協定允許一包多問，但實務上幾乎都是一包一問。
			** Answer Count：查詢封包為 0。
			** Authority/Additional Records Count：查詢封包通常為 0。
			* DNS 問題區段（Question Section）
			** Name：查詢的網域名稱。
			** Type：查詢記錄類型。
			** A：查詢 IPv4 位址。
			** 若未停用 IPv6，可能同時發出查詢 AAAA（IPv6 記錄）的封包；若公司網路不使用 IPv6，會產生不必要流量。
			** Class：通常為 IN（Internet）。
			* 問題名稱（Name）的編碼方式
			** DNS 問題中的網域名稱為變動長度編碼。
			** 以一個數字位元組代表後續字元數量。例如 www.wireshark.org 編碼為 03 w w w 09 w i r e s h a r k 03 o r g。
			** 結尾以 00 位元組表示結束。
			** 該設計用以儲存不同長度的網域名稱。
			=== DNS 回應封包（Response）===
			* DNS 標頭欄位
			** Flags：
			** QR（Query/Response）：回應封包為 1。
			** Standard query response：Flags 通常為 0x8180。
			** Counters：
			** Question Count：1，對應查詢封包的問題。
			** Answer Count：回應的答案數量，例如 2 表示有兩個 IP 位址。
			* DNS 答案區段（Answer Section）
			** Name：對應查詢的網域名稱。
			** Type：記錄類型，如 A。
			** Class：IN。
			** TTL（Time to Live）：指示客戶端應快取於記憶體的時間（秒），例如 300 秒（5 分鐘）。在此期間再次訪問同一網站將直接使用快取，不再發出 DNS 查詢。
			** Data Length：RDATA 欄位長度；對 IPv4 位址（A 記錄）為 4 位元組。
			** Address（RDATA）：實際 IP 位址。
			* 處理多個 IP 位址
			** 當 DNS 回應提供多個 IP 位址（如 104.25.10.6、104.25.11.6）時，依講師觀察，客戶端通常先使用列表中的第一個 IP 連線。
			** 除非第一個 IP 連線失敗，否則不會嘗試第二個 IP。
			=== DNS 伺服器的選擇與影響 ===
			* DNS 伺服器與連線問題
			** 不同 DNS 伺服器（如 8.8.8.8、1.1.1.1）可能對同一網域提供不同或排序不同的 IP 列表。
			** 某網站無法訪問時，可能因大多數人使用的 DNS 伺服器所提供 IP 的路徑出現問題（如海底電纜中斷）；使用不同 DNS 的人可能獲得不同 IP，因而可正常訪問。
			* 判斷 DNS 伺服器好壞的方法
			** IP 數量：好的 DNS 伺服器可能返回所有相關 IP 位址，提供更多選擇；有些伺服器為節省流量僅返回一個 IP。
			** 進階使用者獲得多個 IP 位址更有利，因為提供備援。
			** 可將電腦 DNS 設定為不同伺服器，並用 Wireshark 觀察回應的 IP 數量與內容，以評估服務品質。
			[[檔案:2026-0317-03.png\|800px]]

Kuyohong：/* DNS封包結構與重要欄位 */

2026-03-17T02:51:31Z

DNS封包結構與重要欄位

←上個修訂		於 2026年3月17日 (二) 02:51 的修訂
行 195：		行 195：
	** TTL（Time To Live）：以秒為單位（例：5、300、600、900、1800）。表示快取期限，於期限內重複查詢同名時不再向DNS詢問。		** TTL（Time To Live）：以秒為單位（例：5、300、600、900、1800）。表示快取期限，於期限內重複查詢同名時不再向DNS詢問。
	** TTL的策略用途：		** TTL的策略用途：
	** 若伺服器欲節省頻寬、避免頻繁查詢，可將TTL設大（如900、1800）。		** 若伺服器欲節省頻寬、避免頻繁查詢，可將TTL設大（如900、1800）。
	** 若重視資安、防止被洗IP，TTL可設很小（如5），使用戶端立即忘記並再次查詢。		** 若重視資安、防止被洗IP，TTL可設很小（如5），使用戶端立即忘記並再次查詢。
	** 大型內容服務（例：YouTube）為做流量分配與負載平衡，常將TTL調低，依每次查詢動態導向不同地區（美國、日本、德國、韓國）的伺服器。		** 大型內容服務（例：YouTube）為做流量分配與負載平衡，常將TTL調低，依每次查詢動態導向不同地區（美國、日本、德國、韓國）的伺服器。
	** RDLENGTH（RD length）：回覆資料長度，例如IPv4為4 bytes。		** RDLENGTH（RD length）：回覆資料長度，例如IPv4為4 bytes。
	** RDATA（RD data）：實際答案內容，依RDLENGTH變動，A記錄則為IPv4位址。		** RDATA（RD data）：實際答案內容，依RDLENGTH變動，A記錄則為IPv4位址。

	=== 網頁載入與大量封包的關聯 ===		=== 網頁載入與大量封包的關聯 ===
	* 網頁資源與封包數量		* 網頁資源與封包數量

Kuyohong：/* VLAN 與交換器連接埠模式 */

2026-03-17T02:50:27Z

VLAN 與交換器連接埠模式

←上個修訂		於 2026年3月17日 (二) 02:50 的修訂
行 139：		行 139：
	** Hybrid Port: 混合模式，兼具 Access 與 Trunk 特性，可處理帶標籤與不帶標籤的封包，並依設定決定處理方式。若電腦連到設為 Hybrid 的埠，可能會收到帶 VLAN 標籤的封包。		** Hybrid Port: 混合模式，兼具 Access 與 Trunk 特性，可處理帶標籤與不帶標籤的封包，並依設定決定處理方式。若電腦連到設為 Hybrid 的埠，可能會收到帶 VLAN 標籤的封包。
	[[檔案:2026-0317-01.png\|800px]]		[[檔案:2026-0317-01.png\|800px]]
			== DNS ==
			聚焦DNS（Domain Name System／Service）在UDP上的運作，涵蓋DNS查詢流程、UDP與TCP比較、DNS封包與欄位（Header、Question、Answer）、TTL與快取行為，以及DNS在TCP 53於主從（MASTER/SLAVE）備援的用途；並透過WireShark與ping進行實作抓包與過濾。<br><br>
			講師以 www.wirehack.org 為例，說明網址相較IP的記憶性差異、瀏覽器載入頁面會觸發多筆DNS查詢的情境，以及為何即時性應用與DNS多採UDP以提升效率。後段進行實作：清快取、抓取DNS與ICMP封包、設定過濾與檢視欄位，並提示可能觀察到ARP。課程亦預告進階課程將展示DNS遞迴與權威查詢的更深入風暴，且資安課會示範利用DNS查詢類型進行攻防的案例。
			重點知識點
			=== DNS概念與用途 ===
			* 網址與IP的對應
			** DNS將「有意義的名稱（網址）」映射為「沒有意義但實用的數字（IP位置）」，讓使用者以易記名稱上網，實際連線仍用IP。
			** 範例網址：水果大學 wirehack.org；講師以記憶對比說明「104251.6」等數字難以長期記憶。
			* DNS縮寫與稱呼
			** DNS可解作Domain Name System，亦有人稱Domain Name Service；講師表示稱呼並非重點。
			* DNS的運作層與埠號
			** DNS以UDP為主，目的埠為53（UDP 53）；一般使用者查詢多為UDP。
			** DNS亦設計TCP 53確保資料完整性，典型用於兩台DNS伺服器之間的備援與資料同步（MASTER/SLAVE架構，SLAVE向MASTER取資料時用TCP 53）。
			** 實作情境中，若抓到兩台Windows Server做DNS備援，可見TCP 53風暴；本次課程重點在UDP 53。
			=== DNS查詢流程與網路封裝 ===
			* 基本查詢步驟與封包流向
			** 使用者在命令列執行ping某網址（例：wireshark.org），電腦辨識其為「網址」而非IP，需發送DNS查詢封包。
			** 查詢流程：主機以UDP送至目的Port 53的設定DNS伺服器（例如中華電信的DNS）。若本機無法直接到達，Layer2目的MAC設為Gateway，由具路由功能的Gateway轉往外網，最終抵達DNS伺服器。
			** DNS伺服器可能回應「知道」或「不知道」。不知道時可向其他DNS查詢（遞迴或轉送）。本課僅觀察用戶端至ISP DNS的風暴；進階課程將展示DNS之間的風暴。
			** 回覆抵達後由Gateway轉交給用戶端；用戶端獲得IP後，ping（ICMP）以該IP通訊，預期產生雙向各5個ICMP封包（「必須兩次等於十次」係指雙向回應的往返）。
			* 封裝層次
			** 以太網路（Ethernet）為最底層；其Data承載IP。
			** IP的Data承載UDP。
			** UDP的Data承載DNS。
			** 本課聚焦UDP與DNS層，Ethernet、IP已略過。
			=== UDP機制、優缺點與與TCP的比較 ===
			* UDP欄位與特性
			** UDP標頭簡單：來源Port、目的Port、Length（整體封包長度）、Checksum，以及Data。
			** 查詢時目的Port填53；來源Port為1024以上的隨機Port，各主機不同。
			* UDP缺點與資料完整性問題
			** 範例「HELLO」分成5個封包（H/E/L/L/O）。若其中一個子封包Checksum不通過被丟棄，上層應用不會知道遺失（Transport層丟棄未通知上層），收到可能變成「HELO」，導致壓縮檔解不開、圖片壞掉等。
			** 若需完整性，應用端需自行偵測與重傳設計，或改用TCP。
			* UDP優點與效率原因
			** 標頭欄位少、驗證少，傳輸效率高。
			** 在Ethernet MTU 1500下：IP約20 bytes；TCP最小20 bytes（可因Options增加），相較之下UDP負擔更小，使Data可承載更多有效載荷。
			** 網速不變時，有效資料承載越多傳輸越快；例子指出BT（BitTorrent）傳輸使用UDP常讓人感覺更快。
			* 為何DNS與即時性應用用UDP
			** DNS若走TCP需三次握手與結束流程，查詢變慢；UDP避免握手，回應更即時。
			** 網路電話／即時影音需連續播放，即使遺失部分資料也可容忍；TCP逐包確認會造成播放不連續。
			=== DNS封包結構與重要欄位 ===
			* DNS Header重點
			** Transaction ID（交易ID）：客戶端隨機指定（類似UID），伺服端回覆以相同ID配對。大量並行DNS查詢（如載入含多張圖片的網頁）時，ID用於快速配對請求與回覆。
			** QR：指出封包為查詢或回覆。
			** Flags與Opcode等中間欄位：一般多為固定值或0，常見為「standard query」。
			** Question Count（問題數）：一次查詢可含多個問題，數值以二進制表示。
			** Answer Count（答案數）：回覆的資源記錄數量，例如1或4個IPv4位址。
			** Authority（權威）與Additional（附加）計數：現代用戶端場景常不需使用；講師以「104查號台」比喻Additional提供「若不信可再詢問」的附加資料，稱現今多已不用（歷史上曾用）。
			* Question區段
			** Question Name：欲查詢的名稱（網址）。名稱可長可短，DNS名稱在封包中以標籤長度機制編碼（講師以斜線提示有機制可壓縮／可變長，細節於後續課程）。
			** Question Type：查詢類型（如A代表IPv4，AAAA代表IPv6）。講師提到其編號，並於資安課將示範更多超乎想像的查詢用途與攻防。
			** Question Class：通常為IN（Internet，值為1），歷史上規劃多類，現今普遍只用IN。
			* Answer區段
			** Name：回覆中再次附送問題名稱。
			** Type／Class：分別指出記錄類型（如A／AAAA）與類別（IN=1）。
			** TTL（Time To Live）：以秒為單位（例：5、300、600、900、1800）。表示快取期限，於期限內重複查詢同名時不再向DNS詢問。
			** TTL的策略用途：
			** 若伺服器欲節省頻寬、避免頻繁查詢，可將TTL設大（如900、1800）。
			** 若重視資安、防止被洗IP，TTL可設很小（如5），使用戶端立即忘記並再次查詢。
			** 大型內容服務（例：YouTube）為做流量分配與負載平衡，常將TTL調低，依每次查詢動態導向不同地區（美國、日本、德國、韓國）的伺服器。
			** RDLENGTH（RD length）：回覆資料長度，例如IPv4為4 bytes。
			** RDATA（RD data）：實際答案內容，依RDLENGTH變動，A記錄則為IPv4位址。
			=== 網頁載入與大量封包的關聯 ===
			* 網頁資源與封包數量
			** 載入首頁流程：先下載index.html，再依內含連結（通常為網址而非IP）請求圖片、影音、廣告等資源。
			** 每張圖片前可能先DNS查詢，再TCP三次握手、HTTP請求、ACK往返、資料分段與ACK，單一圖片即可能產生十幾個封包；多張圖片與影音資源可累積至數百甚至上千封包。
			** 教學以ping與簡單DNS查詢示範，避免新手被大量封包干擾理解。
			=== 實作與觀察（WireShark + ping）===
			* 前置檢查與清快取
			** 以圖形化介面或命令列查看本機DNS伺服器（Windows: ipconfig /all 或類似；講義提到「iafconfig、ipconfig /o」為口誤或簡寫，重點在確認DNS設定）。
			** 執行ipconfig /flushdns，顯示「成功清除DNS的快取」，避免快取影響觀測。
			* 抓包與過濾
			** 開啟WireShark，同步在命令列ping「WireShark.org」（講師口語亦稱wirehack.org，皆為示例目標；可替換其他網站）。
			** 停止抓取後設定過濾條件（Filter由學員自行研究，講師稍後提供指引）。
			** 預期封包序列：前兩個為DNS（查詢與回覆），接著約八個ICMP（ping的往返），最後可能再有兩個DNS（情境變化）；若出現ARP，多為本機向Gateway詢問MAC位址。
			** 觀察：DNS回覆之IP可能變動屬正常，尤其在低TTL與負載平衡策略下。
			=== 進階課程預告與資安提示 ===
			* 進階DNS風暴觀察
			** 本課只看用戶端到ISP DNS的風暴；後續課程將演示DNS間的遞迴／權威查詢風暴，包含若本機能加入特定節點時可見更完整流程。
			[[檔案:2026-0317-02.png\|800px]]

Kuyohong：/* 課後練習與課程預告 */

2026-03-17T01:42:27Z

課後練習與課程預告

←上個修訂		於 2026年3月17日 (二) 01:42 的修訂
行 112：		行 112：
	4. ping 本機迴環位址 127.0.0.1。		4. ping 本機迴環位址 127.0.0.1。
	[[檔案:2026-0316-07.png\|800px]]		[[檔案:2026-0316-07.png\|800px]]
			=== 網路連線測試與封包分析 ===
			* Ping 同網段不存在的 IP
			** 行為: 對同一網段內不存在的 IP 執行 ping 時，作業系統會先檢查 ARP 快取是否有該 IP 對應的 MAC 位址。
			** 封包: 找不到 MAC 位址時，系統會發送 ARP 廣播請求，詢問「誰是 [目標IP]？請告訴 [來源IP]」。
			** 結果: 由於目標主機不存在，無任何設備回應 ARP 請求。Windows 10/11 預設會嘗試發送三次 ARP 請求，三次皆失敗後回報「目的地主機無法連線」(Destination host unreachable)。
			** 封包特徵: 在此情境下，Wireshark 會看到大量 ARP 廣播，而不會看到 ICMP (ping) 封包，因為在無法解析 MAC 位址階段就已失敗。
			** 系統差異: 舊版系統（如 Windows 7）可能只發送一次 ARP 即回報失敗，因此 ARP 封包數較少，顯示不同作業系統對 ARP 重試次數的實作差異。
			* Ping 不同網段不存在的 IP
			** 行為: 針對不在同一網段的 IP（外網 IP）執行 ping 時，作業系統會判定需透過預設閘道 (Gateway) 轉發。
			** 封包: 系統會將 ICMP 請求封包發送給閘道。乙太網路層的目標 MAC 為閘道的 MAC，而 IP 層的目標 IP 仍是實際想 ping 的外網 IP。
			** 結果: 封包送至閘道，但最終目標不存在，閘道無法送達，最終導致逾時。Windows 11 顯示「要求等候逾時」(Request timed out)。
			** 關鍵差異: 此過程不會嘗試對外網 IP 發送 ARP，因為通訊是透過閘道進行。需理解乙太網路層與 IP 層目的地可能不同：前者是閘道，後者是最終目標，這常被初學者混淆。
			* Ping 本機 IP 與 Loopback Address
			** 行為: ping 自己的 IP（如 192.168.2.86）或環回地址 (127.0.0.1) 時，皆屬本機內部作業。
			** 封包傳輸: 這些通訊不會經過實體網路卡 (NIC)，而是在作業系統核心內部處理後直接回應。ping 自己的 IP 透過實體網卡配置的 IP 進行，ping 127.0.0.1 則透過作業系統的虛擬環回介面 (Loopback Interface)。
			** Wireshark 擷取問題: 若 Wireshark 僅監聽實體網路卡，將無法擷取任何封包，因為流量未通過該網卡。
			** 解決方案: 需在 Wireshark 選擇 Adapter for Loopback Capture 虛擬介面監聽。這是 Npcap 的功能（WinPcap 不支援），可捕捉發往本機的流量。但因來源與目的 IP 皆為本機，方向性較難直觀辨識。
			=== VLAN 與交換器連接埠模式 ===
			* 802.1Q 封包的出現
			** 情境: 在同學間互相 ping 的封包中，可能看到帶有 802.1Q VLAN 標籤，即使電腦自身未設定 VLAN。
			** 原因: 通常是因為電腦連接的交換器 (Switch) 連接埠設定為 Trunk Port 或 Hybrid Port。
			** 電腦處理: 一般個人電腦作業系統預設不識別 802.1Q 標籤，收到此類封包會直接丟棄。但 Wireshark 能識別並解讀標籤，因此可在 Wireshark 中看到 VLAN 資訊。
			* 交換器連接埠模式
			** Access Port: 連接終端設備（電腦、印表機）的普通乙太網路埠，處理不帶 VLAN 標籤的流量。
			** Trunk Port: 用於交換器之間傳輸多個 VLAN 的流量，封包經過時會加上 802.1Q VLAN 標籤以區分所屬 VLAN。
			** Hybrid Port: 混合模式，兼具 Access 與 Trunk 特性，可處理帶標籤與不帶標籤的封包，並依設定決定處理方式。若電腦連到設為 Hybrid 的埠，可能會收到帶 VLAN 標籤的封包。
			[[檔案:2026-0317-01.png\|800px]]

Kuyohong：/* 實務診斷與應對 */

2026-03-16T09:12:39Z

實務診斷與應對

←上個修訂		於 2026年3月16日 (一) 09:12 的修訂
行 54：		行 54：
	* 建立心中預期與實測比對：觀察 ms、TTL、封包數量與內容，推論壅塞、速度、路由行為、封包遺失，避免被過度簡化結論誤導。		* 建立心中預期與實測比對：觀察 ms、TTL、封包數量與內容，推論壅塞、速度、路由行為、封包遺失，避免被過度簡化結論誤導。
	[[檔案:2026-0316-06.png\|800px]]		[[檔案:2026-0316-06.png\|800px]]
			=== 網路封包過濾技巧 ===
			* 過濾器的基本使用與常見問題
			** 初學者常以 ip.addr 過濾特定 IP（如 ip.addr == 192.168.2.9）。
			** 此法僅能篩選具 IP 層的封包（如 ICMP），會遺漏不含 IP 層的封包（如 ARP），因 ARP 本身沒有 IP 層結構，ip.addr 對其無效。
			* ARP 專用過濾方式
			** 可用 arp. 前綴的過濾器，針對發送者或目標 IP 過濾。
			** 因 ARP 請求與回應中發送者/目標角色互換，需兩條規則才能完整捕捉一次 ARP 交換，再加上 ICMP 的規則，合計三條，較為繁瑣。
			* 高效整合過濾策略
			** 分析 ping 涉及四種封包：ARP 請求（廣播）、ARP 回應（單播）、ICMP 請求（送出）、ICMP 回應（收到）。
			** 共同點：皆與本機的 MAC 位址相關。
			** 精簡條件式：eth.addr == [我的MAC位址] and (arp or icmp)。
			** eth.addr == [我的MAC位址] 確保來源或目的地 MAC 為本機。
			** (arp or icmp) 將結果限定為 ARP 與 ICMP，排除 HTTP、DNS 等無關流量。
			** 只需一條指令，即可清楚、完整捕捉 ping 相關封包。
			=== ARP 協定運作詳解 ===
			* ARP 請求（Request）流程
			** 觸發時機：主機需與同網段目標通信，僅知其 IP、未知其 MAC 時發起 ARP 請求。
			** 封包結構（Ethernet 層）：
			** 目的位址：FF:FF:FF:FF:FF:FF（廣播），使同網段所有設備可接收。
			** 來源位址：發起主機 MAC。
			** 類型（Type）：0x0806（ARP）。
			** 封包結構（ARP 層）：
			** 硬體類型：Ethernet (1)。
			** 協定類型：0x0800（IPv4）。
			** 操作碼（Opcode）：1（request）。
			** 發送者 MAC/IP：發起主機的 MAC 與 IP。
			** 目標 MAC 位址：未知，以 00:00:00:00:00:00 填入。
			** 目標 IP 位址：欲查詢的目標 IP。
			** 傳送方式：以廣播形式送至網段內所有設備。
			* ARP 回應（Reply）流程
			** 觸發時機：收到 ARP 請求的設備檢查目標 IP 是否為自身；匹配者才回應。
			** 封包結構（Ethernet 層）：
			** 目的位址：原請求方 MAC（由請求封包取得）。
			** 來源位址：回應主機 MAC。
			** 封包結構（ARP 層）：
			** 操作碼（Opcode）：2（reply）。
			** 發送者 MAC/IP：回應主機之 MAC 與 IP。
			** 目標 MAC/IP：原請求方之 MAC 與 IP。
			** 傳送方式：以單播（unicast）直接送回請求方。
			* ARP 完成後的影響
			** 請求方收到 ARP 回應後取得目標 IP 對應之 MAC。
			** 後續封包（如 ICMP ping 請求）在 Ethernet 標頭填入該 MAC，完成通信。
			** 若 ARP 無回應，因未知目的 MAC，ICMP 封包無法送出。
			=== 網路問題判斷 ===
			* 不同網段的行為
			** 目標位於不同網段時，主機不會對目標 IP 發起 ARP。
			** 取而代之，主機將封包送往預設閘道（Gateway），故抓包中不會看到針對目標 IP 的 ARP。
			* ARP 失敗的可能原因
			** 若送出 ARP 請求（封包 1）而無回應（封包 2），表示目標未回應。
			** 可能原因之一：發送方認為目標在同網段，但目標主機因網路設定錯誤，認定與發送方不同網段而不回應。
			=== 課後練習與課程預告 ===
			* 課後練習
			** 四項練習以實際抓包驗證理論：
			1. ping 同網段但「不存在」的主機 IP（例：192.168.2.x）。
			2. ping 「不存在」且「不同網段」的主機 IP（例：192.168.222.222）。
			3. ping 主機自己的 IP（例：192.168.2.86）。
			4. ping 本機迴環位址 127.0.0.1。
			[[檔案:2026-0316-07.png\|800px]]

Kuyohong：建立內容為「==PING == 本次課程以 Ping 與 ICMP 進行網路診斷為主軸，結合 Wireshark 實作從 frame、Ethernet、IPv4 到 ICMP 與 data 的逐層解析，並…」的新頁面

2026-03-16T08:27:51Z

建立內容為「==PING == 本次課程以 Ping 與 ICMP 進行網路診斷為主軸，結合 Wireshark 實作從 frame、Ethernet、IPv4 到 ICMP 與 data 的逐層解析，並…」的新頁面

新頁面

==PING ==
本次課程以 Ping 與 ICMP 進行網路診斷為主軸，結合 Wireshark 實作從 frame、Ethernet、IPv4 到 ICMP 與 data 的逐層解析，並延伸觀察 ARP 在區域網路中的角色與觸發時機。內容涵蓋封包生成與回覆流程、回應時間（ms）與 TTL 的意義與推論、Ethernet Frame、IP Header、ICMP Header 的欄位細節與作用、不同作業系統（Windows、macOS、Linux）在 Ping 指令與行為上的差異、Wireshark 的介面與分析功能（時間戳、介面識別、顏色規則、標記/忽略、Bytes/ASCII 顯示、Time Shift），以及使用 ARP 查表與清表、Windows 防火牆設定以啟用 ICMPv4 回覆的實務流程。<br><br>課程安排完整練習：查詢 Gateway、設定指令、啟動 Wireshark 擷取、執行 Ping（示例四次往返共八個封包）、停止並分析，並在 LAN 情境中以清除 ARP 快取後的 Ping 驗證兩則 ARP（廣播與回覆）的預期行為，確保學員將實務診斷與協定層細節連結。
=== Ping 與 ICMP 的基礎概念與用途 ===
* Ping 作為基本診斷工具
** 使用 ICMP Echo Request（Type=8）與 Echo Reply（Type=0）進行「我問你、你回我」的互動模型。
** 典型診斷目標：自身 IP、Gateway、他人/服務主機。不同目標代表不同層面的檢查（本機堆疊、到閘道連通性、端到端可達性）。
* ICMP 類型與回應
** Type/Code 可辨識回覆與錯誤；TTL 歸零時路由器可能回傳 ICMP Destination Unreachable 等訊息。
* 回應時間與 TTL 的意義
** ms 延遲由作業系統記錄（非封包欄位）。TTL 每經過一個路由器扣 1，至 0 丟棄；可用回覆 TTL 推論跳數、作業系統預設 TTL與拓樸鄰近性。
** 以延遲與 TTL 共同推論壅塞、線路/路由問題。
* 作業系統差異
** Windows 的 Ping 參數以「/？」查詢，常見 -t、-a；預設執行固定次數。macOS/Linux 預設持續執行，需 Ctrl+C 停止。不同系統的 ICMP Data 內容可能不同（如 Windows 常見「ABCDEFG」）。
=== Wireshark 基本視圖、顏色規則與協定堆疊 ===
* 詳細視圖與 Bytes 對應：點選 ICMP、IP、Ethernet、frame 層可在右側 Hex/Bytes 對應框選各層範圍，協助核對欄位與長度（如 Total Length）。
* frame 層欄位與時間顯示：Interface ID、Encapsulation Type、Arrival Time/UTC/Epoch、捕獲序號與大小；可使用 Time Shift 調整顯示位移（一般分析少用）。
* 封包標記與忽略：Marked/Ignored 便於聚焦分析。
* Coloring Rules：預設顏色代表社群慣用語義（如 TCP RST、ICMP 等），建議不修改；可在 View > Coloring Rules 檢視與新增自訂規則。
* 協定堆疊：Ethernet > IP > ICMP > Data；ASCII 顯示更清楚呈現載荷。
=== 乙太網路（Ethernet）Frame 結構與 MAC 辨識 ===
* Ethernet II（DIX 2.0）：preamble、SFD、目的/來源 MAC（6 bytes）、Type（0x0800 表 IPv4）、FCS。IEEE 802.3 將 Type 改為 Length，實務多採 Ethernet II。
* Wireshark 可顯示 MAC 前 3 碼（OUI）對應廠商，以快速辨識設備類型。
=== IPv4 Header 詳解與驗證 ===
* Version=4；IHL 常見 20 bytes（無 Options）。
* DS（DiffServ）多由中間設備設定，端主機通常為 0。
* Total Length：包含 Header 與 Data；可於 Bytes 視圖核對實際長度（示例 60 bytes）。
* Identification：封包生成順序遞增；分片時所有分片共享相同 Identification。
* Flags/Fragment Offset：指示分片狀態與位移。
* TTL：每過路由器扣 1；回覆封包若 TTL 未扣減（例如 255），可推論對端在同一子網/鄰近位置。
* Protocol：ICMP=1。
* Header Checksum：可在偏好設定逐協定啟用驗證；過度啟用可能影響效能。
=== ICMP Header 與 Data 內容 ===
* Type/Code：Echo Request=8/0，Echo Reply=0。
* Checksum、Identifier、Sequence Number：用於配對 request/reply 與統計次序。
* Data：各平台填入內容可能不同；多數設備會原樣回覆請求的 data。可據 ASCII 顯示比對確認往返關聯與設備處理策略。
=== ARP 在區域網路中的角色與觸發 ===
* 位址與網段判定：主機以自身子網遮罩計算並比較目標是否同網段。
** 同網段：需取得目標 MAC；未知時發送 ARP Request（EtherType=0x0806，Operation=1），收到 ARP Reply（Operation=2）後以該 MAC 封裝傳送。
** 不同網段：封包送至 Gateway；可能詢問/使用 Gateway 的 MAC。
* ARP 欄位：Hardware Type（Ethernet）、Protocol Type（IPv4）、HLEN=6、PLEN=4、Sender/Target 硬體/協定位址、Operation。
* 觸發條件：同網段且未知對方 MAC；若 ARP 快取已存在則不再發送。
=== Windows 實務操作：ARP/ICMP與防火牆 ===
* ARP 快取：arp -a 檢視；以系統管理員執行 arp -d * 清空以強制觀察 ARP。
* Ping 與擷取預期：清表後 Ping 預期看到兩則 ARP（廣播與回覆）；即便 Windows 某些版本不回覆 ICMP Echo，ARP 互動仍可見。
* 防火牆策略（被 Ping 端）：首選啟用 ICMPv4 入站規則（進階防火牆 → 入站規則 → 允許 ICMPv4 Echo），不建議全面關閉防火牆；測試後恢復原設定。
* 介面與組態：私人/公用網路為不同組態檔；版本差異可能影響導覽位置。
=== 封包流程、數量預期與多介面捕獲 ===
* 封包往返：本機發送 Echo Request，對端回 Echo Reply；本機計算往返延遲（例 3–4 ms）。
* 封包數量預期：執行 4 次 Ping，理論擷取到 8 個封包（4 出、4 回）；若少於預期需調查遺失或過濾原因。
* 多介面捕獲：在 Capture 設定按住 Ctrl 可同時選取多張網卡，觀察 Interface ID 與來源差異；無法在擷取頁面直接加選。
* 過濾與視野管理：Display Filter 精準篩選，必要時以 Ignored 暫時隱藏不相干封包。
=== 實務診斷與應對 ===
* 外包/客服常以簡單 Ping 判定並更換設備；若能提供更深入路由證據，較可能獲得專業處理。
* 建立心中預期與實測比對：觀察 ms、TTL、封包數量與內容，推論壅塞、速度、路由行為、封包遺失，避免被過度簡化結論誤導。
[[檔案:2026-0316-06.png|800px]]

緯育 2026-0314.2 - 修訂歷史

Kuyohong：​/* 實作與觀察（WireShark + ping） */

Kuyohong：​/* 中國網路封鎖與VPN管理 */

Kuyohong：​/* 中國網路封鎖與VPN管理 */

Kuyohong：​/* DNS 伺服器的選擇與影響 */

Kuyohong：​/* 進階課程預告與資安提示 */

Kuyohong：​/* DNS封包結構與重要欄位 */

Kuyohong：​/* VLAN 與交換器連接埠模式 */

Kuyohong：​/* 課後練習與課程預告 */

Kuyohong：​/* 實務診斷與應對 */

Kuyohong：​建立內容為「==PING == 本次課程以 Ping 與 ICMP 進行網路診斷為主軸，結合 Wireshark 實作從 frame、Ethernet、IPv4 到 ICMP 與 data 的逐層解析，並…」的新頁面

Kuyohong：/* 實作與觀察（WireShark + ping） */

Kuyohong：/* 中國網路封鎖與VPN管理 */

Kuyohong：/* 中國網路封鎖與VPN管理 */

Kuyohong：/* DNS 伺服器的選擇與影響 */

Kuyohong：/* 進階課程預告與資安提示 */

Kuyohong：/* DNS封包結構與重要欄位 */

Kuyohong：/* VLAN 與交換器連接埠模式 */

Kuyohong：/* 課後練習與課程預告 */

Kuyohong：/* 實務診斷與應對 */

Kuyohong：建立內容為「==PING == 本次課程以 Ping 與 ICMP 進行網路診斷為主軸，結合 Wireshark 實作從 frame、Ethernet、IPv4 到 ICMP 與 data 的逐層解析，並…」的新頁面