一般使用者所說的網路不通，通常指的是開啟IE（Internet Explorer）連不上YaHoo、Google與Microsoft等等知名網站的現象。但在相同的狀況下對MIS人員來說，就不僅僅只是「通或是不通」那樣地單純，而必須抽絲剝繭地查出無法連通的原因並且處理到連上為止，因此網路不通的故障排除即是IT人員基本功夫之一。
本文先從Linux設定網路開始談起，進而提到常見的網路中斷故障排除，並解說處理此類故障排除所需的網路觀念。
常用網路設定方式分析
常用網路設定方式可歸納成三種，分別是「DHCP動態取得」、「固定IP設定」以及「PPPoE」。
DHCP動態取得
使用DHCP動態取得網路設定有著簡單方便的優勢，在Linux上通常使用dhclient來當作DHCP客戶端程式，從名稱dhclient上就可以看得出來它是使用於DHCP Client端的程式，可以利用「ps ax | grep dhc」一類的指令，來觀察目前是否正在執行dhclient程式。
在Red Hat Enterprise Linux設定網路的配套措施中，使用「setup」指令來使用DHCP動態取得網路設定相當簡便。在依序按下〔setup〕→〔Network configuration〕（網路設定）並勾選網路介面「Use DHCP」後，回到指令介面重新啟動網路即可。此時，透過網路重新啟動的「/etc/init.d/network restart」script呼叫dhclient程式，而動態取得網路設定。
上述設定主要是異動「/etc/sysconfig/network-scripts/ifcfg-eth0」檔案內容中「BOOTPROTO=dhcp」這一行。
固定IP設定
固定（Static）IP方式會提供設定所需的資訊，像是IP/網路遮罩（Netmask）、預設閘道（Default Gateway）與名稱解析伺服器（Name Server）等等，在直接對外的公開（Public）IP主機設定網路即是一例，以下資訊由ISP業者提供：
| IP/網路遮罩 |
60.250.207.96/255.255.255.0 |
| 預設閘道 |
60.250.207.254 |
| 名稱解析伺服器一 |
168.95.1.1 |
| 名稱解析伺服器二 |
168.95.192.1 |
在Red Hat Enterprise Linux中的「IP/網路遮罩及預設閘道」設定，使用先前介紹的「setup」指令即可辦到，取消網路介面「Use DHCP」的勾選後，底下的方框輸入上述的相關設定。
上述設定同樣也是異動「/etc/sysconfig/network-scripts/ifcfg-eth0」檔案的內容。
而在名稱解析的部分，則是開啟「/etc/resolv.conf」檔案，編寫內容如下。它的關鍵字是「nameserver」，後面接著是名稱解析伺服器的IP，詳細說明請參考指令「man resolv.conf」。
nameserver 168.95.1.1
nameserver 168.95.192.1 |
對照微軟網路設定內容，「自動取得IP」對應的是DHCP方式；手動設定的上方框是對應到「setup」指令的設定；下方框部分則必須編輯「/etc/resolv.conf」檔案內容。
PPPoE
第三種常用的設定是PPPoE（Point-to-Point Protocol over Ethernet），顧名思義，它是一種運用在乙太網路上的點對點通訊協定，常應用於ADSL Router連線，需要一組帳號密碼來做身分驗證，連線成功後會出現PPP的網路介面（例如ppp0）。
Red Hat Enterprise Linux使用一系列「adsl-*」指令進行PPPoE的設定與應用，如「adsl-setup」。設定完成後，帳號密碼主要寫到「/etc/ppp/」目錄下的pap-secrets與chap-secrets這兩個檔案；其他部分若有更動，則是配合Red Hat Linux網路設定「/etc/sysconfig/network-scripts/ifcfg-ppp0」檔案。
以下是執行「adsl-setup」指令的畫面，設定期間系統詢問的問題雖然很多但都不難回答，除了帳號密碼這兩個部分特別重要之外，其他大多直接按下Enter就行。
此為重點步驟，一開始出現「LOGIN NAME」，要求輸入「使用者名稱」，本例鍵入「12345678@msa.hinet.net」。
進入INTERFACE的部分，直接按下即可。除非有兩張以上的網路卡，而且PPPoE不是在eth0上執行，則必須填入正確的網路卡代號，例如eth1或eth2等等。
接下來看到一堆的英文，大概的意思是詢問設定者要不要持續連線（link continuously）或是一段時間後自動斷線，直接按下Enter就可以。
在DNS部分，通常按下即可。若有需要，請自行開啟「/etc/resolv.conf」檔案，然後輸入nameserver相關資訊。
此為重點步驟，開始設定PASSWORD，請重複輸入兩次PPPoE密碼。
進入USERCTRL部分，意思為「是否允許一般使用者啟停此介面」，筆者回答「NO」（不允許）。
FIREWALLING部分，筆者選擇「0」之後再自行調整防火牆設定。相關設定如下：
詢問開機是否啟動此PPP連線（start at boot time），本例選擇「yes」，開機即連線。
詢問是否寫入設定（adjust configuration），選擇「y」。
之後使用網路啟停的script，如「/etc/init.d/network restart」，若是按照以上筆者的設定，ifcfg-ppp0檔案的內容將會是「ONBOOT=yes」，亦即自動啟動ppp0介面。
之後使用「ip a」或「ifconfig ppp0」指令，就可以看到ppp0介面以及它所使用的IP位址。
如果此時TCP/IP連線正常，但是「名稱解析」不正常，請記得自行編輯「/etc/resolv.conf」來設定DNS解析。
網路不通故障排除
最常見的網路架構是使用Ethernet（乙太網路）將兩台以上的電腦設備連接起來，並使用TCP/IP設定成同網段（NetID）、相異的兩個IP來測試網路連線是否正常。接下來就以幾個常見的網路不通情況，搭配Linux網路偵錯與測試的指令，來實作網路不通的故障排除。
網路卡沒驅動
在Linux中，網路卡通常是由kernel內建的驅動程式就能運作，使用指令「ifconfig -a」（顯示所有介面）或「ip a」指令就可以看到eth0（乙太網路第一張卡：ethernet 0）或是eth1、eth2等已經驅動的網路介面。如果發生網路卡無法驅動的情況，可能的解決方案如下：
|
|
| |
換用新版本的kernel（或Distribution）也許就可以成功驅動，尤其是比較新的網路卡，通常新版的kernel才會內建相關的驅動程式。 |
|
|
| |
購買一張普通一點的網路卡來安裝，如此一來Linux就有辦法使用內建的驅動程式。 |
|
|
| |
至網路卡原廠網站下載正確的Linux驅動程式，解開後照著「README」檔案內的說明進行安裝，或者執行其中的make或install程式來安裝。 |
請注意，編譯原廠驅動程式需要安裝gcc和kernel-devel（在SUSE稱為kernel-source）這些相關的套件，這與安裝原廠顯示卡驅動程式類似，請參考筆者所撰寫網管人十二期「Linux下的3D桌面特效」一文中關於顯示卡安裝原廠驅動程式的解說。
至於網路卡型號方面，在Linux中可以使用「lspci | grep -i eth」指令查出一些端倪（lspci可查詢有關於ethernet的資訊）。
網路卡未啟用（停用中）
執行「ifconfig」指令時若未使用「-a」選項，只會顯示「啟用（up）」介面，附加「-a」選項時才會顯示出所有介面。可想而知，在某個網路介面沒有啟動之前，想透過這個介面上網是不可能的。如果使用「ip a」指令來觀察，若看到此網路介面冒號後面< >符號內有UP，就代表啟用中。
使用指令方式啟用/停用網路介面如下表：（網路介面以eth0為例）
| 顯示使用中的網路介面 |
顯示所有網路介面 |
啟用eth0 |
停用eth0 |
| ifconfig |
ifconfig -a |
ifconfig eth0 up |
ifconfig eth0 down |
| ip a（有UP的） |
ip a（a是addr） |
ip link set eth0 up |
ip link set eth0 down |
網路線沒接（或沒接好）或接錯網路卡
在插上網路線時，網路卡與網路設備通常會自動協商（auto-negotiation）之間應該使用的速度（speed）是10、100或是1Gb/s，以及該使用全雙工（Full-duplex）或半雙工（Half-duplex）的模式進行傳輸。
現今的網路大多是以100Mb/s或1Gb/s的速度且全雙工模式運作，採用全雙工的原因是主機連接的網路設備大多是Switch，鮮少是Hub（集線器），現在大概也只有Hub才會是以半雙工模式運作且封包會有collisions（碰撞）現象，一般可使用ifconfig指令觀察封包是否發生碰撞。
可以利用指令「ethtool eth0」、「ethtool eth1」來觀察或設定eth0、eth1網路介面關於上述的運作情況，也可藉此看出哪個網路介面是否有接上線（Link detected: yes是上線、no是離線），如此一來，若有兩張以上的網路卡，也比較不會插錯網路孔。
舊版的Linux則是使用指令「mii-tool」來觀察或設定上述運作情況，同樣可以看出哪個網路介面有沒有接上線（「link ok」或「no link」），例如下圖所示就是eth0已接上線、eth1沒接上線的情況。
IP/Netmask設定有誤
先前介紹的三個網路不通的原因，比較偏向實體層（Physical Layer）方面，接下來所列舉出網路不通的情況，因為已經設定TCP/IP網路，所以較偏向於TCP/IP Model（模型）的網路層（Internet Layer）與連結層（Link Layer）網路不通的情況。
要測試兩台之間通或不通，最簡便的方式是：「在同一個Broadcast Domain網路下，設定相同網段（NetID）中相異的兩個IP來測試網路連線是否正常」。如果兩台電腦的IP/Netmask設定有誤，可能是輸入錯誤或是設定成不同的網段IP，那麼這兩台主機雖然是在同一個Broadcast Domain，但TCP/IP連線卻是不通的。上述情形意思是以連結層來看是暢通的（因為它們在同一個Broadcast Domain之中），但以網路層來看卻是不通的（因為設定TCP/IP有誤）。筆者在網管人第二十五期「營造Linux學習環境的利器VirutalBox」一文中，測試兩台虛機之間的內部網路時，即是使用上述的測試方式（如下圖）。
不同Broadcast Domain所造成的網路不通
對於「不同Broadcast Domain所造成的網路不通」，就算此時兩台電腦設定成相同網段（NetID）中相異的兩個IP，依然是不通的。在此先了解何謂「Broadcast Domain」，底下以一些實際的網路案例來幫助大家一同了解Broadcast Domain。
●用一般Switch串起來的網路算是同一個Broadcast Domain。
●使用具備管理功能的Switch切VLAN就會產生兩個以上的Broadcast Domain。
●一般路由器（Router）兩頭實體網路各自分開，算是不同的Broadcast Domain。
●具備VLAN功能的路由器（Router），不同VLAN分屬不同Broadcast Domain。
綜合以上幾項要點，歸納後大致上的結論是：
●相同Broadcast Domain以IPv4來說，能夠直接詢問到對方的MAC Address。
●相同Broadcast Domain以IPv4來說，兩台主機溝通前就要先問出對方的MAC Address。
兩台主機在同一個Broadcast Domain下只要相互溝通，就會知道對方的MAC Address，在Linux可使用指令「arp -an」來觀察。下圖是在主機「172.18.0.35」 ping 「172.18.9.44」的arp情況（其實用ping指令以外的連線方式也可以，例如telnet指令）。
在主機「172.18.0.35」 ping 「172.18.9.44」期間，在172.18.9.44那台執行「tcpdump 'host 172.18.0.35'」的話（「172.18.0.35」是對方IP），會更清楚地看出連線之前先發arp封包問MAC Address的原理。 一般來說，通過Router以後就來到另一個Broadcast Domain，所以預設是無法經過Router問到對方主機的MAC Address，例如一般人應該問不到Google主機的MAC Address。
未設定預設閘道（Default Gateway）
在設定好TCP/IP之後（IP/Netmask），相同網段的主機已經可以「直接溝通」，至於不同網段主機之間的溝通，則需要通過Router才行。這可以透過主機的路由表（Routing Table）來解釋，例如下圖執行「route -n」指令的情況：
先了解一件事：絕大多數的Router收到封包後，都是看封包的「目的地IP位址」（Destination IP Address）來決定下一站要往哪個IP去（擁有那個IP的就是下一個Router或主機）。
以下頁圖來說，到網段172.18.0.0/255.255.192.0的封包是「直接連線」的，這也意味著不必透過路由器就可以直接進行連接（且此網段所用的介面是eth0）。
至於要連往其他網路IP的封包（例如送往168.95.1.1的封包），則符合最後一行的預設路由（Destination是0.0.0.0）丟向這台主機的預設閘道172.18.1.1。
接下來模擬將路由表預設閘道刪除（使用「route del default」指令），這樣通往其他網段（如168.95.1.1）就會出現「Network is unreachable」的訊息，因為通往這個網段的封包，此時並不知道該往哪裡傳遞。
此時，如果在將路由表預設閘道新增回來（使用「route add default gw 172.18.1.1」指令），當然就恢復正常了。另外，可以使用指令「traceroute -n 168.95.1.1」追蹤一路上所走的路徑。
名稱解析未設定或回應不正確
先前曾經提及，想修改Linux名稱解析設定，編輯「/etc/resolv.conf」，在其中的「nameserver」參數後面輸入名稱解析伺服器的IP即可。
之前的連線測試，都是以「IP」為基礎，不像一般使用者使用以「名稱」為基礎的連線方式，下面以「名稱解析未設定」為例，在沒有DNS Server可詢問解析的情況下（如下圖將nameserver用＃註解起來時），連線時則會出現「unknown host」訊息（以ping dns.hinet.net主機為例）。
調整回正確的有名稱解析伺服器時，就又恢復正常了。
應用程式（Application）的網路不通
TCP/IP暢通之後是屬於TCP/IP Model中的網路層（Internet Layer）正常，至於名稱解析正確，已經關係到TCP/IP Model傳輸層（Transport Layer）與應用層（Application Layer）這兩個層面（例如名稱解析是使用DNS採用UDP傳輸），這裡要探討的應用程式網路不通就是屬於這兩個層面的事情。下圖為「http://en.wikipedia.org/wiki/Internet_protocol_suite」的TCP/IP Model。
學網管的一定聽過OSI七層Model，它所定義的七層相對於TCP/IP來說比較廣義，而TCP/IP Model算是應用最成功也最容易實作的，也因此對IT或MIS而言也比較容易理解TCP/IP Model。
網路應用程式通不通，一般只要檢查傳輸層的TCP或UDP封包是否正常傳送接收。傳送接收正常後，就是應用程式本身處理資料的事情。針對TCP與UDP的封包，都可以使用tcpdump來查看是否真的收到。另外，在TCP的部分也可以用「telnet 主機或IP位址 埠號」指令來查探。例如使用指令「telnet www2.babyface.com.tw 3306」（3306埠是知名資料庫Mysql預設使用的埠）可測試對於主機www2.babyface.com.tw的3306埠有無回應（下圖中顯示有回應）。
應用程式不通有許多種可能，在伺服器端方面有以下幾種情形：
●服務沒有啟動，例如很多服務安裝後預設值都是開機時不自動啟動，如ftpd、telnetd、httpd等等。
●服務沒有聆聽那個介面或IP，例如RHEL5的sendmail預設只聆聽127.0.0.1（lo介面）。
●應用程式本身已設定允許拒絕來源主機，像httpd、samba的設定檔都可以設定允許或拒絕來源主機。
●TCP Wrapper已設定阻擋到應用程式某些來源主機，就是寫在「/etc/hosts.allow」與「/etc/hosts.deny」中的設定。
●xinetd已設定阻擋來源主機，例如RHEL5的檔案「/etc/xinetd.d/swat」在SWAT（Samba網頁管理工具）安裝好之後只允許127.0.0.1。
●防火牆（Linux iptables）擋住某些埠號的來源主機，請注意iptables設定「-j DROP」或「-j REJECT」兩種方式都可以阻擋，但阻擋後的客戶端回應訊息卻不太一樣。
以上所造成不通的回應訊息也許會有些不同，有的卻很類似，此時只好耐心地抽絲剝繭查明原因。客戶端的錯誤設定也可能造成不通，最常見的包括主機名稱或IP輸入錯誤、已設定Proxy的瀏覽器卻不自知等等。