1. 項目概述從一次“詭異”的訪問拒絕說起那天下午我正在排查一個網(wǎng)絡(luò)故障。用戶反饋說服務(wù)器AIP192.168.10.100無法訪問服務(wù)器BIP192.168.20.200上的某個服務(wù)。我第一反應(yīng)是路由問題但ping和traceroute都顯示路徑是通的。接著檢查防火墻規(guī)則看起來也沒問題允許了192.168.10.0/24到192.168.20.0/24的流量。問題出在哪兒我?guī)缀跻獞岩墒菓?yīng)用層的問題了直到我鬼使神差地看了一眼那臺核心交換機上的ACL訪問控制列表配置。一條看似簡單的規(guī)則映入眼簾permit ip 192.168.10.0 0.0.0.255 any。等等源地址是192.168.10.0通配符掩碼是0.0.0.255這匹配的不就是192.168.10.0/24這個網(wǎng)段嗎邏輯上完全正確啊。但為什么192.168.10.100的流量還是被拒絕了這個看似簡單的問題恰恰是無數(shù)網(wǎng)絡(luò)工程師、運維人員在初次接觸ACL尤其是涉及網(wǎng)段匹配時最容易踩進去的“坑”。我們常常把“通配符掩碼”和“子網(wǎng)掩碼”混為一談或者想當然地認為它們的工作原理一樣。實際上ACL匹配網(wǎng)段的規(guī)則其底層邏輯與我們熟悉的子網(wǎng)劃分有微妙的、卻是決定性的差異。不理解這個差異配置的ACL就可能產(chǎn)生與你預期完全相反的效果導致一些“靈異”的網(wǎng)絡(luò)連通性問題。今天我就結(jié)合那次排查經(jīng)歷和多年的實操把ACL里匹配網(wǎng)段的規(guī)則掰開了、揉碎了講清楚讓你不僅“知道”更能“理解”和“用對”。2. ACL與通配符掩碼顛覆你對“掩碼”的認知要理解網(wǎng)段匹配必須先過通配符掩碼這一關(guān)。很多人包括當年的我都曾在這里栽過跟頭。2.1 通配符掩碼 vs. 子網(wǎng)掩碼本質(zhì)的差異我們先回顧一下子網(wǎng)掩碼。子網(wǎng)掩碼比如255.255.255.0它的核心作用是定義網(wǎng)絡(luò)邊界。在二進制的世界里255即11111111表示“網(wǎng)絡(luò)位”0表示“主機位”。它和IP地址做“邏輯與”運算得到的就是網(wǎng)絡(luò)地址。它的思維是“哪些位是固定的網(wǎng)絡(luò)哪些位是可變的主機”。而通配符掩碼雖然也由0和1組成但它的邏輯完全相反。在通配符掩碼中0表示“必須精確匹配”。對應(yīng)位上的IP地址比特必須和ACL規(guī)則中定義的地址比特完全一致。1表示“忽略不關(guān)心”。對應(yīng)位上的IP地址比特可以是0也可以是1ACL不做檢查。所以通配符掩碼定義的是在匹配時IP地址的哪些位需要被檢查哪些位可以被忽略。它是一種“匹配模板”而不是“網(wǎng)絡(luò)定義符”。2.2 一個經(jīng)典的“坑”匹配整個網(wǎng)段回到開頭的例子。我們想匹配192.168.10.0/24這個網(wǎng)段。這個網(wǎng)段包含從192.168.10.0到192.168.10.255的所有IP地址。網(wǎng)絡(luò)地址192.168.10.0子網(wǎng)掩碼255.255.255.0(二進制11111111.11111111.11111111.00000000)如果我們錯誤地使用子網(wǎng)掩碼的思維可能會寫出這樣的ACL規(guī)則permit ip 192.168.10.0 255.255.255.0 any。這在某些設(shè)備上甚至是無法通過的語法檢查因為ACL規(guī)則里寫的就是“通配符掩碼”字段。正確的做法是使用通配符掩碼。我們需要分析要匹配192.168.10.0/24意味著IP地址的前24位即192.168.10必須固定最后8位可以任意變化。需要固定的位前24位對應(yīng)通配符掩碼的比特應(yīng)為0?？梢院雎缘奈缓?位對應(yīng)通配符掩碼的比特應(yīng)為1。因此通配符掩碼應(yīng)該是00000000.00000000.00000000.11111111轉(zhuǎn)換為十進制就是0.0.0.255。所以正確的ACL規(guī)則是permit ip 192.168.10.0 0.0.0.255 any。這表示源IP地址的前24位必須嚴格等于192.168.10最后8位是什么都行。這樣就精準匹配了整個192.168.10.0/24網(wǎng)段。注意這里規(guī)則中寫的地址是192.168.10.0但請注意這個0在通配符掩碼為0.0.0.255的語境下并不是特指主機位為0的地址而是“前24位匹配192.168.10”這個模式的一部分。實際上192.168.10.0網(wǎng)絡(luò)地址和192.168.10.255廣播地址也都會被這條規(guī)則匹配到這在某些場景下可能需要額外注意。2.3 更復雜的匹配非連續(xù)的通配符掩碼通配符掩碼的強大之處在于它的“0”和“1”可以不連續(xù)這允許我們實現(xiàn)非常靈活的匹配。而子網(wǎng)掩碼的“1”必須是連續(xù)的。例如假設(shè)一個奇葩的需求我們需要匹配IP地址第三段為偶數(shù)第四段為奇數(shù)的所有10.1.x.x的地址。用子網(wǎng)掩碼幾乎無法簡潔定義。但用通配符掩碼可以嘗試。我們想匹配的IP模式是10.1.偶數(shù).奇數(shù)。第一段10二進制00001010必須精確匹配 通配符掩碼第一位為00000000(0)第二段1二進制00000001必須精確匹配 通配符掩碼第二位為00000000(0)第三段為偶數(shù)即二進制最后一位為0。我們關(guān)心這個位是否為0其他位不關(guān)心。這需要一點技巧。偶數(shù)可以表示為2n其二進制最后一位是0。我們可以寫一條規(guī)則匹配最后一位為0但前7位任意的模式。這對應(yīng)的通配符掩碼第三段為11111110254因為只有最后一位最低位要求為0掩碼為0前7位不關(guān)心掩碼為1。規(guī)則中的地址第三段可以寫0因為0是偶數(shù)且最后一位為0符合要求即10.1.0.奇數(shù)但掩碼的254會忽略前7位只檢查最后一位是否為0。第四段為奇數(shù)即二進制最后一位為1。類似地通配符掩碼第四段為11111110254規(guī)則中地址第四段寫1奇數(shù)最后一位為1。那么規(guī)則可以寫成permit ip 10.1.0.1 0.0.254.254。我們來驗證一下10.1.2.3: 第三段200000010最后一位0第四段300000011最后一位1 匹配。10.1.4.5: 匹配。10.1.1.2: 第三段100000001最后一位1 不匹配。10.1.2.4: 第四段400000100最后一位0 不匹配。雖然這個例子有些極端但它充分展示了通配符掩碼在匹配非標準、非連續(xù)地址組時的靈活性。這在一些特殊的策略路由、流量標記或安全策略中可能會用到。3. 實操如何正確計算和編寫匹配網(wǎng)段的ACL規(guī)則理解了原理我們來看看如何一步步正確配置一條匹配網(wǎng)段的ACL規(guī)則。我將以華為/H3CVRP系統(tǒng)和思科IOS/IOS-XE系統(tǒng)這兩種最常見的平臺為例雖然命令行稍有不同但核心邏輯完全一致。3.1 標準五步法從需求到配置無論平臺如何配置一條精確的ACL規(guī)則都可以遵循以下五個步驟第一步明確匹配需求用自然語言清晰地描述你要匹配的IP地址范圍。例如“允許研發(fā)部VLAN網(wǎng)段10.10.10.0/24訪問文件服務(wù)器172.16.1.100。”第二步提取關(guān)鍵地址和子網(wǎng)掩碼從需求中提取出網(wǎng)絡(luò)地址和子網(wǎng)掩碼。源網(wǎng)絡(luò)10.10.10.0/24- 地址10.10.10.0 子網(wǎng)掩碼255.255.255.0目的地址172.16.1.100- 這是一個單點IP可視為子網(wǎng)掩碼255.255.255.255(即/32)第三步將子網(wǎng)掩碼轉(zhuǎn)換為通配符掩碼這是最關(guān)鍵的一步。記住公式通配符掩碼 255.255.255.255 - 子網(wǎng)掩碼。對于源255.255.255.0通配符掩碼 255.255.255.255 - 255.255.255.0 0.0.0.255對于目的255.255.255.255通配符掩碼 255.255.255.255 - 255.255.255.255 0.0.0.0(表示精確匹配每一個比特)第四步選擇ACL類型并創(chuàng)建基本匹配僅源IP使用標準ACL思科1-991300-1999華為/華三basic ACL 2000-2999。高級匹配源IP、目的IP、協(xié)議端口使用擴展ACL思科100-1992000-2699華為/華三advanced ACL 3000-3999。我們的需求涉及源IP、目的IP和協(xié)議假設(shè)是TCP的445端口SMB服務(wù)因此使用擴展ACL。第五步編寫并應(yīng)用規(guī)則將前面步驟得到的信息組合成ACL規(guī)則語句并將其應(yīng)用到接口的入方向或出方向。3.2 華為/華三VRP配置示例假設(shè)我們要在連接研發(fā)部VLAN的接口GigabitEthernet 0/0/1的入方向應(yīng)用策略。# 進入系統(tǒng)視圖 system-view # 創(chuàng)建一個編號為3001的高級ACL acl number 3001 # 配置規(guī)則允許源IP為10.10.10.0/24目的IP為172.16.1.100目的端口為445的TCP流量 # 規(guī)則ID 5動作permit協(xié)議tcp源地址 10.10.10.0 通配符 0.0.0.255目的地址 172.16.1.100 通配符 0.0.0.0目的端口 eq 445 rule 5 permit tcp source 10.10.10.0 0.0.0.255 destination 172.16.1.100 0 destination-port eq 445 # 可選在末尾添加一條拒絕所有的規(guī)則隱含拒絕存在但顯式寫出便于閱讀和管理 rule 10 deny ip # 退出ACL視圖 quit # 進入接口視圖 interface GigabitEthernet 0/0/1 # 將ACL 3001應(yīng)用到該接口的入方向流量進行過濾 traffic-filter inbound acl 3001 # 提交并退出 commit quit關(guān)鍵點解析source 10.10.10.0 0.0.0.255這就是匹配整個10.10.10.0/24網(wǎng)段的寫法。destination 172.16.1.100 00是0.0.0.0的簡寫表示精確匹配主機172.16.1.100。destination-port eq 445指定目的端口使策略更精確。traffic-filter inbound acl 3001將ACL作為流量過濾器應(yīng)用在接口入方向。這意味著從該接口進入設(shè)備的數(shù)據(jù)包會受到ACL 3001的檢查。3.3 思科IOS/IOS-XE配置示例實現(xiàn)同樣的功能在思科設(shè)備上的配置。# 進入全局配置模式 configure terminal # 創(chuàng)建一個編號為101的擴展IP訪問列表思科擴展ACL常用100-199 ip access-list extended ALLOW_RD_TO_FILESVR # 配置規(guī)則允許TCP流量從10.10.10.0/24到172.16.1.100目的端口445 # 思科語法permit/deny 協(xié)議 源地址 通配符 目的地址 通配符 [操作符 端口] permit tcp 10.10.10.0 0.0.0.255 host 172.16.1.100 eq 445 # 思科擴展ACL末尾默認有一條隱式的deny ip any any無需顯式寫出但為清晰也可添加 deny ip any any # 退出ACL配置模式 exit # 進入接口配置模式 interface GigabitEthernet0/1 # 將訪問列表101應(yīng)用到接口的出方向注意方向這是思科常見做法與華為入方向效果可能等價取決于流量視角 ip access-group ALLOW_RD_TO_FILESVR out # 退出并保存配置 end write memory關(guān)鍵點解析與對比10.10.10.0 0.0.0.255網(wǎng)段匹配寫法與華為一致。host 172.16.1.100這是思科的便捷寫法等價于172.16.1.100 0.0.0.0。同樣any等價于0.0.0.0 255.255.255.255。ip access-group ... out應(yīng)用在接口出方向。這里有一個非常重要的實操心得ACL應(yīng)用的方向inbound/outbound是以設(shè)備本身為參照的。入方向in過濾從該接口進入設(shè)備的流量。常用于保護設(shè)備自身或過濾進入本地網(wǎng)絡(luò)的流量。出方向out過濾從設(shè)備通過該接口發(fā)出的流量。常用于控制從本地網(wǎng)絡(luò)出去的流量。 在上面的思科例子中如果GigabitEthernet0/1連接的是研發(fā)部網(wǎng)絡(luò)那么從研發(fā)部網(wǎng)絡(luò)發(fā)往文件服務(wù)器的流量對于該接口而言是出方向流量從設(shè)備發(fā)出到服務(wù)器網(wǎng)絡(luò)。所以應(yīng)用out是合理的。如果應(yīng)用在華為設(shè)備的入方向效果是等價的都是對從研發(fā)部來的流量進行過濾。理解流量方向是正確應(yīng)用ACL的關(guān)鍵否則規(guī)則可能完全不起作用。3.4 驗證與調(diào)試確保規(guī)則生效配置完成后絕不能一配了之必須驗證。在華為/華三設(shè)備上# 查看ACL 3001的配置和匹配統(tǒng)計 display acl 3001 # 查看接口上的ACL應(yīng)用情況和統(tǒng)計信息 display traffic-filter applied-record # 或者查看指定接口的ACL統(tǒng)計需要先在ACL視圖下用statistics enable啟用統(tǒng)計 display acl 3001 statistics interface GigabitEthernet 0/0/1 inbound在思科設(shè)備上# 查看名為ALLOW_RD_TO_FILESVR的ACL配置和匹配次數(shù) show access-lists ALLOW_RD_TO_FILESVR # 查看接口的ACL應(yīng)用情況 show ip interface GigabitEthernet0/1查看時重點關(guān)注rule/packet的匹配計數(shù)。如果規(guī)則配置正確但計數(shù)不增加可能是流量方向錯誤、路由問題或者有更高優(yōu)先級的策略如其他ACL、防火墻策略攔截了。4. 高級技巧與常見“坑點”實錄掌握了基礎(chǔ)配置我們來看看那些容易讓人翻車的高級場景和排查技巧。4.1 匹配特定主機或多個不連續(xù)主機場景需要允許或禁止幾個特定的、不在同一網(wǎng)段的IP地址。錯誤做法為每個IP寫一條單獨的規(guī)則。雖然可行但規(guī)則條數(shù)多管理繁瑣。高效做法利用通配符掩碼的靈活性。例如要匹配192.168.1.10和192.168.1.20這兩個主機。寫出它們的二進制192.168.1.1011000000.10101000.00000001.00001010192.168.1.2011000000.10101000.00000001.00010100對比發(fā)現(xiàn)只有第四字節(jié)的比特位不同。我們需要找到一個通配符掩碼使得在它為0的位上兩個IP的比特相同在為1的位上允許不同。找出相同的位前三個字節(jié)完全相同第四字節(jié)的二進制00001010(10) 和00010100(20)。逐位對比位8(128): 0 vs 0 - 相同位7(64): 0 vs 0 - 相同位6(32): 0 vs 0 - 相同位5(16): 0 vs 1 -不同位4(8): 1 vs 0 -不同位3(4): 0 vs 1 -不同位2(2): 1 vs 0 -不同位1(1): 0 vs 0 - 相同所以第5、4、3、2位不同。在通配符掩碼中這些位應(yīng)設(shè)為1忽略相同的位8,7,6,1設(shè)為0匹配。因此第四字節(jié)的通配符掩碼為00111100二進制即60十進制。規(guī)則中使用的地址需要在所有掩碼為0的位上與兩個IP都一致。我們?nèi)∑渲幸粋€IP比如192.168.1.10但需要確保在掩碼為0的位上192.168.1.20也一致。檢查一下對于位8,7,6,1兩個IP都是0所以取192.168.1.10的第四字節(jié)1000001010是可行的。最終規(guī)則為permit ip 192.168.1.10 0.0.0.60 any。這條規(guī)則會匹配192.168.1.10和192.168.1.20以及第四字節(jié)二進制模式為0000x1x0的所有地址x表示0或1即10(00001010),14(00001110),20(00010100),24(00011000),26(00011010),30(00011110)等。這比預想的范圍大。這說明用一條規(guī)則精確匹配多個不連續(xù)主機非常困難且容易引入額外匹配。對于精確控制更推薦使用前綴列表ip prefix-list或單獨的ACL規(guī)則。實操心得對于少量、離散的IP地址不要強行用一條復雜的通配符掩碼規(guī)則去匹配。這樣可讀性差容易出錯且可能產(chǎn)生副作用。直接寫多條host規(guī)則思科或0通配符規(guī)則華為雖然條目多但意圖清晰便于后續(xù)維護和排錯。ACL的性能通常足夠處理幾十上百條規(guī)則清晰性比那一點點性能優(yōu)化更重要。4.2 ACL規(guī)則的匹配順序與優(yōu)先級這是另一個大坑。ACL規(guī)則是從上到下逐條匹配的一旦匹配成功就執(zhí)行對應(yīng)動作permit/deny并停止繼續(xù)匹配。場景你想禁止192.168.1.100上網(wǎng)但允許192.168.1.0/24其他所有主機上網(wǎng)。錯誤配置順序rule 5 permit ip source 192.168.1.0 0.0.0.255 any rule 10 deny ip source 192.168.1.100 0 any當192.168.1.100的流量進來時首先匹配rule 5源IP192.168.1.100在192.168.1.0/24網(wǎng)段內(nèi)匹配成功執(zhí)行permit然后ACL處理結(jié)束。rule 10根本不會被評估到。結(jié)果是192.168.1.100依然被允許。正確配置順序rule 5 deny ip source 192.168.1.100 0 any # 先拒絕特定主機 rule 10 permit ip source 192.168.1.0 0.0.0.255 any # 再允許整個網(wǎng)段這樣192.168.1.100的流量先匹配rule 5被拒絕。其他192.168.1.0/24的主機匹配rule 5失敗繼續(xù)匹配rule 10成功被允許。通用原則“先精確后寬泛”。將匹配范圍最小、最具體的規(guī)則如針對單個主機、特定端口的規(guī)則放在前面將匹配范圍寬泛的規(guī)則如允許整個網(wǎng)段、所有流量放在后面。思科的命名擴展ACL可以插入規(guī)則但編號ACL修改順序較麻煩初期規(guī)劃好順序非常重要。4.3 “隱形”的規(guī)則隱含拒絕幾乎所有ACL的末尾都有一條看不見的規(guī)則deny ip any any拒絕所有IP流量。這意味著如果數(shù)據(jù)包沒有匹配到任何一條顯式的permit規(guī)則它最終會被這條隱含規(guī)則拒絕。踩坑實錄有一次我配置了一條ACL只允許10.1.1.0/24訪問服務(wù)器然后應(yīng)用在服務(wù)器接口的入方向。測試時10.1.1.100可以訪問但服務(wù)器自己發(fā)起的回包比如響應(yīng)請求卻失敗了。為什么因為服務(wù)器的回包源IP是服務(wù)器目的IP是10.1.1.100從接口出去時如果ACL應(yīng)用在出方向或者有其他的過濾策略這個回包并沒有匹配到我寫的permit規(guī)則我的規(guī)則是匹配源10.1.1.0/24到目的服務(wù)器因此被隱含拒絕規(guī)則丟棄了。解決方法雙向考慮在配置ACL時一定要考慮流量的雙向性。通常需要在通信兩端都配置適當?shù)脑试S規(guī)則或者使用基于狀態(tài)的防火墻如zone-policy它能自動放行已建立連接的回包。謹慎使用any在測試階段可以在ACL末尾顯式添加一條permit ip any any然后觀察哪些流量被匹配幫助理解流量模式。但在生產(chǎn)環(huán)境最終配置前一定要刪除或替換這條過于寬松的規(guī)則遵循最小權(quán)限原則。利用established參數(shù)思科對于TCP流量思科ACL支持established關(guān)鍵字它可以自動允許那些屬于已建立TCP會話的報文即ACK或RST標志位為1的包。這在只希望內(nèi)網(wǎng)主動發(fā)起訪問并自動允許回包的場景下非常有用。例如permit tcp any any established。4.4 通配符掩碼0.0.0.0與host關(guān)鍵字匹配單個主機時有兩種寫法192.168.1.1 0.0.0.0host 192.168.1.1(思科語法華為部分版本也支持類似或需用0簡寫)兩者完全等價。0.0.0.0表示所有32位都必須精確匹配。在配置時使用host關(guān)鍵字可讀性更好。在華為設(shè)備上目的地址為單個主機時可以用0代替0.0.0.0。4.5 匹配“所有”通配符掩碼255.255.255.255與0.0.0.0相反255.255.255.255表示所有位都不檢查即匹配任何地址。它通常寫作關(guān)鍵字any。permit ip any any等價于permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.2555. 問題排查當ACL不按預期工作時即使你認為自己完全理解了規(guī)則實際網(wǎng)絡(luò)中ACL不生效的情況也比比皆是。下面是一個系統(tǒng)化的排查流程。5.1 排查流程圖與步驟當遇到網(wǎng)絡(luò)訪問被ACL意外阻斷或放行時可以按以下步驟排查確認現(xiàn)象具體是哪兩個IP之間的什么協(xié)議ICMP ping? TCP 80端口不通是單向不通還是雙向都不通定位ACL在流量路徑上的所有設(shè)備交換機、路由器、防火墻上檢查可能應(yīng)用的ACL。使用display acl all華為或show access-lists思科查看所有ACL配置和匹配計數(shù)。驗證規(guī)則邏輯通配符掩碼計算是否正確這是最常見的問題。反復用“需要匹配的地址”和“通配符掩碼”進行二進制驗證。規(guī)則順序是否正確檢查是否有更精確的規(guī)則先被匹配。動作是permit還是deny別笑忙中出錯寫反的情況時有發(fā)生。檢查應(yīng)用位置與方向ACL應(yīng)用在哪個接口確認流量是否確實經(jīng)過了該接口。應(yīng)用方向in/out是否正確這是第二大常見問題。站在設(shè)備的角度畫一下流量路徑圖判斷對于該接口目標流量是進入in還是離開out設(shè)備。是否有多個ACL或策略一個接口的同一個方向只能應(yīng)用一個ACL嗎不一定有些設(shè)備支持策略路由、QoS策略等也會調(diào)用ACL或者有默認的全局策略。檢查所有可能的地方。查看計數(shù)器啟用ACL統(tǒng)計功能如華為的statistics enable重現(xiàn)問題流量查看預期應(yīng)該匹配的規(guī)則計數(shù)器是否增加。如果不增加說明流量根本沒走到這條規(guī)則可能是方向錯誤或被前面的規(guī)則匹配了。模擬測試與簡化在ACL最前面添加一條臨時的、寬松的permit規(guī)則如permit ip source-host 源IP destination-host 目的IP測試連通性。如果通了說明問題出在后續(xù)的規(guī)則上如果還不通可能是ACL應(yīng)用位置或方向錯誤或者根本就不是ACL的問題。暫時將ACL從接口上取消綁定undo traffic-filter inbound或no ip access-group ...測試連通性。如果通了確認是ACL問題如果還不通問題可能在于路由、防火墻或其他安全設(shè)備。5.2 常見問題速查表問題現(xiàn)象可能原因排查命令與解決方法特定主機無法訪問目標1. 該主機IP被某條deny規(guī)則匹配。2. 允許規(guī)則的通配符掩碼計算錯誤未包含該主機。3. 規(guī)則順序有誤寬泛的deny或permit規(guī)則先于精確規(guī)則匹配。1.display acl 編號查看所有規(guī)則匹配計數(shù)看哪條規(guī)則計數(shù)在增。2. 重新計算通配符掩碼用二進制驗證主機IP是否匹配。3. 調(diào)整規(guī)則順序?qū)⑨槍υ撝鳈C的精確規(guī)則上移。整個網(wǎng)段都無法訪問1. 允許該網(wǎng)段的規(guī)則通配符掩碼錯誤如寫成了子網(wǎng)掩碼。2. ACL應(yīng)用在了錯誤的接口或錯誤的方向。3. ACL末尾的隱含拒絕生效且沒有permit規(guī)則匹配。1.重點檢查規(guī)則是否是網(wǎng)絡(luò)地址 0.0.0.255格式2. 檢查display traffic-filter applied-record或show ip interface。3. 在ACL末尾添加一條permit ip any any臨時測試若恢復則問題在于缺少permit規(guī)則。ACL規(guī)則計數(shù)器不增加1. 流量未經(jīng)過應(yīng)用了ACL的接口。2. ACL應(yīng)用方向錯誤流量是從反方向通過的。3. 流量被設(shè)備其他處理機制如路由失敗、策略路由提前丟棄未送到ACL檢查點。1. 使用traceroute確認流量路徑。2. 交換接口的in/out方向再測試。3. 檢查設(shè)備路由表確認是否有到達目的地的路由。允許了A到B但B到A的回包失敗1. 只配置了單向的permit規(guī)則回包沒有對應(yīng)的permit規(guī)則被隱含拒絕。2. 回包路徑上的其他接口應(yīng)用了限制性ACL。1. 配置雙向permit規(guī)則或使用狀態(tài)化防火墻如安全策略。2. 在B端設(shè)備或路徑中間設(shè)備上檢查是否有出向/入向ACL限制了回包。配置了host關(guān)鍵字但無效1. 思科設(shè)備確認是host 192.168.1.1不是host 192.168.1.1 0.0.0.0。2. 華為設(shè)備目的地址單個主機可用0源地址用0可能語法不對需寫全0.0.0.0或使用其他方式。1. 思科規(guī)則應(yīng)為permit ip host 192.168.1.1 any。2. 華為對于源/目的IP使用192.168.1.1 0來匹配單個主機0是0.0.0.0的簡寫僅在目的地址時常用源地址建議寫全。最穩(wěn)妥是寫全192.168.1.1 0.0.0.0。5.3 工具輔助在線計算器與腳本對于復雜的通配符掩碼計算不要硬扛。可以借助一些工具網(wǎng)絡(luò)計算器很多在線的子網(wǎng)計算器也支持通配符掩碼計算。輸入網(wǎng)絡(luò)地址和子網(wǎng)掩碼它會給出對應(yīng)的通配符掩碼。自己寫段小程序如果你熟悉Python或其它腳本語言寫一個簡單的函數(shù)來驗證IP是否匹配ACL規(guī)則是非?？斓?。def check_acl_match(ip_str, rule_ip_str, wildcard_str): ip list(map(int, ip_str.split(.))) rule_ip list(map(int, rule_ip_str.split(.))) wildcard list(map(int, wildcard_str.split(.))) for i in range(4): if (ip[i] ~wildcard[i]) ! (rule_ip[i] ~wildcard[i]): return False return True # 示例檢查 192.168.10.100 是否匹配規(guī)則 192.168.10.0 0.0.0.255 print(check_acl_match(192.168.10.100, 192.168.10.0, 0.0.0.255)) # 應(yīng)返回 True print(check_acl_match(192.168.20.100, 192.168.10.0, 0.0.0.255)) # 應(yīng)返回 False這個函數(shù)的核心邏輯是(IP ~Wildcard) (Rule_IP ~Wildcard)。因為Wildcard中為1的位需要忽略在比較時置為0所以先對Wildcard取反~再和IP做按位與保留需要比較的位然后看它們是否相等。回過頭看文章開頭我遇到的那個“詭異”問題。原因正是一條配置在核心交換機上聯(lián)接口入方向的ACL意圖是限制某個網(wǎng)段訪問互聯(lián)網(wǎng)但其通配符掩碼計算有誤錯誤地匹配到了192.168.10.0/24這個網(wǎng)段而服務(wù)器A的地址正在其中。但由于規(guī)則順序和方向應(yīng)用的疊加導致了部分流量被意外攔截。通過使用上述的排查步驟特別是查看ACL計數(shù)和重新驗算通配符掩碼最終定位并修正了那條錯誤的規(guī)則。ACL是網(wǎng)絡(luò)控制的基石而通配符掩碼是它的靈魂。死記硬背“通配符掩碼是反子網(wǎng)掩碼”或許能應(yīng)付一時但只有真正理解其“0位精確匹配1位忽略”的比特位操作本質(zhì)才能在各種復雜場景下靈活、準確地運用它讓ACL真正成為你手中精準的網(wǎng)絡(luò)策略手術(shù)刀而不是一個時不時制造“靈異事件”的黑盒子。下次再配ACL時不妨在敲下回車前心里默默用二進制過一遍這份嚴謹會讓你避開很多深夜的故障排查電話。