公司小美手握一杯咖啡，懒洋洋打开自己的电脑，启动中的电脑如同出生的婴儿，脑海里什么都没有。什么都没有不可怕，可怕的是连一个名字 (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