做網絡或運維這一行大概率被問過這樣一句話內網 Web 服務已經部署好了外網為什么還是訪問不了如果排查后發(fā)現(xiàn)網站進程在跑、域名解析也正常問題往往集中在防火墻配置上。這篇文章圍繞一個非常典型的需求展開通過防火墻的目的 NAT 和安全策略讓外部互聯(lián)網主機可以訪問公司內部 Web 服務器。先說結論這種需求不是改一條“端口映射”就能結束的。完整鏈路通常需要四類配置配合接口和安全域、目的 NAT也叫服務器映射/端口映射/DNAT、入方向安全策略以及若干基礎路由項。任何一環(huán)缺失外部訪問都起不來。文章會從原理、網絡規(guī)劃、配置步驟、驗證手段到常見排錯完整過一遍不管你現(xiàn)在用的是華為、H3C、深信服、天融信還是其他家用級防火墻只要把配置邏輯對齊剩下的就是按鈕位置差異。尤其適合下面幾類讀者剛接手公司出口防火墻的運維新人、要給客戶演示系統(tǒng)的實施工程師、被“外網訪問內網 Web”這類需求反復折磨的網絡管理員。下面直接用工程化視角拆解全過程。1. 外部互聯(lián)網主機訪問內部 Web 服務器方案能力速覽規(guī)劃項說明核心需求外部互聯(lián)網主機通過公網 IP/域名訪問公司內部 Web 服務器的 80/443 服務技術本質防火墻目的 NAT 入方向安全策略 路由可達推薦網絡位置Web 服務器放在防火墻 DMZ 區(qū)不要直接放進辦公網核心區(qū)主要開放端口HTTP 80、HTTPS 443按實際業(yè)務最小化開放涉及防火墻功能接口安全域、服務器映射/DNAT、安全策略、會話表、日志驗證方式外網側主機用瀏覽器、curl、telnet 測試防火墻看會話表和策略命中計數(shù)安全邊界只放行業(yè)務必需端口公網管理入口必須限制源 IP保留審計日志典型風險直接“全端口映射”到內網、目標 Web 服務本身存在漏洞、未做來源限制這個方案的價值很明確不需要申請額外專線不用改內部網絡架構一臺帶 NAT 能力的防火墻就可以把內部 Web 服務安全地發(fā)布到公網。2. 適用場景與使用邊界2.1 適合哪些場景第一類是正式對外業(yè)務發(fā)布。公司有自己的官網、產品介紹頁、客戶查詢系統(tǒng)申請了合法公網 IP 和域名后需要把這些跑在內網服務器上的 Web 服務開放給公網用戶。第二類是短期項目演示。給外部客戶演示內部系統(tǒng)時客戶不愿意裝客戶端只想用瀏覽器訪問你的服務這時臨時發(fā)布一個 HTTPS 頁面最省事。第三類是前后端聯(lián)調。外包開發(fā)商需要訪問公司內部測試站點又不想把源碼和數(shù)據(jù)庫暴露在外網。無論是哪類場景關鍵前提都是你擁有這些服務器和防火墻的管理權限并且已經獲得公司安全負責人授權。2.2 不適合哪些場景如果目標 Web 服務器承載了財務、人事、核心數(shù)據(jù)庫等高敏感業(yè)務不建議直接用 NAT 映射暴露到公網除非已經完成安全評估并配套了 WAF、入侵檢測、日志審計等加固手段。也不建議把服務器所在網段和辦公終端混在一起例如讓 Web 服務器直接使用辦公電腦所在的 192.168.x.x 網段再把整段 80/443 映射出去這種做法會讓攻擊面擴大到整個辦公網。2.3 安全與合規(guī)邊界對外發(fā)布 Web 服務前要確認域名、公網 IP、ICP 備案等手續(xù)是否已經合規(guī)不要自己私拉公網入口繞過既有網絡管理流程。在測試環(huán)境中可以使用本文的配置方法做驗證但正式上線前必須由網絡負責人評審策略。3. 拓撲規(guī)劃與信息清單先看一個簡化但典型的網絡拓撲外部互聯(lián)網主機 198.51.100.5 | | 訪問 https://www.example.com v 防火墻 WAN 接口 203.0.113.1/24 ----- untrust 區(qū)域 | | DNAT: 203.0.113.10:443 - 192.168.10.10:443 v 防火墻 DMZ 接口 192.168.10.1/24 ----- dmz 區(qū)域 | v DMZ 區(qū) Web 服務器 192.168.10.10這里使用的是文檔保留地址。演示環(huán)境中公網側可以是 203.0.113.x實際生產環(huán)境必須替換成運營商分配給你的合法公網 IP。內網 DMZ 段使用 192.168.10.0/24。規(guī)劃時至少要把以下信息整理成一張表參數(shù)示例值說明公網接口 IP203.0.113.1/24防火墻 WAN 口地址內部接口 IP192.168.10.1/24防火墻 DMZ 口地址對外公網 IP203.0.113.10專門用于 NAT 映射的合法公網地址Web 服務器內網 IP192.168.10.10DMZ 區(qū)服務器地址對外協(xié)議端口443/TCP盡量只開放 HTTPS內網服務端口443/TCPWeb 服務實際監(jiān)聽端口域名解析www.example.com - 203.0.113.10公網 DNS 或測試用 hosts源地址限制可選如僅允許 198.51.100.0/24可縮小暴露面如果服務器同時需要跑 HTTP 和 HTTPS一般建議對外只放 443再把 80 跳轉到 443。這樣可以減少明文流量和中間人風險。4. 為什么“端口映射”和“安全策略”必須同時配置很多初學防火墻的人會混淆一件事我到底需要做 NAT還是需要放安全策略答案是兩者都做缺一不可。目的 NAT 解決的是“地址能不能到達”的問題。公網用戶發(fā)起訪問時目的地址是 203.0.113.10而內部 Web 服務器是 192.168.10.10。如果不做目的 NAT公網報文進入防火墻后會被轉發(fā)到一個外部無法路由的私網地址上報文不可能到達 Web 服務器。安全策略解決的是“流量允不允許通過”的問題。防火墻默認情況下通常拒絕跨安全域的流量。即使你做了目的 NAT外部流量被轉換成了到 192.168.10.10 的訪問如果 untrust 到 dmz 方向沒有對應策略防火墻依然會丟包最常見的現(xiàn)象是外網 telnet 公網 IP 的 443 端口不通防火墻會話表里能看到嘗試但 action 是 deny。另外還有一條經常被忽略回程流量并不需要你額外配置“反向 NAT”。Web 服務器收到請求后會向源地址回包。防火墻在建立 NAT 會話后會記住“公網地址:端口 - 內網地址:端口”的對應關系當服務器回包經過防火墻時會自動把目的地址從 192.168.10.10 的私網源轉換回公網地址 203.0.113.10再從 WAN 口返回外部用戶。這也是“狀態(tài)化防火墻”和普通路由器之間最明顯的區(qū)別之一。5. 環(huán)境準備與前置條件5.1 防火墻側檢查防火墻必須工作在路由模式并至少有三種可用接口或子接口連接互聯(lián)網的 WAN 口、連接 DMZ 服務器的接口、用于管理維護的 LAN 口。更穩(wěn)妥的做法是給防火墻劃分安全域把 WAN 口劃入 untrust把服務器接口劃入 dmz把辦公網或管理網劃入 trust。配置前還要保證防火墻系統(tǒng)時間準確否則后續(xù)日志審計的時間戳會失真。5.2 Web 服務器側檢查先在內網本機驗證 Web 服務本身是否正常# 在 Web 服務器本機檢查服務是否監(jiān)聽 ss -lntp | grep -E :80|:443 # 本機訪問測試 curl -I http://127.0.0.1 curl -I https://127.0.0.1 -k如果本機都不通先解決 Web 服務本身的問題不要急著去改防火墻。常見的坑有兩個一是 Nginx/Apache/IIS 只監(jiān)聽了 127.0.0.1外部網絡根本訪問不到二是服務器本地操作系統(tǒng)防火墻攔截了 80/443 入站端口?？梢耘R時放行或關掉本地防火墻做對比測試但生產環(huán)境建議添加精確入站規(guī)則而不是直接關閉防火墻。5.3 公網側資源檢查對外發(fā)布需要至少一個合法公網 IP并確認它沒有被運營商封禁常用端口。如果服務器上配置了 HTTPS 域名訪問還需要準備好域名和證書。至少在測試階段可以用公網 IP 端口直接訪問但生產環(huán)境強烈建議使用域名避免用戶記憶 IP 地址也方便以后切換公網入口。6. 防火墻 NAT 映射與安全策略配置不同品牌防火墻的菜單名稱有差異但配置項幾乎一樣。下面先給一套通用動作清單再給一個以華為 USG 系列為背景的示意 CLI方便你理解真實配置長的樣子。6.1 配置接口與安全域先確保接口已有 IP 地址并加入了正確安全域interface GigabitEthernet1/0/0 ip address 203.0.113.1 255.255.255.0 interface GigabitEthernet1/0/1 ip address 192.168.10.1 255.255.255.0 firewall zone untrust add interface GigabitEthernet1/0/0 firewall zone dmz add interface GigabitEthernet1/0/1以上是示意 CLI真實設備上請按型號手冊調整。如果防火墻是 H3C SecPath、深信服 AF、天融信 NGFW 等產品一般通過 Web 管理界面的“網絡接口”和“安全域”菜單完成同樣操作。6.2 創(chuàng)建目的 NAT/服務器映射目的 NAT 負責把 203.0.113.10:443 映射到 192.168.10.10:443。典型 CLI 邏輯如下nat server policy web_https zone untrust destination-address 203.0.113.10 0 service 443 tcp translate-address 192.168.10.10在 Web 管理界面上通常叫“服務器映射”“端口映射”“虛擬服務器”“NAT 規(guī)則”配置內容是同一套關系表單字段示例值公網 IP203.0.113.10公網端口443內網 IP192.168.10.10內網端口443協(xié)議TCP映射類型目的 NAT / DNAT如果同時要發(fā)布 HTTP再增加一條 80 端口映射。但考慮到 HTTPS 和 HTTP 跳轉邏輯可以在公網只開放 443然后在 Web 服務器內部自行處理 80 到 443 的重定向。業(yè)務必須面向公網開放多個端口時建議逐條映射而不是一次性把 Web 服務器整段 IP 放出去。6.3 放行安全策略完成 NAT 之后必須再增加一條從 untrust 到 dmz 的安全策略security-policy rule name policy_web_from_untrust source-zone untrust destination-zone dmz destination-address 192.168.10.10 32 service https action permit這條策略的核心語義是允許所有外部互聯(lián)網主機訪問 DMZ 區(qū)的 192.168.10.10 的 443 端口。這里的 destination-address 使用的是 NAT 轉換后的私網服務器地址。大多數(shù)防火墻在啟用 NAT server 后會先執(zhí)行地址轉換再匹配安全策略所以策略里寫私網 IP 是常用做法如果你所用設備要求在策略里寫公網地址就按設備實際規(guī)則調整。需要強調的是不要把動作寫得過于寬松。推薦的最小策略寫法是方向指定 untrust - dmz目標只指定 Web 服務器地址服務只指定 80/443而不是“any to any”。6.4 服務器主動訪問外網時的源 NAT配置了目的 NAT 后外部訪問 Web 服務器的回程是自動解決的。但如果 DMZ 區(qū) Web 服務器需要自己訪問外網比如拉取系統(tǒng)補丁、調用第三方支付 API、上傳日志到云端那就還需要一條源 NAT 策略。否則服務器發(fā)出的報文源地址是私網 192.168.10.10公網回包無法路由回去。nat source-policy rule name snat_server_out source-zone dmz destination-address any action source-nat easy-ip源 NAT 的策略名稱和命令格式因廠商差異較大這里只是示意。如果你的 Web 服務器完全不需要主動上外網可以忽略這一步甚至在最終安全策略里禁止 DMZ 主動訪問外網進一步收縮風險面。7. 配置后的功能驗證流程配置完成后不能只看“策略已提交”就算結束。建議按照從底層到應用層的方式逐步驗證。7.1 Web 服務器本機驗證在 Web 服務器上執(zhí)行# 檢查本機 443 監(jiān)聽 curl -I https://127.0.0.1 -k # 查看 Web 服務進程確認是 Nginx/Apache/httpd ps -ef | grep -E nginx|apache|httpd這一步確認服務進程存在并且監(jiān)聽地址不限于回環(huán)接口。7.2 防火墻下聯(lián)內網驗證從防火墻信任區(qū)域或者辦公網內一臺主機訪問服務器內網地址curl -I https://192.168.10.10 -k如果內網能通說明 Web 服務和后臺路由沒有問題問題范圍可以縮小到 NAT 和安全策略。7.3 公網側驗證從外網主機或模擬外網流量的測試機執(zhí)行# 測試 TCP 端口是否可達 nc -vz 203.0.113.10 443 # 使用 curl 觀察 HTTP 響應碼和響應頭 curl -I https://203.0.113.10 -k # 如果配置了域名和 Host用域名請求 curl -I https://www.example.com -k如果外網能返回 HTTP 200/301/302 等正常狀態(tài)碼說明整條鏈路已經通了。還可以觀察響應頭里的 Server 字段判斷流量確實到達了后端 Web 服務器而不是被防火墻或 CDN 攔截。如果外網 telnet 端口成功但 curl 失敗重點檢查 Web 服務里的域名/Host 配置是否匹配請求頭。例如多個虛擬主機共存時直接訪問 IP 可能返回默認站點而不是目標站點。7.4 Web 服務器訪問日志驗證在 Web 服務器查看訪問日志# Nginx 默認日志路徑 tail -f /var/log/nginx/access.log # Apache 默認日志路徑 tail -f /var/log/httpd/access_log當外網用戶訪問時如果日志里出現(xiàn)來自公網源地址的請求記錄說明從防火墻到服務器的轉發(fā)已經成功。7.5 防火墻會話驗證在防火墻查看 TCP 443 會話確認是否有狀態(tài)為 established 的連接display session table protocol tcp destination-ip 192.168.10.10 verbose不同廠商命令名稱不同華為部分設備為 display session table思科 ASA 可用 show connH3C 可用 display session table。只要能看到目標地址為 192.168.10.10 且端口為 443 的 established 會話大概率說明 NAT 和策略都生效了。8. 防火墻資源占用與性能觀察防火墻不是個人電腦不存在顯存概念但同樣有資源瓶頸。配置外部訪問后需要觀察三類資源。第一是設備 CPU 和內存。Web 服務一旦被外部頻繁訪問防火墻需要處理 NAT 轉換、策略匹配、會話建立和日志記錄。如果設備 CPU 持續(xù)接近 100%先看是不是日志量過大再看是否需要升級硬件或把 Web 服務遷移到專用負載均衡設備后面。第二是并發(fā)會話數(shù)和新建會話速率。目的 NAT 會讓每個外部請求占用一條會話表項。默認會話老化時間如果太短大文件下載或 WebSocket 長連接可能被中途斷開如果太長又可能造成會話表膨脹。生產環(huán)境建議針對 Web 服務的 TCP 會話設置合理的空閑超時并對大流量下載場景做單獨驗證。第三是帶寬和延遲。外部訪問走的如果是普通寬帶或專線實際吞吐量會直接影響頁面打開速度?？梢苑謩e在防火墻 WAN 口和下聯(lián) DMZ 口做流量統(tǒng)計確認擁塞點是在公網鏈路、防火墻轉發(fā)還是 Web 服務器本身。更穩(wěn)妥的做法是先用單用戶小文件測試再逐步加大并發(fā)不要一上來就壓測避免把業(yè)務壓掛。9. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案外網 ping 公網 IP 通但訪問端口不通NAT 沒生效或安全策略未放行防火墻查看會話表、策略命中計數(shù)補目的 NAT檢查 untrust - dmz 策略外網 curl 返回 503/502/超時Web 服務后端異?；虮O(jiān)聽地址不對內網直接訪問服務器 IP修復 Web 服務確認監(jiān)聽 0.0.0.0 或對應網卡外網可以訪問內網用公網域名訪問不了防火墻未開啟 NAT 回環(huán)在內網同一網段嘗試 curl 內網 IP通過內網 DNS 解析到內網 IP或在防火墻配置 hairpin NAT外網端口通但頁面提示應用級錯誤防火墻已經通了Web 配置問題查看應用日志和站點根路徑檢查虛擬目錄、反向路由、URL 路徑配置例如 ASP.NET 站點若報“您的 Web 服務器未正確設置以解析 /ocm-provider/”往往是站點根路徑或虛擬目錄未匹配而不是防火墻問題Web 服務器日志里沒有來自公網的訪問記錄流量沒有到達服務器抓包確認目的 IP 是否被正確轉換檢查目的 NAT 中內網 IP 是否填錯添加策略后仍被拒絕策略順序不對或被更高優(yōu)先級策略匹配查看策略命中計數(shù)調高目標策略優(yōu)先級或檢查是否存在全局 deny 策略代理設備/反向流量設備轉發(fā)后源 IP 全是防火墻地址需要保留真實客戶端 IP查看 Web 日志中的 x-forwarded-for 字段在防火墻或 Web 層配置 X-Forwarded-For 傳遞其中“內網訪問公網域名失敗”是一個很典型的問題。原因是內部用戶訪問目的地址為公網 IP 時報文從內網直接到防火墻但后續(xù)回包路徑和外部用戶的 NAT 會話不一致導致防火墻無法匹配會話。解決思路有兩種在公司內部 DNS 上把域名解析為內網服務器 IP或者開啟防火墻的 NAT 回環(huán)功能。生產環(huán)境更推薦前者邏輯清楚且不增加防火墻負擔。10. 安全加固與日常運維建議配置好外部訪問只是開始更關鍵的是控制風險。對外只開放最小端口范圍。絕大多數(shù) Web 業(yè)務只開放 443 即可80 僅用于跳轉或不開放。不推薦把 22、3389、數(shù)據(jù)庫端口 3306/5432、Redis 6379 直接映射到公網。如果有人要求“順便把服務器遠程端口也映射出去”應該直接拒絕改成通過帶外管理、堡壘機或虛擬桌面方案訪問。對管理地址做來源限制。防火墻 Web 管理界面如果暴露在公網本身就是巨大風險。華為、H3C、深信服、天融信等設備默認通常限制管理口為 trust 區(qū)域或指定源地址配置時不要為了方便而改成 all。需要遠程維護時先通過安全可控的管理通道接入內網再訪問防火墻管理地址。Web 服務器本身要注意加固。用 HTTPS 替換 HTTPTLS 協(xié)議至少啟用 1.2不要使用默認自簽名證書對外提供服務定期更新 Web 服務軟件版本防止已知漏洞被利用。日志要單獨保存方便出現(xiàn)異常訪問時追溯。外網流量接入后可以先觀察一周訪問日志看看是否存在掃描、爆破、異常路徑探測等行為再決定是否加入更嚴格的訪問控制。11. 防火墻配置變更與回滾管理第一次做這類發(fā)布不要把規(guī)則一把梭。建議按以下順序執(zhí)行先做最小范圍驗證。在測試環(huán)境或業(yè)務低峰期創(chuàng)建目的 NAT 和安全策略用外網測試機訪問確認可以打開頁面然后持續(xù)觀察 10 到 30 分鐘看是否有異常報錯。保存當前配置。大多數(shù)防火墻都有配置保存/備份功能。變更前導出一份當前配置變更后再導出一次方便快速回滾。命令行設備可以用 save、write memory、copy running-config startup-config 等命令保存Web 設備通常有“保存配置”“備份配置”按鈕。在策略中添加描述和負責人字段。網絡團隊共用一臺防火墻時如果不注明用途幾個月后沒人能說清這條 NAT 是為誰開放的。建議在規(guī)則描述中寫明業(yè)務名稱、負責人、聯(lián)系電話、過期時間。對臨時開放策略設置定時失效。如果是給客戶演示三天可以在防火墻或上層安全設備上設置策略有效時間到期自動阻斷。避免“臨時開一下”變成永久規(guī)則。12. 總結與后續(xù)擴展防火墻發(fā)布內部 Web 服務最需要理解清楚的一點是目的 NAT 負責“把公網地址翻譯成內網地址”安全策略負責“允許這條訪問鏈路通過”。兩者配合好外部互聯(lián)網主機才能穩(wěn)定訪問公司內部 Web 服務器。驗證時從本機、內網、外網、防火墻會話四個層面逐級排查基本能快速定位絕大多數(shù)問題。整個配置過程并不復雜難點在于安全邊界的把控。端口越少越好、策略越明確越好、日志越完整越好這三條會長期保護你的網絡環(huán)境。如果后續(xù)業(yè)務量增長可以在 Web 服務器前面增加一套負載均衡或 Web 應用防火墻讓外部訪問入口更專業(yè)也更容易擴展。建議先把基礎 NAT 發(fā)布流程收藏起來下次遇到類似需求時直接按清單操作。