網(wǎng)站建設(shè)與網(wǎng)頁設(shè)計如何優(yōu)化百度seo排名
目錄
1.防火墻如何處理雙通道協(xié)議？
2.防火墻如何處理NAT？
3.防火墻支持哪些NAT技術(shù)，主要應(yīng)用的場景是什么？
4.當內(nèi)網(wǎng)PC通過公網(wǎng)域名解析訪問內(nèi)網(wǎng)服務(wù)器的時候，會存在什么問題，如何解決？請詳細說明
5.防火墻使用VRRP實現(xiàn)雙機熱備會遇到什么問題，如何解決？請詳細說明
6.防火墻支持哪些接口模式，一般使用在哪些場景？
7.NAT實驗
8.雙機熱備實驗
1.防火墻如何處理雙通道協(xié)議？
FTP協(xié)議原理圖
FTP是一個典型的多通道協(xié)議，在主動模式客戶端向服務(wù)端的TCP的21號端口發(fā)起三次握手，建立控制連接，客戶端通過FTP PORT命令通知服務(wù)端自己的隨機端口為P，由服務(wù)端向客戶端的TCP PORT P 發(fā)起三次握手，建立傳輸連接其中服務(wù)端的源端口為20.
在被動模式下，客戶端向服務(wù)端的TCP 的21端口發(fā)起三次握手，建立控制連接，客戶端向服務(wù)端發(fā)送PASV命令，服務(wù)端通過Enter?PASV命令告知客戶端自己的隨機端口為M，由客戶端向服務(wù)端的TCP PORT M發(fā)起三次握手，建立傳輸連接。
安全策略存在的問題：對于類似于FTP這種雙通道協(xié)議，由于其中端口的隨機性，導致無法書寫安全策略的參數(shù)，假如對于端口參數(shù)選擇any，會使得顆粒度較大，以至于讓防火墻失去效果。
ASPF（Application Specific Packet Filter，針對應(yīng)用層的包過濾）也叫基于狀態(tài)的報文過濾，ASPF功能可以自動檢測某些報文的應(yīng)用層信息（可以理解為在雙方建立傳輸通道之前協(xié)商端口的報文）并根據(jù)應(yīng)用層信息放開相應(yīng)的訪問規(guī)則,開啟ASPF功能后，FW通過檢測協(xié)商報文的應(yīng)用層攜帶的地址和端口信息，自動生成相應(yīng)的Server-map表，用于放行后續(xù)建立數(shù)據(jù)通道的報文，相當于自動創(chuàng)建了一條精細的“安全策略”。
<USG6000V1>dis firewall server-map? ? ? ? ? ?//查看server-map表
2023-03-18 06:47:53.330
Current Total Server-map : 1
Type: ASPF, 10.1.1.3 -> 100.1.1.2:2054, Zone:---
Protocol: tcp(Appro: ftp-data), Left-Time:00:00:13
Vpn: public -> public
<USG6000V1>dis firewall session table? ? ? ? ?//查看會話表
2023-03-18 06:47:57.650
Current Total Sessions : 14
ftp VPN: public --> public 10.1.1.3:2059 +-> 100.1.1.2:21
ftp VPN: public --> public 10.1.1.3:2065 +-> 100.1.1.2:21
ftp VPN: public --> public 10.1.1.3:2049 --> 100.1.1.2:21
ftp VPN: public --> public 10.1.1.3:2063 +-> 100.1.1.2:21
ftp-data VPN: public --> public 10.1.1.3:2066 --> 100.1.1.2:2054
2.防火墻如何處理NAT？
在路由器上NAT針對多通道協(xié)議也會像防火墻那樣抓取控制進程中協(xié)商傳輸進程網(wǎng)絡(luò)參數(shù)的報文，進而生成傳輸進程返回的NAT映射（在NAT中的主要參數(shù)是IP）。
困境
某些協(xié)議會在應(yīng)用層攜帶通信ip，這個ip用于下一階段通信。但是NAT的地址轉(zhuǎn)換并不是轉(zhuǎn)應(yīng)用層IP而是轉(zhuǎn)三層IP，這就導致某些協(xié)議的通信階段在NAT場景下失敗。
這也是導致交換機一般沒有nat的主要原因。（由于NAT需要抓取控制進程的特殊報文來進行分析，從而計算出后續(xù)傳輸進程所需要的網(wǎng)絡(luò)參數(shù)，并且在發(fā)送端和接受端以及NAT后的數(shù)據(jù)需要進行校驗計算，會消耗大量的計算資源，對于設(shè)備的內(nèi)存和CPU是一個很大的考驗。由于交換機是通過硬件芯片工作的，本身計算資源有限，無法完成NAT的強大計算量，這也就是一般交換機沒有NAT的主要原因）
防火墻nat類型的server-map
<USG6000V1>dis firewall server-map
2023-03-18 08:07:54.050
Current Total Server-map : 1
Type: Nat Server, ANY -> 100.1.1.111:80[10.1.2.2:80], Zone: untrust , protoc
ol:tcp
Vpn: public -> public
3.防火墻支持哪些NAT技術(shù)，主要應(yīng)用的場景是什么？
源NAT
場景：主要應(yīng)用在內(nèi)網(wǎng)用戶沒有外網(wǎng)服務(wù)的路由時，在內(nèi)網(wǎng)用戶想要訪問外網(wǎng)的某臺服務(wù)器時，發(fā)送的數(shù)據(jù)包的源IP為自己的私網(wǎng)IP，目的IP為服務(wù)器的公網(wǎng)IP，在通過邊界路由器或者防火墻時，需要將自己的私網(wǎng)IP轉(zhuǎn)換成公有IP去訪問。服務(wù)端回包時的源IP為自己的公有IP，目的IP為私網(wǎng)用戶的公有IP。
server-nat
場景：私網(wǎng)服務(wù)器需要對外網(wǎng)用戶提供服務(wù)時；在網(wǎng)絡(luò)中無法訪問一個私網(wǎng)的用戶，當服務(wù)器處于私網(wǎng)內(nèi)部時，外部人員無法訪問；此時，就需要將內(nèi)網(wǎng)服務(wù)器的IP和服務(wù)通過server-nat映射到私網(wǎng)邊界的路由器或者防火墻的公網(wǎng)IP。讓外網(wǎng)人員通過訪問邊界設(shè)備的公有IP來達到訪問內(nèi)網(wǎng)服務(wù)器的目的。
域間雙向轉(zhuǎn)換
場景：假設(shè)內(nèi)網(wǎng)服務(wù)器只允許內(nèi)網(wǎng)用戶訪問，但是由于某種特殊要求，現(xiàn)在需要外網(wǎng)用戶對內(nèi)網(wǎng)服務(wù)器也發(fā)起訪問，就需要在訪問的時候?qū)?strong>源目IP都進行NAT。
域內(nèi)雙向轉(zhuǎn)換
場景：假設(shè)內(nèi)網(wǎng)有一臺服務(wù)器，在內(nèi)網(wǎng)用戶想要去訪問的時候，一般先去DNS服務(wù)器解析出服務(wù)器的IP地址，在服務(wù)映射的情況下，向外提供的是公網(wǎng)IP，所以在內(nèi)網(wǎng)用戶訪問的時候也是使用公網(wǎng)IP訪問，就需要在做域內(nèi)雙向轉(zhuǎn)換。
雙出口nat
場景：某個企業(yè)使用兩條運營商的寬帶；需要將屬于某個運營商的網(wǎng)段進行nat然后與該運營商的下一跳進行關(guān)聯(lián)，就不會出現(xiàn)nat轉(zhuǎn)換錯亂的問題。?
4.當內(nèi)網(wǎng)PC通過公網(wǎng)域名解析訪問內(nèi)網(wǎng)服務(wù)器的時候，會存在什么問題，如何解決？請詳細說明
場景：私網(wǎng)內(nèi)部有一臺服務(wù)器提供服務(wù)（192.168.56.63），現(xiàn)私網(wǎng)內(nèi)部人員（192.168.1.15）通過DNS解析出來的地址去訪問私網(wǎng)服務(wù)器，由于DNS解析出的地址為公有IP（14.2.23.5）；
轉(zhuǎn)換前數(shù)據(jù)包格式：
源IP：192.168.1.15? ? ? ? ?目IP:14.2.23.5
如果只是在簡單的server-nat下，只會轉(zhuǎn)換目的IP
轉(zhuǎn)換后數(shù)據(jù)包格式：
源IP：192.168.1.15? ? ? ? 目IP：192.168.56.63
在服務(wù)端回包時，會按照轉(zhuǎn)換后的數(shù)據(jù)包進行回包，但接收方（客戶端）收到的報文格式與本端發(fā)送時不一致，就回丟棄該報文，導致雙方通信失敗。
解決方法：域間雙向nat
轉(zhuǎn)換前數(shù)據(jù)包格式：
源IP：192.168.1.15? ? ? ? ? ? ? ? ? ? ? ? ? 目IP:14.2.23.5
轉(zhuǎn)換后數(shù)據(jù)包格式：
源IP：14.2.23.6（公網(wǎng)池地址）? ? ? ?目IP：192.168.56.63
發(fā)包和收包報文格式一致，雙方正常通訊。
5.防火墻使用VRRP實現(xiàn)雙機熱備會遇到什么問題，如何解決？請詳細說明
出現(xiàn)的問題：假設(shè)上面的防火墻為PC1的主網(wǎng)關(guān)，下面為備網(wǎng)關(guān)。當PC的數(shù)據(jù)流來到上面的防火墻時，查詢會話表，未果后查詢策略表，若命中創(chuàng)建會話表，后續(xù)報文基于會話表轉(zhuǎn)發(fā)。但是當主網(wǎng)關(guān)左側(cè)線路斷掉的話，因為VRRP的存在會將PC 的網(wǎng)關(guān)切換到下面的一臺防火墻，但是由于下面一臺防火墻沒有會話表，又沒有首包可以創(chuàng)建，故導致數(shù)據(jù)轉(zhuǎn)發(fā)失敗。由于數(shù)據(jù)包一般要求來回路徑一致，回包此時發(fā)往上面的防火墻，也會導致數(shù)據(jù)轉(zhuǎn)發(fā)失敗。
解決辦法：使用VGMP進行統(tǒng)一管理，防火墻兩側(cè)線路狀態(tài)需要一致。?
VGMP-------統(tǒng)一組管理協(xié)議，將VRRP組進行統(tǒng)一管理，在開啟搶占的時候統(tǒng)一由VGMP進行管理，看是否需要切換。
在主備防火墻之間使用線路連接，俗稱“心跳線”，負責主備網(wǎng)關(guān)之間的配置同步（包括會話表，安全策略，路由情況等）
6.防火墻支持哪些接口模式，一般使用在哪些場景？
- 路由模式 --- 以第三層對外連接（接口具有IP 地址）
- 交換模式 --- 通過第二層對外連接（接口無IP 地址）
- 旁路模式 --- 該接口一般用于接收鏡像流量，向主機一樣旁觀在設(shè)備上。通過旁觀設(shè)備的端口鏡像技術(shù)收集流量給旁路接口，這個場景防火墻可以做IPS，審計，流量分析等任務(wù)。
- 接口對模式 --- 加快接口的轉(zhuǎn)發(fā)效率（不需要查看MAC地址表）
7.NAT實驗
1.源nat
抓包分析：
2.server-nat
測試：?
3.域內(nèi)雙向nat??
抓包分析：
?4.域間雙向nat
?抓包分析：
8.雙機熱備實驗
創(chuàng)建心跳接口----端口聚合
?配置主防火墻
?
查看當前狀態(tài)
?
備防火墻
?
查看備防火墻的同步配置
?
雙機熱備測試
關(guān)閉主防火墻的1/0/0口進行測試，在備防火墻的接口上抓包，觀察有流量通過
