防火牆是避免網路資訊基礎設施免受複雜網路環境中安全攻擊的必要設施。高效的防火牆則更需要實時跟蹤來往於不同網路裝置間的各類網路連線，即「有狀態防火牆」。對於實際的硬體物理網路基礎設施需要防火牆，對於虛擬網路裝置，openstack在這樣的雲平台亦需要同樣的防火牆進行網路保護。
在openstack中，防火牆由「security group」和「fwaas」兩大服務組成。其中security group在port級別提供對vm網路通訊的訪問控制。而fwaas則執行在vrouter上在subnet的邊界控制子網間的l3和l4流量。簡而言之，「security group」保護port，「fwaas」保護subnet。
openstack下的「security group」不僅保護租戶vm，使其避免受到無價值資料流的影響，同時還限制租戶vm，避免其主動發起arp spoofing，dhcp spoofing等不安全網路行為。實際定位到底層，「security group」可以通過iptables和ovs 流表兩種方式實現。本文將重點講述基於ovs 流表實現的安全組（security group）。
無狀態的防火牆只能通過靜態的網路元組來過濾，阻攔，放行資料報文。這裡的靜態網路元組包括ip位址，埠，網路協議。無狀態防火牆並不關心當前網路連線處於何種狀態。相較於無狀態防火牆，有狀態防火牆增加了對當前網路連線狀態的識別，同步使用靜態的網路元祖對資料報文進行過濾，阻攔，放行。增加的識別標誌在一定程度上消耗系統資源，但更加嚴格的規則卻更能保障網路更加安全。
網路連線狀態的識別通常是由ct模組（connection tracker）實現的。在linux核心中，ct是由conntrack實現。從ovs 2.5起，開始支援conntrack，並在openflow中體現相關ct狀態的識別與處理。openstack則從m版開始，使用ovs的新特性，來實現「有狀態防火牆」中的「security group」功能。
從ovs提供的ct功能簡圖2來看，相對於原有流表處理，無非增加了提交連線資料報進入ct模組，標記連線狀態，用於後續流表查詢連線狀態，匹配資料報文進行指定處理的過程。
圖3列舉了ovs實現的openflow 中新增的ct相關字段。（有刪減，僅列舉了後續流表分析時用到的字段）
這裡需要重點解釋下rel，inv，zone=value（ct_zone）這三條專案。
rel，即related。這裡舉個典型的例子描述下related資料報。當vm a ping 某外網ip位址b，發出乙個icmp echo request報文，當該request報文到達路由器時，路由器判定外網ip位址不可達，回送乙個icmp network unreachable報文。那麼這個icmp network unreachable報文與先前發出的icmp echo request報文就是存在related關係。因為對於icmp echo request報文而言，只有icmp echo reply報文是與它存在reply（rpl）關係的。
inv，即invalid。如果存在下述幾種情況：linux核心中l3/l4協議處理程式不可用或者未載入；nf_conntrack_ipv4或nf_conntrack_ipv6模組沒有載入；l3/l4協議判定資料報非法；資料報本身報文長度與協議本身不匹配，那麼該資料報將被置位inv。例：udp奇數位元組報文，被某型網絡卡驅動末位padding 0，但未增加ip頭部內長度資訊，也未增加udp頭部內長度資訊，導致該報文在ovs ct中判定inv，最終drop導致通訊與預期不符。
通過查詢系統連線跟蹤條目，如圖4所示，可知協議型別，源ip，目的ip，源埠，目的埠這5項元組共同構成了識別一條連線跟蹤的索引。在openstack環境中，會有一定概率存在不同專案下的vm，使用相同網段的子網ip，且恰好被排程到同一臺宿主機。在極其偶然的情況下這兩台vm恰好使用同樣的協議，同樣的源埠去訪問同乙個目的ip的同乙個目的埠。如果不加任何隔離處理必將導致連線跟蹤條目的重疊衝突。
zone=value(ct_zone)，很好的處理了這種衝突。zone可以稱之為隔離連線跟蹤條目的namespace。不同zone中的連線跟蹤條目即使協議型別，源ip，目的ip，源埠，目的埠完全一致，也不會存在衝突。在security group的ovs驅動中，每條連線在提交至ct模組時，zone均被指定為該網路連線所處network在本節點上local vlan tag。（此處network為neutron下的network模型）
當乙個port不新增任何安全組資訊時，只有匹配該port的arp報文，dhcp報文，和已建立的連線才會被初始化時下發的流表規則放行。當然，關閉port的port_security_enabled屬性可以遮蔽anti arp spoofing和anti dhcp spoofing流表規則的下發。neutron中的一些特殊型別port，例如dhcp port，gateway port等被認為是security port，自然也是關閉port_security_enabled屬性。如果需要在port上允許其他自定義的ip,mac網路包的流通，也可以通過port的allowed_address_pairs新增相應資訊。被新增的ip,mac會在下發安全組規則時作為可信任的位址資訊被填入流表。
當安全組a的一條ingress規則通過remote group id指向了安全組b，那麼代表著所有通過安全組b的流量才能匹配這條ingress規則。也即意味著只有繫結了繫結了安全組b的port發出的流量才能匹配這條ingress規則。
以「目的ip192.168.0.0/24目標埠22協議tcp出向放行」，「任意ip目標埠80協議tcp入向放行」兩條安全組規則為例，分析流量具體經過的流表，如下圖5所示。
不使用ovs情況下，linux核心的連線跟蹤模組僅限於ip協議層（l3）的linux核心防火牆（iptables）使用。而實際vm流量從tap口流出時已經是l2層報文。因此額外新增了一層linux bridge，配合ebtables，處理原有l2層報文後上送至iptables，從而在iptables中執行連線跟蹤，所有security group規則也被轉換成具體的iptables規則，配合連線狀態，實現狀態防火牆的功能。經過篩選處理後的報文再通過veth從linux bridge流向br-int，執行外部交換與路由。
對比ovs與iptables實現的狀態防火牆，多一層虛擬網路裝置就多一次處理，這裡必然導致多一重效能損耗。如圖7所示，在security group 規則數量龐大的情況下，效能消耗則更加明顯。
實現日 周 月排行統計
在如今很多系統中，都需要進行日 周 月排行統計，但是在網上尋找了一番，發現很多都是相對的周 月排行，即週排行則用當前時間減去 7天。這樣我個人認為並不恰當。如月排行中，假設今天是4月 22日,則從 3月22日至4月 22日之間都可以算成月排行內，這樣的話與我們的月排行不盡相同，我認為月排行應該指當月...
周總結（2023年2月19 25）
這是這春節之後的第一周，每一天都過的非常充實而有意義，因為自己正在不斷的朝著自己的目標努力著。而且我堅信10個月之後的2019年1月份我一定能夠達到我的目標。不管是我的專業技能還是軟技能上都將擁有質的飛躍。本週實行了一下幾個方面的內容 計算機方面 英語能力 看身邊巨人的成長歷程 軟技能方面 健身 一...
c實現 2月29日
時間限制 2000ms 單點時限 1000ms 記憶體限制 256mb 給定兩個日期，計算這兩個日期之間有多少個2月29日 包括起始日期 只有閏年有2月29日，滿足以下乙個條件的年份為閏年 1.年份能被4整除但不能被100整除 2.年份能被400整除 第一行為乙個整數t，表示資料組數。之後每組資料報...