「印表機可以連，但網站完全打不開。」
這種情況很容易讓人困惑。
既然電腦能連到網路印表機，代表網路線、Switch 和 IP 應該都正常；但為什麼連外部網站，甚至其他 VLAN 的 Server 都失敗？
打開網路設定後，可能會發現：
IP Address：10.10.20.35
Subnet Mask：255.255.255.0
Default Gateway：
IP 有了，Subnet Mask 也有了，唯獨 Default Gateway 是空白。
這台電腦不是完全沒網路。
它只是不知道該從哪裡離開自己的網段。
有點像你能在社區裡自由走動，也找得到隔壁鄰居，但社區唯一的大門消失了。想去外縣市是不太可能，可能連超商都到不了。
Default Gateway 可以翻譯為「預設閘道」。
當 Client 要將封包送往不同網段時，會先交給 Default Gateway，再由它決定下一步往哪裡轉送。
企業環境裡，Gateway 可能位於：
例如 Client 位於：
IP Address：10.10.20.35
Subnet Mask：255.255.255.0
Default Gateway：10.10.20.1
它要連到：
10.10.50.10
Client 會先判斷目的地是否與自己位於同一網段。
由於：
10.10.20.35/24
和：
10.10.50.10/24
不在同一個 /24 網段，因此 Client 不會直接尋找 Server 的 MAC，而是將封包交給：
10.10.20.1
再由 Gateway 根據自己的 Routing Table 決定後續路徑。
Client 會使用：
進行判斷。
假設：
Client IP：10.10.20.35
Mask：255.255.255.0
也就是：
10.10.20.35/24
它所屬的網路為：
10.10.20.0/24
可用主機範圍大致是：
10.10.20.1 ～ 10.10.20.254
如果目的地是：
10.10.20.50
Client 判斷它在同網段。
如果目的地是：
10.10.50.10
Client 判斷它在不同網段，需要交給 Gateway。
這個判斷是在 Client 本機完成，不需要先詢問 Router。
假設：
Client A：10.10.20.35/24
Client B：10.10.20.50/24
兩者位於同一網段。
Client A 要傳送封包給 Client B 時，需要知道 Client B 的 MAC Address。
因此會發送 ARP Request：
誰是
10.10.20.50？請告訴10.10.20.35。
Client B 回覆自己的 MAC Address 後，Client A 就可以建立 Ethernet Frame：
Source MAC：Client A
Destination MAC：Client B
Switch 再根據 MAC Address Table 將 Frame 轉送到 Client B 所在的 Port。
這段通訊不需要經過 Default Gateway。
所以即使 Gateway 空白或錯誤，同網段設備仍可能互通。
這就是為什麼使用者可以列印同網段印表機，卻連不到外部網站。
假設 Client A 要連：
Server：10.10.50.10
Client 判斷 Server 不在本地網段，因此會尋找 Default Gateway：
10.10.20.1
這時 Client 不需要知道 Server 的 MAC Address。
它需要的是 Gateway 的 MAC。
因此會 ARP：
誰是
10.10.20.1？
取得 Gateway MAC 後，Client 建立的第一段 Frame 可能是：
Source MAC：Client A
Destination MAC：Gateway
但 IP Packet 仍是：
Source IP：10.10.20.35
Destination IP：10.10.50.10
這裡是很重要的觀念：
每經過一個 Router，Layer 2 的 MAC Header 會重新建立，但來源與目的 IP 通常仍維持原本的端點。
除非途中發生 NAT，IP 才可能被修改。
Gateway 收到 Frame 後，拆除 Layer 2 Header、查看目的 IP，再根據 Routing Table 將封包送往下一跳。
Client 必須能在 Layer 2 上直接找到 Default Gateway。
因此一般情況下，Gateway IP 必須位於 Client 所屬網段。
例如 Client 是：
10.10.20.35/24
合理的 Gateway 可能是：
10.10.20.1
如果誤填為：
10.10.50.1
Client 會判斷這個 Gateway 本身就在遠端網段。
問題來了：
要到遠端網段需要先找 Gateway，但 Gateway 自己也在遠端。
這就像導航告訴你：「要離開社區，請先到隔壁縣市的大門。」邏輯有點循環，而且非常不實用。
假設 Client 正確設定應為：
IP：10.10.20.35
Mask：255.255.255.0
Gateway：10.10.20.1
但 Mask 被誤設成：
255.255.0.0
也就是 /16。
此時 Client 會認為：
10.10.0.0 ～ 10.10.255.255
都在同一個本地網段。
當它要連：
10.10.50.10
本來應該交給 Gateway，卻會誤以為 Server 就在同一個 Layer 2 網路，直接發送 ARP：
誰是
10.10.50.10？
但 VLAN 20 裡不會有 VLAN 50 的 Server 回覆。
Client 會持續等待，最後連線失敗。
這種情況很容易誤判成：
實際上封包根本沒有被交給 Gateway。
所以排錯不能只看 IP 和 Gateway，也要一起確認 Subnet Mask。
Windows 可以查看 ARP Table：
arp -a
Linux 可使用：
ip neigh
正常情況下，可以看到 Gateway 的 IP 與 MAC 對應：
10.10.20.1 aa-bb-cc-dd-ee-ff dynamic
若 Gateway 無法解析，可能顯示為：
可能原因包括：
如果 Client 能取得正確 DHCP 設定，卻無法解析 Gateway MAC，就應先查本地 VLAN 與 Gateway Interface，而不是立刻研究 Internet。
排錯時，常見的第一個測試是：
ping 10.10.20.1
如果成功，通常能初步證明：
但仍不能證明：
如果 Ping Gateway 失敗，也不一定代表 Gateway 不存在。
有些設備可能限制 ICMP。
因此還可以搭配：
不要讓單一 Ping 承擔它證明不了的事情。
Routing Table 是系統用來決定封包出口的路由表。
Windows 可以查看：
route print
PowerShell 也可以使用：
Get-NetRoute
Linux 常用：
ip route
可能看到：
10.10.20.0/24 dev eth0
default via 10.10.20.1 dev eth0
代表：
10.10.20.0/24 的流量直接從 eth0 送出10.10.20.1
Windows 的預設路由通常顯示為：
0.0.0.0 0.0.0.0 10.10.20.1
0.0.0.0/0 代表涵蓋所有 IPv4 目的地。
但它只有在 Routing Table 找不到更精確路由時才會使用。
當 Routing Table 中有多條路由符合目的地時，系統會優先選擇最精確的路由。
這叫：
Longest Prefix Match
例如：
10.10.0.0/16 via Gateway A
10.10.50.0/24 via Gateway B
0.0.0.0/0 via Gateway C
目的地是：
10.10.50.10
三條路由都能匹配，但 /24 比 /16 和 /0 更精確，因此會選：
10.10.50.0/24 via Gateway B
不是看到 Default Gateway 就一定走 Default Gateway。
預設路由比較像最後的兜底選項：
如果沒有任何更明確的路，就走這裡。
如果存在多條相同 Prefix Length 的路由，系統可能根據 Metric 選擇優先路徑。
一般來說：
Metric 越小，優先級越高。
例如：
0.0.0.0/0 via 10.10.20.1 metric 10
0.0.0.0/0 via 192.168.1.1 metric 50
通常會優先走：
10.10.20.1
Metric 可能由：
決定。
多網卡環境中，錯誤 Metric 很容易讓封包走錯出口。
假設一台 Linux 或 Windows 主機有兩張網卡：
NIC 1：10.10.130.20/24
Gateway：10.10.130.1
NIC 2：10.10.50.20/24
Gateway：10.10.50.1
兩張網卡都設定 Default Gateway，系統便出現兩條預設路由。
結果可能包括：
一般較清楚的設計是：
例如：
default via 10.10.130.1
10.10.50.0/24 dev NIC2
表示：
這比讓兩個 Gateway 在 Routing Table 裡競爭工作更容易預測。
雙網卡的完整案例會在後續 Linux 文章繼續討論。
多網卡主機可能遇到一種現象：
USB NIC 啟用時，某個網段無法 Ping；把 USB NIC Down 掉，反而恢復正常。
這通常不是 USB NIC 對 Ping 有私人恩怨，而是它改變了路由選擇。
啟用 USB NIC 後，可能新增：
當 USB NIC 關閉，那條錯誤路由消失，封包才回到原本正確出口。
遇到這種情況，重點不是把 USB NIC 永久關掉，而是比較它啟用前後的 Routing Table。
Windows 可以在前後分別執行：
route print
Linux 則可以比較：
ip route
ip rule
找出新增或優先順序改變的路由。
Windows：
tracert 8.8.8.8
Linux：
traceroute 8.8.8.8
如果結果停在第一跳前：
1 Request timed out
可能方向包括：
如果第一跳成功，後續失敗：
1 10.10.20.1
2 10.10.1.254
3 Request timed out
問題可能位於：
仍要注意，Traceroute 出現星號不代表那一跳必定故障。
有些設備只轉送封包，卻不願意回覆探測。
如果後續節點仍然出現，就代表封包其實有經過它。
網路連線通常需要雙向通訊。
Client 到 Server 的去程可能為：
Client
→ Gateway A
→ Firewall
→ Server
但 Server 的回程可能因 Routing Table 錯誤而走：
Server
→ Gateway B
→ 另一台 Firewall
→ 丟失
這稱為：
症狀可能是：
因此，排錯時不要只問：
Client 知不知道怎麼去？
還要問：
Server 知不知道怎麼回來？
網路連線不是單程告白，去程很努力沒有用，回程還是得給個回應。
對一般 Client 來說，Default Gateway 通常用來建立預設路由。
例如：
Default Gateway：10.10.20.1
系統便建立：
0.0.0.0/0 via 10.10.20.1
但 Router、Server 或多網卡主機可能有更複雜的 Routing Table。
它們可以：
因此，排錯時最可靠的是查看實際 Routing Table，而不是只看 GUI 裡的 Default Gateway 欄位。
Client 的 Gateway 通常由 DHCP Option 3 提供。
如果 Scope 設定錯誤，可能讓整個 VLAN 的 Client 都取得錯誤 Gateway。
例如正確值應為：
10.10.20.1
DHCP 卻發成：
10.10.20.254
結果可能是：
這種新舊 Client 表現不同的情況，很容易讓事件看起來不規律。
排錯時應比較：
如果問題從某次 DHCP 調整後開始，線索就更明顯。
假設正式 Gateway 是：
10.10.20.1
但另一台設備被誤設為相同 IP。
Client 的 ARP Table 可能一會兒學到正式 Gateway MAC，一會兒學到錯誤設備 MAC。
症狀可能包括：
可透過：
追蹤錯誤設備所在 Port。
這類問題不應只靠重開 Client，因為每次重新學 ARP，可能只是暫時選到正確設備。
企業網路為了避免 Gateway 單點故障，可能使用：
兩台或多台 Layer 3 設備共同提供一個 Virtual IP。
例如：
Switch A：10.10.20.2
Switch B：10.10.20.3
Virtual Gateway：10.10.20.1
Client 的 Default Gateway 設為：
10.10.20.1
正常情況下，由 Active／Master 設備持有 Virtual MAC 並轉送流量。
若備援異常，可能出現：
因此，Gateway 出問題時，不一定只查一台 Router。
還要確認 Virtual IP、角色、Priority、Preempt 和 Tracking 狀態。
使用者回報：
電腦可以印文件，但瀏覽器完全不能上網。
查看設定：
IP：10.10.20.35
Mask：255.255.255.0
Gateway：空白
DNS：10.10.10.53
印表機位於：
10.10.20.50
兩者同網段，因此透過 ARP 與 Switch 就能互通，不需要 Gateway。
但 DNS 位於：
10.10.10.53
外部網站也位於遠端網路。
由於沒有 Default Gateway，Client 無法到達 DNS，也無法前往 Internet。
進一步檢查發現，該電腦被手動設定 IP，操作人員只填了 IP 和 Mask，漏掉 Gateway。
補上正確 Gateway 後，遠端連線恢復。
但完整處理不應只停在手動補值。
還要確認：
Client 設定：
IP：10.10.20.35
Mask：255.255.0.0
Gateway：10.10.20.1
正確 Mask 應為：
255.255.255.0
Client 可以：
10.10.20.50
但無法連：
10.10.50.10
原因是 Client 使用 /16，誤以為 10.10.50.10 位於本地，於是直接發 ARP，而不是交給 Gateway。
封包根本沒有進入 Inter-VLAN Routing。
將 Mask 修正為 /24 後，Client 正確把遠端流量送給 Gateway，服務恢復。
這個案例提醒我們：
半通不通時，IP、Mask、Gateway 必須一起看。
只確認 Gateway 有填，不代表 Client 一定會使用它。
遇到「同網段可以、跨網段不行」時，可以依序檢查。
Windows：
ipconfig /all
Linux：
ip addr
ip route
確認：
根據 Client IP、Mask 和目的 IP 計算。
不要只憑前三段看起來一樣，就直接認為同網段。
實際邊界取決於 Prefix Length。
arp -a
或：
ip neigh
確認 Gateway MAC 是否能解析。
Windows：
route print
Linux：
ip route
確認：
依序測試：
確認：
Client 與同網段設備通訊時，可以直接透過 ARP 與 Switch 傳送 Frame，不需要 Default Gateway。
只有當目的地位於不同網段時，才會把封包交給 Gateway。
因此：
同網段可以、跨網段不行
→ 檢查 Mask、Gateway、Route
Gateway 無法解析 MAC
→ 檢查 VLAN、Layer 2、Gateway Interface
Gateway 可達、遠端不可達
→ 檢查上游 Route、Firewall、NAT 與回程
多網卡啟用後才異常
→ 比較 Routing Table、Metric 與 Source IP
最重要的是，Routing Table 會先選最精確的 Route，找不到時才使用 Default Route。
Default Gateway 不是每個封包都會拜訪的必經景點，而是前往未知遠端目的地時的預設出口。
iThome鐵人賽
看影片追技術