隨著互聯網技術的不斷發展，傳統的 IPv4 地址已不能滿足用戶的需要。新一代的 IPv6 協議也日益被廣泛的接受和使用，越來越多的軟件系統都要求支持 IPv6 網絡協議。然而現有網絡環境對 IPv6 的支持仍然非常有限，這給軟件的開發和測試都帶來了一定的困難。本文將介紹如何使用 Apache 在現有的 IPv4 網絡中構建模擬的 IPv6 環境。
在 Linux 平台及 IPv4 環境中構建 IPv6 測試環境
1 IPv6簡介
IPv6（Internet Protocol Version 6）作為 IPv4 的升級版本，它是作為一共軟件升級安裝在設備和
操作系統中。為什麼需要使用 IPv6，一個最直接的答案就是目前廣泛應用的 IPv4 已經無法提供足夠的 IP 地址來滿足迅速增長的網絡。IPv4 采用32位地址長度，只有大約43億個地址，很快就將被分配完畢。而 IPv6 采用128位的地址長度，幾乎可以不受限制的提供地址。當然擴大地址空間只是 IPv6 的眾多優勢中的重要一項，除此之外，IPv6 還能夠提高網絡的整體吞吐量、改善服務質量（QoS）、安全性有更好的保證、支持即插即用和移動性、更好實現多播功能等等。
從1992年 IPNG 工作組成立，經歷了十幾年的發展，雖然 IPv6 離達到與 IPv4 相同的水平仍有距離，但已經有越來越多的支持 IPv6 的設備投入使用，越來越多的軟件系統開始支持 IPv6。現在 IPv6 已經可以提供 DNS，Web，Email，Ftp，Telnet 等基本服務。Windows，Sun，Apple 等操作系統也都已經或即將支持 IPv6 協議。IBM 也一直致力於 IPv6 的發展，早在1997年 IBM 就發布了支持 IPv6 的 AIX。如今 DB2，Lotus，Rational，Tivoli 和 WebSphere 也都在逐步支持 IPv6 的應用。
2 在 IPv4 環境中模擬 IPv6 網絡
正如上節中所述，目前許多與網絡應用相關的軟件已經加入了對 IPv6 的支持，更有大量的軟件正在處於對 IPv6 支持的開發階段。但是就開發而言，目前許多開發環境並沒有對 IPv6 提供很好的支持，尤其當所開發的應用需要經過較老的路由甚至公共網絡時。如果希望通過升級網絡設備來支持開發環境，將是一筆不小的花費，有時甚至是不現實的（比如短期內升級公共網絡支持 IPv6）。
研究如何在現有的 IPv4 網絡環境中模擬出 IPv6 環境，使得開發和測試工作能夠順利進行，顯得尤為重要。下面介紹一種在 Linux 平台上通過 Apache 服務器來模擬 IPv6 的 HTTP/HTTPS 網絡開發測試環境。
2.1 IPv6 網絡要求及現有的網絡環境
圖1顯示了典型的 HTTP 網絡應用，如果需要對這樣的網絡應用提供 IPv6 的支持，開發和測試人員可能會碰到如下三種情形：
客戶端和服務器運行於同一個局域網中，如圖1-a
客戶端和服務器運行於同一個 Intranet 中，它們之間的網絡通路需要經過路由，如圖1-b
客戶端和服務器分別處於不同的地域，它們之間由 Internet 提供連接，如圖1-c。
圖 1. 三種典型的 HTTP 網絡應用
在這三種不同的情形下，IPv6 的網絡環境要求是不同的。對於情形1，只需客戶端和服務器所運行的操作系統支持 IPv6 即可通過 IPv6 協議進行通信，若需要提供 Global 地址的通信，則可以通過在局域網內的某台機器上運行一個軟件 IPv6 路由來支持，因此其針對 IPv6 的開發和測試相對簡單。 對於情形2，由於客戶端和服務器之間經過運行於 IP 層的路由，因此要求網絡通路上經過的所有路由器均支持 IPv6。 這可能是一個不小的挑戰，因為很多 Intranet 環境並沒有提供支持 IPv6 的路由。對於情形3，這就要求 Internet 提供 IPv6的支持，就短期看來，Internet 提供全面的 IPv6 支持還不太可能。
因此，在情形2和情形3的環境中，網絡硬件支持將成為開發和測試支持 IPv6 的網絡應用程序的最大障礙，在2.2節中將給出如何運用現有的 IPv4 網絡來進行 IPv6 應用程序的開發和測試，同時又保證其在真實的 IPv6 環境中正常運行。
2.2 利用現有 IPv4 網絡模擬 IPv6 環境
2.2.1 模擬環境構建的基本原理
圖2 - 圖3顯示了 IPv6 模擬環境的框圖，這裡存在兩種情形，但具體的配置是類似的。
對於開發客戶端 IPv6 應用程序，其框圖如圖2；而對於開發服務器端 IPv6 應用程序，其框圖如圖3。其基本原理就是利用代理技術將原來被 IPv4 網絡阻斷的客戶端或服務器端映射到位於同一局域網內的代理服務器上，這樣“客戶端”與“服務器端”就可以進行基於 IPv6 的網絡通信了。 在圖2中，我們需要代理服務器與客戶端運行於同一局域網中，在客戶端看來，此代理服務器是一個具備了 IPv6 支持能力的“服務器”，即使真正的服務器端並沒有支持 IPv6 ，也可以進行客戶端的開發和測試。在圖3中，我們需要一台機器與服務器端運行於同一局域網中，在服務器端看來，此代理服務器是一個具備了 IPv6 支持能力的“客戶端”。
圖 2. 利用代理將服務器端映射到與客戶端同一局域網內
圖 3. 利用代理將客戶端映射到與服務器端同一局域網內
下面僅以客戶端的IPv6環境為例來講述整個模擬環境的構建過程。
2.2.2 環境的建立
操作系統平台： Linux，內核需支持 IPv6，2.6以上版本最佳，
推薦使用 RedHat Enterprise Linux 5或SuSE Linux Enterprise Server 10
軟件： radvd（Router ADVertisement Daemon），
這是一個運行於 Linux 平台之上的提供 IPv6 路由配置信息的軟件，可以替代 IPv6 路由來進行無狀態的地址自動配置。
Apache，這是目前應用最為廣泛的 Web 服務器，要求版本2.0以上
openssl，運行於 Linux 平台上的提供實現 SSL v2/v3 協議的加解密工具包
2.2.3 啟動 radvd
IPv6 的地址獲取方式與 IPv4 有所不同。在 IPv4 中，主機 IP 地址的自動配置必須由 DHCP 服務器來支持，這被稱為有狀態的自動配置（StatefulAutoconfiguration）；而在 IPv6 中，除了 DHCP 的 v6版本，還引入了無狀態的自動配置（ StatelessAutoconfiguration ）。這項新技術無需 DHCP 服務器支持，所有支持 IPv6 的路由器都監聽各主機發送的自動配置請求包， IPv6 路由器對這類請求包的回復裡面包含了一些 IPv6 地址的前綴（ prefix ）信息，主機在收到這樣的包以後，可以根據自己的一些已有信息（比如 MAC 地址），生成自己的 IPv6 地址。
本文是在現有的 IPv4 網絡環境中模擬 IPv6 環境，自然不存在物理的 IPv6 路由器，但是通過 Linux 平台上的 radvd 工具也可以模擬無狀態自動配置，它同樣可以監聽局域網內各 IPv6 主機發送的自動配置請求並作出響應，這樣，這些主機就可以獲得各自的 IPv6 地址，並利用這些地址進行相互間的通信。而圖X中的客戶端正是使用這種方式與代理服務器通信的。
這裡以 SLES10 平台上的 radvd-0.9-13.2 為例來說明 radvd 的配置和啟動過程。
從 SLES10 的安裝光盤中找到 radvd-0.9-13.2.i586.rpm 進行安裝
# rpm -ivh radvd-0.9-13.2.i586.rpm
配置運行 radvd 的主機的 IPv6 地址信息
# ip a a 2002:9ba:b4e:6::1/64 dev ethX
# ip r a 2002:9ba:b4e:6::/64 dev ethX
這裡的 ethX 表示的是此主機監聽局域網數據包的網卡設備
radvd 安裝後其配置文件位於 /etc/radvd.conf ，在這個文件中加入配置信息
interface ethX
{
AdvSendAdvert on;
MinRtrAdvInterval 5;
MaxRtrAdvInterval 10;
AdvDefaultPreference low;
prefix 2002:9ba:b4e:6::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
同上，這裡的 ethX 表示的是此主機監聽局域網數據包的網卡設備。prefix 段表明了該局
域網配置 IPv6 地址的前綴。
確保系統啟動了對 IPv6 數據包的轉發功能
# sysctl -w net.ipv6.conf.all.forwarding=1
啟動 radvd
# /etc/init.d/radvd start
在 radvd 啟動成功後，通過 ps 命令可以看到系統中有一個 radvd 的 daemon 進程處於運行狀態。若對局域網中的其他主機運行 ifconfig 命令可以看到這些主機已經自動配置了 IPv6 地址，其前綴（ prefix ）與 radvd 配置文件中的值一致。
2.2.4 配置 Apache 服務器
Apache 服務器是整個模擬 IPv6 環境的核心部分，它將監聽來自 IPv6 網絡連接的數據包，並將其通過 IPv4 網絡轉發到服務器端。這裡使用了 Apache 服務器的 mod_proxy 模塊，相信這一模塊提供的 Forward Proxy 功能已為大家所熟知，並被廣泛采用。這一模塊同時還提供了 Reverse Proxy 功能，本文就采用了此技術來實現轉發功能。運行 Reverse Proxy 的 Apache 服務器對於客戶端而言就是一台實際的 Web 服務器，客戶端將從該服務器獲取和上傳所有的數據，具體的配置方法如下文所述。
大多數的 Linux 平台已經安裝了 Apache 服務器，對於已經安裝了 Apache 服務器的平台，必須保證其支持 IPv6，並且加載了 mod_proxy和mod_ssl 模塊。當然也可以從 Apache 的源代碼開始編譯一個新的 Apache 服務器。
首先需要確定 Apache 服務器監聽 IPv6 地址，一般而言，在 httpd.conf 中有如下一條：
Listen 80
這表明該 Apache 服務器監聽所有的主機地址，自然也包括 IPv6 的地址。若原 Apache 服務器配置了監聽一些特定的地址，確保這些地址中包含代理服務器與客戶端通信使用的 IPv6 地址。
對於代理服務器的配置，這裡需要使用 Apache 服務器的 mod_proxy 模塊中的 ProxyPass 指示字，在 Apache 配置文件中加入如下的配置語句。
NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin [email protected] ServerName ipv6-server-proxy ProxyRequests off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /request http://www.server.com/request ErrorLog "logs/proxypass-error_log" CustomLog "logs/proxypass-access_log" common </VirtualHost>
這裡的 ProxyPass 指示語的含義是所有對此 Apache 服務器的 /request 目錄的訪問都將轉發到 http://www.server.com/request。若此 Apache 服務器的 IPv6 地址為2002:9ba:b4e:6::3，則客戶端若訪問
http://[2002:9ba:b4e:6::3]/request
實際獲得的數據將來自於
http://www.server.com/request
這樣，在客戶端看來，與其通信的服務器是一個支持 IPv6 的服務器端，而實際上是 Apache 代理將遠程的服務器端映射到了本地的 IPv6 網絡。在這種環境下，客戶端就可以來開發和測試自身對 IPv6 的支持了，而無需考慮服務器端對此協議的支持。
上述語句添加的位置由 Apache 的配置文件結構決定，目前許多版本的 Apache 采用多個配置文件，即由一個主的配置文件 httpd.conf 來包含其他子項配置文件，如 httpd-vhosts.conf，httpd-ssl.conf 文件等，而不是所有的配置信息全部寫在 httpd.conf 文件中。這裡推薦將上述配置語句寫入 httpd-vhosts.conf 文件中，然後在主配置文件 httpd.conf 文件加入下面這條包含此文件。
Include httpd-vhosts.conf
這裡默認 httpd-vhosts.conf 與 httpd.conf 在同一目錄下，多數情況下要加入 httpd-vhosts.conf 的相對路徑。
對於需要使用 HTTPS 連接的應用程序，其 Apache 服務器的配置有所不同，參見下一節2.2.5中的具體介紹。
在配置好以後，即可啟動/重啟 Apache 服務器來使得剛才的配置生效。
# /etc/init.d/httpd restart
2.2.5 利用 openssl 生成 HTTPS 連接所需的認證信息
由於運行 Reverse Proxy 的 Apache 服務器在客戶端看來是一台實際的 Web 服務器，因此在進行 HTTPS 連接時，客戶端需要驗證其 SSL 簽名的有效性。這樣，我們需要在上述配置好的 Apache 服務器中加入 SSL 認證信息，才能保證客戶端的 HTTPS 應用程序能夠正常運行。
自簽名（self-signed）的 SSL 認證文件的生成
首先是生成根證書文件 ca.crt
# openssl genrsa -des3 -out ca.key 4096 # openssl req -new -x509 -days 365 -key ca.key -out ca.crt
第一步是生成一個根證書的 key 文件，系統會要求輸入 pass phase， 記下輸入的密碼，這一密碼會在後面多次用到。而第二步則將使用這個 key 文件來生成根證書，這一步執行時系統會要求輸入許多根證書的信息，值得注意的是 Common Name（CN），這一步中輸入的 CN 值應與下一步生成服務器證書時輸入的不同。
接著需要生成服務器證書簽名請求（Certificate Signing Request）文件 server.csr，步驟與生成根證書文件類似。
# openssl genrsa -des3 -out server.key 4096 # openssl req -new -key server.key -out server.csr
同樣，在第二步中會要求輸入一系列的服務器信息，這裡的 Common Name（CN） 應與客戶端訪問該服務器時使用的地址相同，例如：
客戶端使用 http://proxyhost.com/ 訪問該服務器時，這裡的 CN 應為 proxyhost.com
客戶端使用 http://[2002:9ba:b4e:6::3]/ 訪問該服務器時，這裡的 CN 應為 [2002:9ba:b4e:6::3]
為何需要相同，是因為客戶端的 HTTPS 連接程序會驗證該服務器提供的證書有效性，若證書中的 CN 與實際客戶端訪問的主機名不同，客戶端會拋出 INVALID_CN 錯誤。
最後，利用前面生成的根證書文件 ca.crt 來簽署（Sign）服務器證書簽名請求 server.csr。
# openssl x509 -req -days 365 -in server.csr -CA ca.crt \
-CAkey ca.key -set_serial 01 -out server.crt
將上述生成的四個證書相關文件（ca.crt，ca.key，server.crt，server.key）拷入 Apache 的配置文件夾中，接下來將會把這些文件的路徑和一些配置信息加入到 Apache 配置文件中。
Listen 443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLPassPhraseDialog builtin
SSLSessionCache "shmcb:/usr/local/apache2/logs/ssl_scache(512000)"
SSLSessionCacheTimeout 300
SSLMutex "file:logs/ssl_mutex"
NameVirtualHost *:443
<VirtualHost *:443>
DocumentRoot "apache2/htdocs"
ServerName ipv6-server-proxy
ServerAdmin [email protected]
ErrorLog "ssl-error_log"
TransferLog "ssl-access_log"
SSLEngine on
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
SSLCertificateFile "server.crt"
SSLCertificateKeyFile "server.key"
<Directory "/usr/local/apache2/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog "logs/ssl_request_log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SSLProxyEngine on
ProxyRequests off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /request http://www.server.com/request
</VirtualHost>
這裡再次使用了 ProxyPass 來建立代理服務。
正如上一節2.2.4中所述，這裡建議將這些配置信息寫入 httpd-ssl.conf 中，然後在 httpd.conf 中加入如下一行將其包含。
Include httpd-ssl.conf
配置完成後，即可啟動/重啟 Apache 服務器來使得剛才的配置生效。
# /etc/init.d/httpd restart
客戶端 HTTPS 連接的考慮
由於這裡采用的是自簽名（Self-signed）的方式來生成服務器的認證文件，客戶端使用 HTTPS 連接到該代理服務器時，會出現認證錯誤的提示。這就需要將這裡生成的證書加入到客戶端的可信站點列表中。具體的添加方式因采用的系統不同而各異。就 Windows 平台的 IE 而言，可以將上述生成的 ca.crt 及 server.crt 文件加入到 IE 的可信站點中，這會影響到所有利用 IE 提供的 wininet 庫進行 HTTP 應用開發的程序。
2.2.6 DNS 考慮
在網絡應用中，客戶端一般使用域名來訪問服務器端。在測試 IPv6 的環境中，必須使用 IPv6 的地址來訪問，這就需要一個支持 IPv6 的 DNS 域名服務器，對於一定的域名返回其 IPv6 的地址。目前可以使用在 Linux 平台的 BIND 9 來搭建這樣的 DNS 服務器。但是其配置相對比較復雜，還可以使用一種相對簡便的方法。即利用 Linux 和 Windows 平台均支持的 hosts 文件來配對域名與其相應的 IPv6 地址。這需要在客戶端的相應 hosts 文件中加入一些 IPv6 地址的配置信息。
在 Linux 平台上，hosts 文件一般位於 /etc/hosts，在此文件中加入如下一行：
2002:9ba:b4e:6::3 www.someipv6site.com
這樣就指定了 www.someipv6site.com 的 IPv6 地址為 2002:9ba:b4e:6::3。而在 Windows 平台上 hosts 文件位於 %WINDIR%\System32\drivers\etc\hosts，其格式與 Linux 平台上相同。
2.3 IPv6 和 IPv4 混合環境兼容性測試
從 IPv4 到 IPv6 的過渡是一個漫長而復雜的過程，不可能在短期內實現完全轉換，所以在產品的開發及測試過程中除了考慮 IPv6 網絡內的通訊還需要充分考慮現實網絡環境中很可能出現的 IPv6 網絡和 IPv4 網絡的混合環境，這就需要測試應用程序在此環境下的兼容性。 本節將介紹一些需要模擬的情況。
模擬以下3種網絡情況首先都需要在現有的 IPv4 局域網環境中選擇一台機器作為路由服務器，並按照2.2.3節的描述進行相關配置。這樣與該路由連接於同一個 Switch 上的計算機都將會被自動分配一個 IPv6 的地址。如果仍然沒有獲得 IPv6 的地址，請關閉計算機和路由服務器上的防火牆。然後按照 2.2.4 節中的描述選擇一台計算機設置為 ProxyPass。
2.3.1客戶端和服務器端均運行於 IPv6 的網絡環境
這種情況的驗證相對比較簡單，只需要在客戶端將服務器的地址設為前面配置的 ProxyPass 的 IPv6 的地址便能實現客戶端和服務器端 IPv6 到 IPv6 的交互。這就是2.2節介紹的情況。
圖 4. 客戶端和服務器端均運行於 IPv6 的網絡環境
2.3.2 客戶端運行於 IPv6 網絡，服務端運行於 IPv4 網絡
對於客戶端和服務器端分別處於 IPv6 和 IPv4 環境的情況，需要在局域網環境中增加代理 (proxy) 作為兩者之間的橋梁，該代理與上述路由服務器位於同一個網絡之中，因而也擁有 IPv6 的地址和 IPv4 的地址。客戶端所設置的目的服務器端地址為 IPv4 的地址，設置的代理地址為該代理的 IPv6 的地址，這樣客戶通過 IPv6 協議與代理直接進行通訊，而代理接受到客戶端所設置的 IPv4 格式的服務器地址後則通過 IPv4 協議與服務端交互，這樣便模擬實現了客戶端位於 IPv6 網絡而服務器端位於 IPv4 網絡的情況。
圖5 客戶端運行於 IPv6 網絡，服務端運行於 IPv4 網絡
2.3.3 客戶端運行於 IPv4 網絡，服務端運行於 IPv6 網絡
模擬位於 IPv4 網絡中的客戶端與位於 IPv6 網絡中的服務器端進行交互需要使用 Proxy 和 ProxyPass 來進行環境搭建。客戶端將 ProxyPass 所在的 IPv6 的地址設置為服務器端的地址，將 Proxy 所在的 IPv4 的地址設置為代理的地址，這樣客戶端與代理之間通過 IPv4 協議進行通訊。代理在獲取到客戶端所配置的 IPv6 協議的 ProxyPass 地址後將通過 IPv6 協議與 ProxyPass 進行交互。ProxyPass 收到客戶端發送的請求後將通過 IPv4 的協議發送給真正的位於 IPv4 網絡中的服務器進行處理。這樣在客戶端就模擬實現了 IPv4 網絡到 IPv6 網絡的通訊。
圖6 客戶端運行於 IPv4 網絡，服務端運行於 IPv6 網絡
3 總結
在本文中，我們通過使用現有的 IPv4 網絡配合 Linux 平台上的 Apache 服務器，達到了模擬 IPv6 的 HTTP/HTTPS 網絡環境的目的，從而可以在有限的硬件資源之下開發和測試網絡應用軟件對 IPv6 的支持。這項技術還可以應用到其他的網絡協議之上，只需使用具備類似於 Apache 服務器轉發技術的代理服務器。因此這項技術具有一定的通用性。