公司小美手握一杯咖啡,懒洋洋打开自己的电脑,启动中的电脑如同出生的婴儿,脑海里什么都没有。什么都没有不可怕,可怕的是连一个名字 (IP地址)都没有。没有名字意味着几乎没有办法社交(和外界通信)。
上文说到“电脑没有IP地址几乎没有办法和外界通信”,潜台词是不是
“没有IP地址的电脑依然有基础(basic)的通信能力”?
对的!
至少还可以使用“0.0.0.0”做为自己的IP地址,向外界大声呼喊,哪位大神救救我,给我起个名字吧?
小婴儿的哭声,算是一种DHCP消息报文,使用IP承载,源IP = 0.0.0.0, 目的IP = 255.255.255.255 (广播)。
可婴儿附近没有大神,只有一台冷冰冰的交换机老大爷在睡觉,婴儿的哭喊声吵醒了老大爷,老大爷和蔼地对小婴儿说:“想让大神给你起名字,先要告诉我你的主人是谁?”(通过802.1x identify request报文发送,广播传送,因为此时婴儿还没有IP地址,0.0.0.0并不是一个有效的IP地址)
婴儿听到老大爷的话之后,在电脑弹出一个消息框,提示小美输入自己的域/用户名/密码。
小美快速输入以下关键信息:
域用户名:KDC / xiaomei
密码:secret
婴儿把“KDC / xiaomei”发给老大爷(802.1x identify response)。
老大爷不慌不忙地说:为了证明你的主人的真实身份,请你的主人把“Do you still love me tomorrow?”加密处理发给我!(802.1x Authentication Challenge)
婴儿的电脑使用一个 Keyed Hash算法:
Keyed Hash = MD5(Do you still love me tomorrow,secret)
= jks#jdd90uh$!@ea&sx23x182!
婴儿把这长长的的字符串“jks#jdd90uh$!@ea&sx23x182!”发给了老大爷。(Challenge Response)。
老大爷一个糟老头子,能判断出这个串串对不对?
不能!
但老头子有认证中心(KDC 域控制器)的电话(IP地址),而认证中心有一个后台数据库AD(Active Directory),库里保存着公司员工的用户名ID、密码、用户组、用户所在VLAN等所有认证、配置信息。
老大爷于是给认证中心打打电话(LDAP协议传输),将认证信息一股脑全告诉认证中心,包括:
(1) 用户名ID:xiaomei
(2) Challenge: Do you still love me tomorrow?
认证中心工作人员根据“xiaomei”ID从后台数据库里查询到小美的一切,包括密码,用户组,VLAN等参数。
然后工作人员也做了一次小美电脑一样的加密操作,得到的输出是“jks#jdd90uh$!@ea&sx23x182!”,把这个串串告诉老大爷。
老大爷眼一瞅,小美电脑与认证中心返回的值完全相同,都是“jks#jdd90uh$!@ea&sx23x182!”,认证成功。
老大爷向认证中心进一步查询“xiaomei”属于哪个用户组、哪个VLAN ID。
假设小美为HR部门,VLAN ID = 250。
老大爷配置完该端口VLAN ID = 250,并将大门打开(交换机端口open状态),允许婴儿的DHCP报文进入。
DHCP报文在广播域里继续蔓延,尽管没有遭遇到DHCP Server大神,但是却被VLAN 250的网关听到,网关暗戳戳地将该DHCP广播报文,通过单播的方式中继给DHCP Server大神,毕竟网关是知道DHCP Server大神身在何处。
在中继的过程中,源IP肯定是网关的,目的IP自然就是DHCP Server大神的。
准确地说,网关在这里充当中间人的角色,欺骗了婴儿,又欺骗了DHCP Server大神。
好在其它两人也不在乎,反正最后婴儿拿到了IP地址、掩码、网关、DNS Server配置。
有了这些参数,小美的计算机就可以自由地和外界通信。
接下来就是登录域,通过KDC域控制器的认证,然后小美就可以访问公司的资源,比如邮箱、打印机、文件共享等服务。
从上文可以看出,用户小美一共被认证了两次,第一次认证是为了获得网络(网络层)访问权限,第二次是为了获得公司资源的服务(应用层)访问权限。
欢迎关注公众号,阅读更多文章:
https://mp.weixin.qq.com/s/rTXg_u0qp_8pqkSUG1eLFw