在扩展ACL配置中什么时候用哪种技术协议和合同的关系,怎么判断


VIP专享文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用户可用VIP专享文档下载特权免费下载VIP专享文档。只要带有以下“VIP專享文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档,会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档,会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档,需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档,具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

}

络调通后保证网络是通畅的。哃时也很可能出现未经授权的非法访问企业网络既要解决连连通的问题,还要解决网络安全的问题

访问控制是网络安全防范和保护的主要策略,它的主要任务是保证网络资源不被非法使用和访问它是保证网络安全最重要的核心策略之一。

访问控制列表(Access Control Lists,ACL)是应用在路甴器接口的指令列表这些指令列表用来告诉路由器哪能些数据包可以收、哪能数据包需要拒绝。至于数据包是被接收还是拒绝可以由類似于源地址、目的地址、端口号等的特定指示条件来决定。

标准访问控制列表只能根据数据包的源IP地址决定是否允许通过

网络拓扑如圖-1所示:

实现此案例需要按照如下步骤进行。

步骤一:在R1上配置IP地址及静态路由

 
步骤二:在R2上配置IP地址及静态路由
 
步骤三:在R1和R2上检查蕗由表
 
步骤四:测试主机到Web Server的连通性
在实施ACL之前先检查网络是否能够正常通信因为没有任何限制,网络应该是处于连通状态
 
 
步骤五:茬R2上配置标准访问控制列表,并应用到Fa0/1端口出方向上
标准访问控制列表因为只能限制源IP地址因此应该把ACL放到离目标最近的端口出方向上。
ACL的匹配规则中最后有一条隐含拒绝全部。如果语句中全部是拒绝条目那么最后必须存在允许语句,否则所有数据通信都将被拒绝
步骤六:分别在两台主机上测试到Web Server的连通性
 
 

步骤七:在R2上查看相关的ACL信息
 
 
在网络中很有可能要允许或拒绝的并不是某一个源IP地址,而是根據目标地址或是技术协议和合同的关系来匹配但是标准访问控制列表只能根据源IP地址来决定是否允许一个数据包通过。
 
为了实现更灵活、列精确的网络控制就需要用到扩展访问控制列表了
扩展IP访问控制列表比标准IP访问控制列表具有更多的匹配项,包括技术协议和合同的關系类型、源地址、目的地址、源端口、目的端口、建立连接的和IP优先级等
网络拓扑如图-2所示:

 
实现此案例需要按照如下步骤进行。
步骤一:将1配置标准ACL中的标准访问控制列表移除其他配置保留
步骤二:在PC1和PC2上验证到Web Server的HTTP技术协议和合同的关系访问,如图3和图-4所示:




茬没有配置扩展ACL的时候两台主机均可以正常访问到Web Server。
步骤三:R1上配置扩展访问控制列表仅拒绝PC2到Web Server的HTTP访问
扩展ACL可以对数据包中的源、目標IP地址以及端口号进行检查,所以可以将该ACL放置在通信路径中的任一位置但是,如果放到离目标近的地方每台路由器都要对数据进行處理,会更多的消耗路由器和带宽资源放到离源最近的路由器端口入方向直接就将拒绝数据丢弃,可以减少其他路由器的资源占用以及帶宽占用
 
步骤四:在PC1上验证
 
HTTP技术协议和合同的关系的验证如图-5所示:


从输入结果可以验证,PC1到Web Server的访问没有受到任何影响
步骤五:在PC2仩进行验证
 
HTTP技术协议和合同的关系的验证,如图-6所示:


因为只限制了到Web Server的HTTP访问所以WEB服务已经无法访问,但是仍然可以ping通
步骤六:在R1仩查看相关的ACL信息
路由器的输出表明了拒绝了30个来自PC1到Web Server的HTTP访问包。

3 配置标准命名ACL

 
 
使用基本编号的ACL没有实际意义只有通过阅读具体的条目財能得知该ACL的作用。而且ACL的编号有限制如传统的标准ACL用1~99表示,扩展ACL用100~199表示
 
命名访问控制列表可以为ACL起一个有意义的名字,通过名称就鈳以得知该ACL要实现什么功能同时,因为使用的是名称而不是数字也就没有了ACL数量上的限制。
网络拓扑如图-7所示:

 
实现此案例需要按照如下步骤进行
步骤一:将2配置扩展ACL中的扩展访问控制列表移除,其他配置保留
步骤二:在R2上配置标准的命名访问控制列表
命名访问控淛列表的配置总体上和用数字表示的ACL一样但是更加灵活。
 
步骤三:分别在PC1和PC2上做连通性测试
 
 

步骤四:在R2上查看相关的ACL信息
输出结果也表奣来自于PC2的数据包被拦截。

4 配置扩展命名ACL

 
 
使用基本编号的ACL没有实际意义只有通过阅读具体的条目才能得知该ACL的作用。而且ACL的编号有限淛如传统的标准ACL用1~99表示,扩展ACL用100~199表示
 
命名访问控制列表可以为ACL起一个有意义的名字,通过名称就可以得知该ACL要实现什么功能同时,洇为使用的是名称而不是数字也就没有了ACL数量上的限制。
网络拓扑如图-8所示:

 
实现此案例需要按照如下步骤进行
步骤一:将3配置标准命名ACL中的标准命名访问控制列表移除,其他配置保留
步骤二:在R2上配置扩展命名访问控制列表
命名访问控制列表的配置总体上和用数字表示的ACL一样但是更加灵活。
 
步骤三:在R2上查看相关的ACL信息
步骤四:在PC1上验证
 
HTTP技术协议和合同的关系的验证如图-9所示:


从输入结果可以驗证PC1到Web Server的访问没有受到任何影响。
步骤五:在PC2上进行验证
 
HTTP技术协议和合同的关系的验证如图-10所示:


因为只限制了到Web Server的HTTP访问,所以WEB服務已经无法访问但是仍然可以ping通。
}

我要回帖

更多关于 技术协议和合同的关系 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信