您好,登錄后才能下訂單哦!
pfsync概述
pfSense XML-RPC配置同步概述
冗余配置示例
HA與多WAN
驗證故障轉移功能
提供無NAT的冗余
第2層冗余
高可用與橋接
使用IP別名減少心跳流量
接口
故障排查
pfSense的高可用性通過以下特性的組合來實現:
CARP用于IP地址冗余
XMLRPC用于配置同步
pfsync用于狀態表同步
通過這種配置,單元充當“主動/被動”群集,主節點作為主單元,輔助節點作為備用角色,如果主節點發生故障,則會根據需要接管。
雖然經常被錯誤地稱為“CARP群集”,但由于CARP只是pfSense實現高可用性的幾種技術之一,因此兩個或多個冗余pfSense防火墻更適合稱為“高可用性群集”或“HA群集”,未來的CARP可以交換為不同的冗余協議。
每個群集節點上的一個接口將專門用于同步任務。這個接口通常稱為“Sync”接口,用于配置同步和pfsync狀態同步。任何可用的接口都可以用于“Sync”。
注意
有人稱之為“CARP”接口,這是不正確的,而且非常具有誤導性。 CARP心跳發生在與CARP VIP的每個接口上; CARP流量和故障轉移操作不使用Sync接口。
最常見的高可用性群集配置僅包含兩個節點。 群集中有更多的節點也是可以的,但它們顯然不具有特別的優勢。
區分三種功能(IP地址冗余,配置同步和狀態表同步)非常重要,因為它們發生在不同的地方。 配置同步和狀態同步發生在同步接口上,直接在防火墻單元之間進行通信。 CARP心跳在每個接口上與CARP VIP一起發送。 故障轉移信號不會發生在同步接口上,而是發生在每個啟用CARP的接口上。
共用地址冗余協議(CARP)由OpenBSD開發人員創建,作為免費的開放式冗余解決方案,用于在一組網絡設備之間共享IP地址。在此之前已經有類似的解決方案,主要是IETF虛擬路由器冗余協議(VRRP)標準。然而,思科聲稱VRRP已經被它的熱備用路由器協議(HSRP)的專利覆蓋,并告知OpenBSD開發人員它將執行其專利權利。因此,OpenBSD開發人員創建了一個新的免費開放協議,在不侵犯思科專利的情況下實現基本相同的效果。 CARP于2003年10月在OpenBSD上投入使用,后來又被添加到FreeBSD中。
CARP類型虛擬IP地址(VIP)在群集的節點之間共享。一個節點是主節點,接收IP地址的流量,其他節點保持備份狀態并監視心跳,以查看并確認主節點發生故障時是否需要承擔主節點角色。由于一次只有一個群集成員正在使用IP地址,因此CARP VIP不會發生IP地址沖突。
為了使故障轉移正常工作,必須將進入群集的入站和出站流量(例如路由上游流量,×××,NAT,本地客戶端網關,DNS請求等)通過CARP VIP進行傳遞,例如出站NAT將從CARP VIP發送。如果流量直接發往某個節點,而不是CARP VIP,則該流量不會被其他節點接收。
CARP與VRRP和HSRP類似,在某些情況下有可能會發生沖突。在包含CARP VIP的每個接口上發送心跳,每個VIP每個接口一個心跳。在默認的偏離值和基準值下,VIP每秒發出一次心跳。偏離值確定哪個節點在給定時間點是主節點。無論哪個節點傳輸心跳,更快的那個都會承擔主節點角色。較高的偏離值會導致心跳傳輸延遲增加,因此具有較低偏離值的節點將成為主節點設備,除非網絡或其他問題導致心跳延遲或丟失。
注意
切勿使用CARP VIP訪問防火墻GUI、SSH或其他。 出于管理的目的,只能在每個單獨節點的接口上使用實際的IP地址,而不要使用VIP。 否則,不能事先確定正在訪問哪個節點單元。
使用CARP的高可用性群集需要每個子網中有三個IP地址,并且Sync接口需要單獨的未使用子網。 對于廣域網,這意味著最佳配置需要大于或等于29個子網。 每個節點使用一個IP地址,另外還有一個共享的CARP VIP地址用于故障轉移。 同步接口每個節點只需要一個IP地址。
在技術上可以將CARP VIP接口配置為給定子網中唯一的IP地址,但通常不建議這樣做。在WAN上使用時,這種類型的配置將只允許從主節點到WAN的通信,這會使任務(如更新、插件安裝、網關監控或任何需要輔助節點的外部連接的任務)變得非常復雜。它可能更適合用于內部接口,但內部接口通常不會受到與WAN相同的IP地址限制,因此仍然最好在所有節點上配置IP地址。
CARP心跳線利用多點傳送,并且可能需要對集群涉及的交換機進行特殊處理。 一些交換機會以可能導致CARP失敗的方式過濾、限速或以其他方式干擾組播。 另外,一些交換機使用端口限制方法,這些方法可能導致CARP無法正常工作。
因此交換機必須:
允許發送和接收多播流量,不能干擾使用CARP VIP的端口。
允許使用多個MAC地址發送和接收流量。
允許CARP VIP MAC地址在端口之間移動。
幾乎所有CARP未能正確反映預期狀態的問題都是交換機故障或其他第2層問題,因此在繼續之前請確保交換機已正確配置。
pfsync可以使群集節點之間的防火墻狀態表保持同步。主防火墻上狀態表的修改會通過Sync接口發送到輔助防火墻,反之亦然。當pfsync處于活動狀態并正確配置時,所有節點都將了解流經群集的每個連接。如果主節點發生故障,則備份節點將接管并且客戶端不會注意到發生了轉換,因為兩個節點都事先知道連接。
pfsync在默認情況下使用多點傳送,但可以定義IP地址以強制單點傳送更新,以便只有兩個防火墻的多點傳送流量無法正常運行。任何活動接口都可用于發送pfsync更新,但使用專用接口更有利于安全性和性能。 pfsync不支持任何身份驗證方法,因此如果使用除專用接口以外的其他任何方法,則任何具有本地網絡訪問權的用戶都可以將狀態插入到狀態表中。在低安全性要求的低吞吐量環境中,使用LAN接口是可以接受的。這種狀態同步所需的帶寬在不同環境之間會有很大差異,但根據網絡中狀態的插入和刪除速率,可能會高達穿越防火墻吞吐量的10%。
故障轉移仍然可以在沒有pfsync的情況下運行,但不會無縫連接。沒有pfsync,如果一個節點失敗,另一個接管,用戶連接將被丟棄。用戶可以立即通過另一個節點重新連接,但在轉換過程中它們會中斷。根據特定環境中的使用情況,這可能會被忽視,或者可能是一個重要但短暫的中斷。
當使用pfsync時,必須在參與狀態同步的所有節點(包括輔助節點)上啟用pfsync設置,否則將無法正常運行。
必須在Sync接口上制定允許pfsync通信的規則。 該規則必須將來自Sync網絡源的pfsync協議傳遞到任何目標。 通過任何協議的所有流量的規則也允許所需的流量,但一般來說,更具體的規則會更加安全。
pfSense中的狀態綁定到特定的系統接口。 例如,如果WAN是em0,那么WAN上的狀態將與em0綁定。 如果群集節點具有相同的硬件和接口分配,則按預期工作。 在使用不同硬件的情況下,可能會有問題。 如果一個節點上的WAN是em0,但另一個節點上的WAN是igb0,那么這些狀態將不匹配,并且它們不會被視為相同。
最好使用相同的硬件,但也可能不能滿足實際的需要。有一個解決方法:將接口添加到LAGG,脫離底層物理接口,因此在上面的示例中,廣域網將在兩者上都是lagg0,狀態將被綁定 到lagg0,盡管lagg0在一個節點上包含em0,并且在另一個節點上包含igb0。
通常pfSense都允許防火墻在線升級,而不會造成網絡中斷。 但不是每次升級都是如此,因為pfsync協議可以更改以適應其他功能。 在升級之前,始終檢查所有發布通告中鏈接的升級指南,以查看是否有任何CARP用戶的特殊注意事項。
為了將維護防火墻節點的工作變得更容易,可以使用XML-RPC進行配置同步。啟用XML-RPC同步時,支持區域的設置將同步復制到輔助設備,并在每次更改配置后激活。 XMLRPC同步是可選的,但如果沒有它,維護一個集群的工作量要大的多。
某些區域設置無法同步,如接口配置,但更多的區域都可以同步:包括防火墻規則、別名、用戶、證書、×××、DHCP、路由、網關等。作為一般規則,特定于硬件或特定安裝的項目(例如系統>常規或系統>高級設置下的接口或值)不會同步。受支持區域的列表可能因使用的pfSense版本而有所差別。大多數插件不會同步,但有些插件包含自己的同步設置。有關更多詳細信息,請參相關文檔。
配置同步應使用Sync接口,如果沒有專用的Sync接口,請使用為pfsync配置的相同接口。
在雙節點群集中,只能在主節點上啟用XML-RPC設置,輔助節點必須禁用XML-RPC設置。
為使XML-RPC正常工作,兩個節點都必須使GUI運行在相同的端口和協議上,例如:端口443上的HTTPS(默認設置)。管理員帳戶不能被禁用,并且兩個節點必須具有相同的管理員帳戶密碼。
本節介紹一個簡單的三接口HA配置。 這三個接口是LAN,WAN和Sync。 這在功能上等同于兩個接口LAN和WAN部署,pfsync接口僅用于同步主防火墻和輔助防火墻之間的配置和防火墻狀態。
注意
本示例僅涵蓋IPv4配置。 高可用性與IPv6兼容,但它需要在防火墻接口上進行靜態尋址。 準備配置HA時,如果靜態IPv6分配不可用,請在所有接口上將IPv6設置為無。
第一項任務是規劃IP地址分配。 一個好的策略是使用子網中最低可用的IP地址作為CARP VIP,將下一個后續IP地址用作主防火墻接口IP地址,并將下一個IP地址用作輔助防火墻接口IP地址。 這種策略是可選的,你可以使用任何方案,但我們強烈建議使用一致且合理的方案來簡化設計和管理。
WAN地址將從ISP分配的地址中選擇。 如“WAN IP地址分配表”所示,HA的WAN子網為198.51.100.0/24,地址198.51.100.200至198.51.100.202將用作WAN IP地址。
IP 地址 | 作用 |
---|---|
198.51.100.200/24 | CARP共享IP地址 |
198.51.100.201/24 | 主節點 WAN IP 地址 |
198.51.100.202/24 | 輔助節點 WAN IP 地址 |
LAN子網是192.168.1.0/24。 在本例中,LAN IP地址將按照“LAN IP地址分配表”中所示進行分配。
IP 地址 | 作用 |
---|---|
192.168.1.1/24 | CARP共享IP地址 |
192.168.1.2/24 | 主節點 LAN IP 地址 |
192.168.1.3/24 | 輔助節點 LAN IP 地址 |
這個接口上沒有共享的CARP VIP,因為不需要。 這些IP地址僅用于防火墻之間的通信。 在本例中,172.16.1.0/24用作Sync子網。 將只使用兩個IP地址,但掩碼(/ 24)與其他內部接口(LAN)保持一致。 對于IP地址的最后八位字節,請使用與該防火墻的LAN IP地址相同的最后八位字節以保持一致。
IP 地址 | 作用 |
---|---|
172.16.1.2/24 | 主節點 Sync IP 地址 |
172.16.1.3/24 | 輔助節點 Sync IP 地址 |
下圖顯示了此示例HA的結構。 主節點和輔助節都有與WAN和LAN相同的連接,并且它們之間使用交叉電纜連接Sync接口。 在這個例子中,廣域網交換機和局域網交換機仍然存在潛在的單點故障。 交換機冗余將在本章后面的第2層冗余中介紹。
每個節點都需要實際HA設置以外的一些基本配置。 在兩個節點都沒有沖突的LAN設置之前,請勿將兩個節點都連接到同一個LAN中。
在防火墻上安裝操作系統,并在兩個節點上以相同方式分配接口。 接口必須在所有節點上按照相同的順序進行分配。 如果接口未對齊,配置同步和其他任務將無法正常工作。 如果對接口分配進行了任何調整,則必須在兩個節點上進行相同的復制。
然后,連接到GUI并使用安裝向導為每個防火墻配置唯一的主機名和非沖突的靜態IP地址。
例如,一個節點可以是“firewall-a.example.com”,另一個節點可以是“firewall- b.example.com”,也可以是更加個性化的一對名稱。
注意
避免將節點命名為“master”或“backup”,因為這些是防火墻默認使用的狀態,可以將他們命名為“primary”和“secondary”。
默認的LAN IP地址是192.168.1.1。 每個節點必須使用它自己的地址,例如主節點使用192.168.1.2,輔助節點使用192.168.1.3。 該布局顯示在LAN IP地址分配中。 一旦每個節點具有唯一的LAN IP地址,則兩個節點都可以插入同一個LAN交換機。
在繼續之前,必須配置群集節點上的Sync接口。 同步IP地址分配列出了用于每個節點上的同步接口的地址。 在主節點上完成設置后,再在輔助節點上進行設置。
完成Sync接口配置后,還必須在兩個節點上將添加防火墻規則以允許他們之間進行同步。
防火墻規則必須允許通過配置同步(默認情況下,HTTPS使用的443端口)和pfsync在兩個節點之間的通信。 可以使用簡單的“全部允許”樣式規則。
下圖是配置完成的防火墻規則列表,其中還包含允許ICMP(ping)用于診斷目的的規則。
輔助節點并不需要這些規則,只需要有一條規則允許流量通過GUI來使XML-RPC運行。 一旦配置了XML-RPC,主節點的全部規則就會同步到輔助節點。
必須在主節點和輔助節點上配置使用pfsync的狀態同步才能正常工作。
首先在主節點上,然后在輔助節點上執行以下操作:
導航到系統>高可用性同步(雙機備份)
設置同步狀態
將同步接口設置為SYNC
將pfsync同步對等IP到另一個節點。 配置主節點時設置為172.16.1.3,配置輔助節點時設置為172.16.1.2
點擊保存
警告
配置同步只能在主節點上配置。 輔助節點不能也不需要配置。
在主節點上執行以下操作:
導航到系統>高可用性同步
將“同步配置”下的“配置同步目標IP”設置為為輔助節點同步接口IP地址172.16.1.3
將遠程系統用戶名設置為admin。
注意
用戶名必須是“admin”,其他用戶名不會正常工作!
將遠程系統密碼設置為管理員用戶帳戶密碼,并在確認框中重復輸入。
選中需要進行同步區域的復選框以同步到輔助節點。 全部切換按鈕用于一次選擇所有選項。
點擊保存
快速確認后,進入輔助節點的防火墻>規則策略列表,可以看到主節點輸入的規則已經被同步過來了。
這兩個節點已連接并進行配置同步! 每當在主節點上進行修改后,所做的更改將很快同步到輔助節點。
警告
不要在輔助節對設置同步的區域進行任何更改! 下次主節點執行同步時,這些選項將被覆蓋。
通過配置同步,CARP虛擬IP地址只需添加到主節點,并且它們將自動同步到輔助節點。
導航到主節點上的防火墻>虛擬IPs,設置CARP VIP
單擊右側的 按鈕在列表頂部添加新的VIP。
注意
必須為處理用戶流量的每個接口添加一個VIP,在本示例中,要為WAN和LAN各添加一個。類型:定義VIP的類型,在這種情況下CARP。
接口: 定義VIP將駐留的接口,例如WAN
地址: 地址框是為VIP輸入IP地址值的位置。 還必須選擇子網掩碼,并且它必須與接口IP地址上的子網掩碼相匹配。 在本例中,輸入198.51.100.200和24(請參閱WAN IP地址分配)。
虛擬 IP密碼: 設置CARP VIP的密碼。 這只需要兩個節點之間的匹配,這將通過同步來處理。 密碼和確認密碼框必須填寫并且必須匹配。
VHID 組: 定義CARP VIP的ID一個常見的策略是使VHID匹配IP地址的最后一個字節,因此在這種情況下選擇200
廣播頻率: 確定CARP心跳發送的頻率。
Base(基本值):控制Heartbeats之間經過的整秒數,通常為1.這應該在群集節點之間匹配。Skew(偏離值):控制秒的分數(1/256增量)。 主節點通常設置為0或1,次節點將為100或更高。 該調整由XML-RPC同步自動處理。
描述:一些文本可以識別VIP,例如WAN CARP VIP。
注意
如果CARP對給定網絡的延遲過于敏感,建議一次調整基本值一秒鐘,直到穩定為止。
以上描述以WAN VIP為例。 LAN VIP也進行類似配置,但它將使用LAN接口,地址為192.168.1.1(請參閱LAN IP地址分配)。
如果WAN子網中有任何額外的IP地址用于1:1 NAT、端口轉發、×××等,也可以在這里進行添加。
編輯完成后,點擊應用更改。
添加VIP后,請檢查輔助節點上的防火墻>虛擬IPs,以確保VIP按預期進行了同步。
如果同步成功,兩個節點上的虛擬IP地址將如下圖所示。
下面將配置NAT,以便LAN上的客戶端使用共享的WAN IP訪問廣域網。
導航到防火墻> NAT(地址轉換),出站選項卡
單擊選中手動出站NAT規則生成
點擊保存
將出現一組與自動出站NAT適用的規則。 調整內部子網源的規則,以改為使用CARP IP地址。
在規則的右側單擊 進行編輯
找到頁面的轉換部分
從地址下拉列表中選擇WAN CARP VIP地址
更改描述以提及此規則將NAT LAN連接到WAN CARP VIP地址
警告
如果稍后添加其他本地接口(如第二個LAN,DMZ等),并且該接口使用私有IP地址,則必須在此時添加其他手動出站NAT規則。
完成后,規則更改將與使用CARP VIP的LAN出站NAT規則中的規則更改類似。
群集節點上的DHCP服務器設置需要調整,以便它們可以一起工作。 這些修改將從主節點同步到輔助節點,因此對于VIP和出站NAT,這些修改只需要在主節點上進行。
導航到系統服務> DHCP服務器,LAN 選項卡。
將DNS服務器設置為LAN CARP VIP,此處為192.168.1.1
將網關設置為LAN CARP VIP,此處為192.168.1.1
將故障轉移對等IP設置為輔助節點的實際LAN IP地址,此處為192.168.1.3
點擊保存
將DNS服務器和網關設置為CARP VIP可確保本地客戶端與故障轉移地址通信,而不是直接通向任一節點。 如果主節點失敗,本地客戶端將繼續與輔助節點通話。
故障轉移對等IP允許守護程序直接在此子網中與對等方進行通信,以交換租賃信息等數據。 當設置與輔助設備同步時,會自動調整該值,以便輔助設備指向主設備。
HA還可以在多WAN配置中用于防火墻冗余。 本節詳細介紹雙WAN HA部署所需的VIP和NAT配置。
在這個例子中,每個WAN上將使用四個IP地址。 每個防火墻需要一個IP地址,另外還有一個CARP VIP用于出站NAT,另外還有一個CARP VIP用于1:1 NAT條目,該條目將用于DMZ段中的內部郵件服務器。
下表顯示了兩個WAN的IP地址。 在大多數環境中,這些將是公共IP地址。
IP 地址 | 作用 |
---|---|
198.51.100.200 | 用于出站NAT的共享CARP VIP |
198.51.100.201 | 主節點防火墻 WAN |
198.51.100.202 | 輔助節點防火墻 WAN |
198.51.100.203 | 用于1:1 NAT的共享CARP VIP |
IP 地址 | 作用 |
---|---|
203.0.113.10 | 用于出站NAT的共享CARP VIP |
203.0.113.11 | 主節點防火墻 WAN2 |
203.0.113.12 | 輔助節點防火墻 WAN2 |
203.0.113.13 | 用于1:1 NAT的共享CARP VIP |
LAN子網是192.168.1.0/24。 在這個例子中,LAN IP地址將被分配如下。
IP 地址 | 作用 |
---|---|
192.168.1.1 | CARP共享LAN VIP |
192.168.1.2 | 主節點防火墻LAN |
192.168.1.3 | 輔助節點防火墻 LAN |
DMZ子網是192.168.2.0/24。 地址分配見下表。
IP 地址 | 作用 |
---|---|
192.168.2.1 | CARP共享DMZ VIP |
192.168.2.2 | 主節點防火墻 DMZ |
192.168.2.3 | 輔助節點防火墻 DMZ |
這個接口上不會有共享的CARP VIP,因此不需要設置。 這些IP地址僅用于防火墻之間的通信。 在本例中,172.16.1.0/24將作為Sync子網。 使用兩個IP地址,子網掩碼與其他內部接口一致。
IP 地址 | 作用 |
---|---|
172.16.1.2 | 主節點防火墻 Sync |
172.16.1.3 | 輔助節點防火墻 Sync |
使用HA與多WAN時的NAT配置與使用單個WAN的HA相同。 確保只有CARP VIP用于入站流量或路由。 有關NAT配置的更多信息,請參閱相關文檔。
使用多WAN時,必須設置防火墻規則,以使用默認網關將流量傳遞到本地網絡。 否則,當流量嘗試到達CARP地址或從LAN到DMZ時,它將轉而出去與WAN連接。
必須在所有內部接口的防火墻規則頂部添加一條規則,該規則將所有本地網絡的流量引導至默認網關。 必須注意使用默認網關,而不是故障轉移或負載平衡網關組之一。 此規則的目的地是本地LAN網絡,或包含任何本地可達網絡的別名。
由于附加的廣域網和DMZ元素,這種布局的圖表要復雜得多,如下圖所示。
由于使用HA涉及高可用性,因此在將群集投入生產之前應該進行徹底的測試。 測試最重要的部分是確保HA系統在系統中斷期間能夠正常故障切換。
如果本節中的任何操作不能按預期正常工作,請參閱高可用性故障排除。
在這兩個系統上,導航到系統狀態> CARP(故障轉移)。 如果一切工作正常,主節點設備所有CARP VIP狀態將顯示為MASTER,輔助節點設備將顯示為BACKUP。
如果其中一個顯示DISABLED,請單擊啟用CARP按鈕,然后刷新頁面。
如果一個接口顯示 INIT,則意味著包含CARP VIP的接口沒有連接。 將接口連接到交換機,或者至少連接到其他節點。 如果該接口不使用,請從接口上移除CARP VIP,因為這會干擾正常的CARP操作。
導航到輔助節點上的主要位置,例如防火墻>規則策略和防火墻> NAT(地址轉換),確保在主節點上創建的規則正在同步到輔助節點。
如果配置了DHCP故障切換,則可以在系統狀態> DHCP租約中檢查它的狀態。 包含DHCP故障轉移池狀態的頁面頂部將出現一個新的部分,如下圖所示。
現在進行真正的故障轉移測試。在開始之前,請確保LAN上的CARP后面的本地客戶端可以連接到互聯網,同時pfSense防火墻在線運行。一旦確認可以正常工作,那么現在是進行備份的好時機。
實際測試時,請從網絡上拔下主節點或暫時關閉主節點。客戶端將能夠通過輔助節點繼續從Internet加載內容。在輔助節點上再次檢查狀態> CARP(故障轉移),它現在將報告它是LAN和WAN CARP VIP的MASTER。
現在將主節點重新聯機,它將恢復為MASTER的角色,并且輔助節點系統將自己降級到BACKUP。在這個過程中的任何時候,互聯網連接仍然是可以正常工作的。
在盡可能多的故障情況下測試HA。其他測試包括:
拔下WAN或LAN上的網線
拔下主電源插頭
使用臨時禁用功能和維護模式禁用主節點上的CARP
單獨測試每個系統(關閉輔助節點電源,然后重新接通電源并關閉主電源)
在故障轉移期間下載文件或嘗試傳輸音頻/視頻流
在故障轉移期間,向Internet主機運行連續的ICMP回應請求(ping)
如前所述,只有CARP VIP為防火墻直接處理的地址提供冗余,并且它們只能與NAT或防火墻本身的服務一起使用。 冗余還可以為具有HA的路由公共IP子網提供冗余。 本節介紹這種類型的配置,這在大型網絡、ISP和無線ISP網絡以及數據中心環境中很常見。
pfSense的WAN端至少需要一個/ 29的公共IP范圍,它提供了六個可用的IP地址。 兩個防火墻部署只需要三個,但這是容納三個IP地址的最小IP子網。 每個防火墻都需要一個IP,并且WAN端至少需要一個CARP VIP。
第二個公共IP子網將通過ISP、數據中心或上游路由器路由到CARP VIP。 由于此子網路由到CARP VIP,因此路由不會依賴于單個防火墻。 對于本章中所描述的示例配置,將使用/ 24公共IP子網,并將其分成兩個/ 25個子網。
這里描述的示例網絡是一個數據中心環境,由兩個pfSense防火墻組成,每個防火墻有四個接口:WAN、LAN、DBDMZ和pfsync。 該網絡包含許多網絡和數據庫服務器。 它不是基于任何真實的網絡,但會有類似這樣的實例部署。
WAN側連接到上游網絡,即ISP、數據中心或上游路由器。
該網絡中的網段使用“LAN”接口,但已重命名。 它包含Web服務器,所以它被命名為WEB,但可以稱為DMZ,SERVERS或任何所需的東西。
該段是一個OPT接口并包含數據庫服務器。 在托管環境中,將網絡和數據庫服務器分隔成兩個網絡是很常見的。 數據庫服務器通常不需要從互聯網直接訪問,因此不受Web服務器的危害影響。
此圖中的同步網絡用于通過XML-RPC同步pfSense配置的修改,以及pfsync同步兩個防火墻之間的狀態表修改。 建議使用專用接口。
網絡拓撲如下圖所示,包括所有可路由的IP地址、WEB網絡和數據庫DMZ。
注意
包含數據庫服務器的網段通常不需要公開訪問,因此更常用的是使用私有IP子網,但可以使用此處說明的示例,而不考慮兩個內部子網的功能。
本節介紹規劃冗余網絡時要考慮的第2層設計元素。 本章假定只部署兩個系統,當然也可以根據需要擴展到更多的部署。
如果兩個冗余pfSense防火墻都接入到同一臺交換機任何接口上,則該交換機將成為單點故障。 為了避免這種單點故障,最好的選擇為每個接口部署兩個交換機(除了專用的pfsync接口)。
下圖以網絡為中心,未顯示交換機基礎結構。 具有冗余交換機的HA圖圖解釋了該環境如何與冗余交換機基礎架構配合使用。
使用多個交換機時,交換機應互連。 只要兩臺交換機之間有單一連接,并且任何一臺防火墻上都沒有網橋,對任何類型的交換機來說都是安全的。 在使用橋接的情況下,或者在交換機之間存在多個互連的情況下,必須小心避免第2層環路。 如果是這種情況,就需要一個管理型交換機,它能夠使用生成樹協議(STP)來檢測和阻塞會產生交換機環路的端口。 當使用STP時,如果活動鏈路斷路,例如交換機故障,那么備份鏈路可以自動提交到它的位置。
pfSense還支持lagg(4)鏈路聚合和鏈路故障切換接口,允許將多個網絡接口插入一個或多個交換機以提高容錯能力。 有關配置鏈路聚合的更多信息,請參閱LAGG(鏈路聚合)。
獲得防火墻內關鍵系統的主機冗余比較困難。 每個系統都可以使用兩個網卡,使用鏈路聚合控制協議(LACP)或類似的供應商特定功能連接到每組交換機。 服務器也可以有多個網絡連接,并且根據操作系統,可以在一組服務器上運行CARP或類似的協議,以便它們形成相互冗余。
當試圖設計一個完全冗余的網絡時,會許多單點故障會被忽略。需要考慮的事情比簡單的交換機故障要多得多。以下是一些常見的冗余示例:
為每個冗余段提供隔離電源。
為冗余系統使用單獨的斷路器。
使用多個UPS/發電機。
使用多個電力供應商,盡可能進入建筑物的兩側。
即使是多WAN配置也不能保證Internet正常運行。
使用多種互聯網連接技術(DSL,Cable,Fiber,Wireless)。
如果任何兩個運營商使用相同的光纖/隧道/路徑,他們都可能同時被淘汰。
備份冷卻,冗余冷水機組或便攜式/應急空調。
考慮將第二套冗余設備放置在另一個房間,另一個樓層或另一個建筑物中。
在城鎮或其他城市的另一部分有重復的設置。
我聽說火星上的主機價格便宜,但延遲是殺手級的。
高可用性目前不兼容本地橋接。
如果某個網段上有大量的CARP VIP,則會導致很多組播流量。 每個CARP VIP每秒發送一次心跳。 為了減少這種流量,額外的VIP可以在接口上的一個CARP VIP上“堆疊”。 首先,選擇一個CARP VIP作為接口的“主要”VIP。 然后,將同一子網中的其他CARP VIP更改為IP別名類型VIP,選擇“主”CARP VIP接口作為它們在VIP配置上的接口。
這不僅減少了在給定細分受眾中看到的心跳,而且還會導致所有IP別名VIP與“主”CARP VIP一起更改狀態,從而降低第2層問題,減少故障轉移出現問題的概率。
IP別名VIP通常不會通過XML-RPC配置同步進行同步,但是,以這種方式設置為使用CARP接口的IP別名VIP將會進行同步。
如果在與HA的單個接口上需要多個子網,則可以使用IP別名來完成。 與主接口IP地址一樣,我們建議每個防火墻在附加子網內都有一個IP地址,每個子網總共至少有三個IP。 必須將單獨的IP別名條目添加到新子網內的每個節點,以確保其子網掩碼與新子網的實際子網掩碼相匹配。 直接在接口上的IP別名VIP不同步,安全可以得到保證。
一旦將IP別名VIP添加到兩個節點以在新子網中獲得立足點,則可以使用來自新子網的IP地址添加CARP VIP。
只要不需要附加子網和兩個獨立HA節點之間的通信,就可以省略IP別名,并直接在另一個子網中使用CARP VIP。
高可用性配置相對復雜,且有許多不同的方式來配置故障轉移群集。在本節中,一些常見(不常見)的問題在大多數情況下討論并有望解決。如果在咨詢本節后問題仍然存在,那么在pfSense論壇上有專門的CARP / VIPs討論區。
在繼續之前,請花時間檢查HA群集的所有成員以確保它們具有一致的配置。通常,這有助于通過示例設置,仔細檢查所有正確的設置。在輔助節點上重復該過程,并注意輔助節點上配置不同的地方。請務必檢查CARP狀態(檢查CARP狀態),并確保所有集群成員都啟用CARP。
系統狀態>系統日志,系統選項卡會記錄與HA有關的錯誤。檢查涉及的每個系統上的日志,看看是否有任何與XMLRPC同步、CARP狀態轉換或其他相關錯誤的信息。
有三種常見的錯誤配置會阻止HA正常工作。
在給定接口或廣播域上創建的每個CARP VIP上必須使用不同的VHID。 使用單個HA時,輸入驗證將防止重復的VHID。 不過,也不總是那么簡單。 CARP是一種組播技術,因此在同一網段上使用CARP的任何內容都必須使用唯一的VHID。 VRRP也使用與CARP類似的協議,因此確保與VRRP VHID沒有沖突,例如ISP或本地網絡中的其他路由器正在使用VRRP。
最好的解決方法是使用一組獨特的VHID。 如果正在使用已知安全的專用網絡,請從1開始編號。在VRRP或CARP發生沖突的網絡上,咨詢該網絡的管理員以查找空閑區域的VHID。
檢查所涉及的系統是否正確同步時間并具有有效時區,尤其是在虛擬機中運行時。 如果時間相差太大,某些同步任務(如DHCP故障切換)將無法正常工作。
真正的子網掩碼必須用于CARP VIP,而不是/ 32。 這必須與分配CARP IP的接口上的IP地址的子網掩碼相匹配。
CARP VIP所在的接口在使用前必須已經在接口(VLAN,LAN,WAN,OPT)上直接定義了另一個IP。
如果CARP在出現此錯誤時無法正常工作,則可能是配置不匹配。 確保對于給定的VIP、VHID、密碼和IP地址/子網掩碼都匹配。
如果設置正確,并且在生成此錯誤消息時CARP仍不起作用,那么在同一廣播域中可能會有多個CARP實例。 使用tcpdump(數據包捕獲)禁用CARP并監控網絡,以檢查其他CARP或類似CARP的流量,并適當調整VHID。
如果CARP工作正常,并且系統啟動時此消息在日志中,則可以忽略它。 只要CARP繼續正常工作(主節點顯示MASTER,輔助節點顯示BACKUP狀態),啟動時就會看到此消息是正常的。
如果輔助節點無法從主節點收到CARP廣播,則會發生這種情況。 檢查防火墻規則、連接、交換機配置。 同時檢查系統日志是否有可能導致解決方案的相關錯誤信息。 如果在虛擬機(VM)產品(如ESX)中遇到此問題,請參閱虛擬機(ESX)中的問題。
在某些情況下,在系統恢復聯機后,可能會在短時間內正常發生這種情況。 但是,某些硬件故障或其他錯誤情況可能會導致服務器默默承擔240的較高優先級,以表示它仍然存在問題,并且不應成為主設備。 這可以通過GUI或通過shell或系統診斷>命令來進行檢查。
在GUI中,此狀態顯示在系統狀態> CARP的錯誤消息中。
在shell或系統診斷>命令中,運行以下命令檢查降級:
#sysctl net.inet.carp.demotion
net.inet.carp.demotion: 240
如果該值大于0,則該節點已降級。
在這種情況下,隔離防火墻,檢查網絡連接,并執行進一步的硬件測試。
如果降級值為0,并且主節點仍然將自己降級為BACKUP或不斷變化,請檢查網絡以確保沒有第2層環路。 如果防火墻從交換機接收到自己的心跳,它也可以觸發對BACKUP狀態的更改。
在虛擬機內部使用HA時,尤其是VMware ESX,需要一些特殊的配置:
在vSwitch上啟用混雜模式。
啟用“MAC地址更改”。
啟用“偽傳輸”。
如果正在使用虛擬分布式交換機,則可以為啟用混雜模式的防火墻接口創建端口組,并為其他主機設置單獨的非混雜端口組。論壇上有用戶使用這種方式來平衡讓CARP功能和保護客戶端端口的要求。
如果在4.0或4.1中使用VDS(虛擬分布式交換機)并將其從4.0升級到4.1或5.0,則VDS將無法正確傳遞CARP流量。 如果在4.1或5.0上創建了新的VDS,它可以正常工作,但升級后的VDS則不會。
可以在VDS上禁用混雜模式,然后重新啟用它可以解決該問題。
如果在VDS上啟用端口鏡像,則會打破混雜模式。 要修復它,請禁用然后重新啟用混雜模式。
如果物理HA集群使用ESX主機(lagg組或類似設備)上的多個端口連接到交換機,并且目標VM只能訪問某些設備/ IP,則端口組設置可能需要調整 ESX將基于IP設置組的負載平衡設置為基于散列,而不是始發接口。
設置不正確的副作用包括:
流量僅在其NIC上以混雜模式到達目標VM。
當主防火墻的“真實”IP地址可以到達時,無法從目標VM到達CARP VIP。
到目標VM的端口轉發或其他入站連接從一些IP地址工作,而不是其他IP地址。
CARP中的自我降級依賴于交換機端口鏈路的丟失。 因此,如果主防火墻實例和輔助防火墻實例位于不同的ESX單元上,并且主設備丟失了交換機端口鏈接并且不會將其公開給虛擬機,CARP將在其所有VIP上保留MASTER,并且次要設備也會相信它應該是MASTER。 解決這個問題的方法之一是在ESX中編寫一個事件,如果物理端口丟失鏈接,該事件將取消VM上的交換機端口。 在ESX中也可能有其他方法。
使用e1000網卡(em(4)),ed(4)網卡或CARP VIP不會離開init狀態。
在VM的相關接口上設置“混雜模式:允許CARP在任何接口類型(橋接,主機,內部)上運行,
如果節點單元插入單獨的交換機,請確保交換機正確中繼并傳遞廣播/多播通信。
一些交換機具有廣播/多播過濾,限制或“風暴控制”功能,可以打破CARP。
某些交換機已損壞固件,導致IGMP Snooping等功能干擾CARP。
如果使用調制解調器/ CPE背面的開關,請嘗試使用真正的開關。 這些內置交換機通常無法正確處理CARP流量。 通常將防火墻插入合適的交換機,然后上行到CPE將消除問題。
在遇到配置同步問題時,請仔細檢查以下項目:
所有節點上的用戶名必須為admin。
主服務器上的配置同步設置中的密碼必須與備份中的密碼相匹配。
WebGUI必須位于所有節點上的相同端口上。
WebGUI必須在所有節點上使用相同的協議(HTTP或HTTPS)。
必須允許流量通過同步流量接口上的WebGUI端口。
必須在所有節點上啟用和配置pfsync接口。
確認只有主同步節點啟用了配置同步選項。
確保在輔助節點上的同步配置到IP中沒有指定IP地址。
確保兩個節點上的時間都是最新的,并且相當準確。
如果在處理多WAN時遇到CARP VIP麻煩,請仔細檢查是否存在與防火墻配置中提到的規則相同的規則。
翻譯自pfsense book
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。