一次简单的排错经历
2009-12-24 20:48
489 查看
今天,遇见了这样的一个问题,公司有员工反映:两台机器,A 为服务器,地址为192.168.200.198, B机器为个人用pc,ip地址为192.168.200.35,使用B机器 运行:\\192.168.200.198, 无法打开A机器上的共享文件。
出现了这样的现象,这种现象以前也遇见过,于是我从系统入手,查看A机器上的管理员权限和guest的权限,将两个权限全部放开,但是现象依然存在。于是我在B机器上共享了d盘,通过A服务器上来运行\\192.168.200.35,发现可以共享过去。
网络拓扑为:A接华为s3526三层交换机,但是该三层交换机当二层用,B接h3c3100二层交换机,两个交换机均接到了另一个华为的三层交换机上,该三层交换机与上面所提到的交换机 trunk 连接。
开始并没有想到路由协议的问题,一直在两边进行测试,最后发现只能单方向共享文件,A可以访问B,但是B不能访问A,由于和A接的交换机是前人调试的,开始有点大意,认为应该不会在该交换机上作访问控制列表。
在排除了计算机系统的原因后,进入与A连接的交换机发现了一个acl 3000,其中有这个的几个rule ,将nebios的协议deny掉了,并且该acl 3000应用到了与A相连的交换机的trunk口的in方向上。该acl如图所示
发现了这个问题,一切就不难了,进入该trunk 口,讲acl 3000的访问控制列表去掉,重新测试,B机器即可访问A服务器上的共享文件夹。本文出自 “网络之路” 博客,请务必保留此出处http://chenpengpeng.blog.51cto.com/1117737/248679
出现了这样的现象,这种现象以前也遇见过,于是我从系统入手,查看A机器上的管理员权限和guest的权限,将两个权限全部放开,但是现象依然存在。于是我在B机器上共享了d盘,通过A服务器上来运行\\192.168.200.35,发现可以共享过去。
网络拓扑为:A接华为s3526三层交换机,但是该三层交换机当二层用,B接h3c3100二层交换机,两个交换机均接到了另一个华为的三层交换机上,该三层交换机与上面所提到的交换机 trunk 连接。
开始并没有想到路由协议的问题,一直在两边进行测试,最后发现只能单方向共享文件,A可以访问B,但是B不能访问A,由于和A接的交换机是前人调试的,开始有点大意,认为应该不会在该交换机上作访问控制列表。
在排除了计算机系统的原因后,进入与A连接的交换机发现了一个acl 3000,其中有这个的几个rule ,将nebios的协议deny掉了,并且该acl 3000应用到了与A相连的交换机的trunk口的in方向上。该acl如图所示
发现了这个问题,一切就不难了,进入该trunk 口,讲acl 3000的访问控制列表去掉,重新测试,B机器即可访问A服务器上的共享文件夹。本文出自 “网络之路” 博客,请务必保留此出处http://chenpengpeng.blog.51cto.com/1117737/248679
相关文章推荐
- Yosimite 系统 “发生意外错误(错误代码-50)” (记一次macbook pro(mid2012) 自主维修排错经历)
- 一次使用OCI的排错经历
- 一次简单但又完整的先拿shell后提权的经历
- 记一次Linuxx下驱动安装排错经历
- 一个简单的局域网排错经历
- openstack虚拟机无法启动的一次排错经历
- 一次使用OCI的排错经历
- 关于nginx和cacti的一次排错经历
- 记一次WEB数据采集程序开发经历——对付简单的动态加载
- 一次使用OCI的排错经历
- 智能一代云平台(二十七):一次线上环境出问题排错经历
- 一次冗长繁琐的排错经历
- 一次简单的代码封装经历
- 【转贴】一次 JDBC 与 MySQL 因 “CST” 时区协商误解导致时间差了 14 或 13 小时的排错经历
- 一次冗长繁琐的排错经历
- 一次 JDBC 与 MySQL 因 “CST” 时区协商误解导致时间差了 14 或 13 小时的排错经历
- 一次简单的代码封装经历
- 用Python对KSC数据集处理的一次排错经历
- 从一次Windows网络编程排错经历中得出的一个可靠拆包算法
- 一次nginx 502 & mysql not contect 排错经历