使用Hyper-V VLAN功能组建受隔离的网络环境
使用Hyper-V VLAN功能组建受隔离的网络环境
在开始今天的分享前，gOxiA 带着大家前先了解下面的截图，这样才能更好的理解所要分享的内容。在一个企业网络内（Corp LAN），已经部署了DC、DNS、DHCP、WDS等服务器，是一个完整的生产环境。在 10.1.50.x 的子网内 gOxiA 有三台 Hyper-V 主机（两台基于 Windows 10，一台基于 Windows Server 2016）进行工作相关的测试和评估。
默认情况下三台 Hyper-V 主机与 Corp LAN 是可以相互访问的，这个应该很容易理解吧；现在为这三台Hyper-V 主机分别创建了虚拟交换机 vNet-LAN50，那意味着其上的虚拟机将从 10.1.50.x 获取网络地址，并运行相互访问，到这里也很容易理解吧；由于一些测试需要进行隔离，通常会在Hyper-V 主机上创建 VMs Only LAN，仅供当前Hyper-V 主机上的虚拟机相互访问，或在当前 vNet-LAN50 上启用 VLAN 分配 ID 20 进行隔离，到这里相信也能理解；OK，我们继续，现在由于一个测试任务过于庞大所需的硬件资源很高，无法在一台Hyper-V主机上进行，需要现有的三台 Hyper-V 主机组网使用，且不变动现有的物理网络环境，同时实现与现有逻辑网络隔离。
如果为每台虚拟机创建单独的网络，如192.168.192.x，是可以实现相互通讯的，但是并未完全实现逻辑网络的隔离，假如虚机部署了 DHCP 服务，那么极有可能会对现有的 Corp LAN 产生影响。但是启用虚机 VLAN 后，怎么实现跨 Hyper-V 主机访问呢？！按理说 vNet-LAN50 这个虚拟交换机的物理接口是 Hyper-V 主机上与 10.1.50.x 相连的网卡，由于是透明通讯，虚拟机设置 VLAN20 后理应透过 vNet-LAN50 与其他 Hyper-V 主机上 VLAN20 的虚机通讯，但是现实很残酷并非如所想的那样！！！
经过测试需要通过 Hyper-V 的 Virtual Switch Manager（虚拟交换机管理器）为当前网络即 vNet-LAN50 也启用 VLAN ID 20，才能实现跨 Hyper-V 主机 的 VLAN 段虚机互访。
虽然该法实现了最终的需求，但也确实与现有逻辑网络完全隔离，这意味着原有 10.1.50.x 段中的其他设备将无法访问这三台 Hyper-V 主机，否则也必须修改 VLAN 为 20。（如果 Hyper-V 主机是多宿主，倒是很好解决！）
深入探讨 网站想要使用你计算机上的程序打开Web内容
深入探讨 网站想要使用你计算机上的程序打开Web内容
gOxiA 因为工作需要最近在做与桌面虚拟化相关的技术内容，期间就遇到了“网站想要使用你计算机上的程序打开 Web 内容”的问题。具体是在用户安装 VDA 客户端后，通过 IE 访问 VDI 门户时会弹出这个提示，如下图所示。其实问题是比较简单的，为了避免下次再弹出提示框，我们通常会复选“不再对此程序显示此警告”，然后点击“允许”。这样在访问 VDI 门户后就会直接启动 VDA 客户端正常访问。
之后 gOxiA 又用 Microsoft Edge 访问测试了一下，会直接提示下载一个扩展名为 ICA 的文件，而这个 ICA 在当前系统上被注册为使用一个特定的应用程序打开。
也就是说在整个访问过程中是浏览器下载了一个文件，然后由指定的应用程序打开它，当在 IE 浏览器环境下时可通过复选“不再对此程序显示此警告”然后“允许”来实现通过应用程序直接打开文件的操作，这样用户体验就会更顺畅。
那么问题来了，用户说如果我复选了“不再对此程序显示此警告”，然后点击了“不允许”，可发现是误操作了该怎么办呢？该如何恢复呢？为此，gOxiA 检查了 IE 设置还真的不像禁用弹出窗口、或兼容性视图设置那样会有明确的设置选项且支持修改操作。由于通常也都是习惯于正确的操作，确实会忽略掉如果复选不再显示警告并点击了不允许会有什么结果。
期间也有咨询过微软支持，但也没有准确的解答，无奈只能自己研究 。使用 Procmon 抓包来看看这一设置都做了什么操作？！
还挺轻松立刻就锁定了位置，当我们在弹出“网站想要使用你计算机上的程序打开Web内容”的警告窗体上，复选“不再对此程序显示次警告”，并点击“允许“后，iexplore 进程会在注册表的 “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\” 下生成一个新的 GUID 项，并写入该程序的相关键值。其中 AppPath 和 AppName 是容易理解的，也没有什么特殊之处，而 Policy 则是非常关键，默认键值为”3“。如果我们修改了这个值，例如：2，那么再下次访问时又会重新弹出警告让用户选择，只有值为3时才会默认通过安装的应用打开下载的 ICA，而不再弹出任何提示。此外，在重新复选并允许后 iexplore 进程并不会修改之前已经添加的项和对应的键值，而是会重新生成一个新的项，很有意思！
接下来 gOxiA 又重新做了一次抓包，但这次操作是复选不再提示后不允许运行，但在抓包数据中分析发现，执行这一操作并不会写入任何设置。也就是说即使用户复选了不再提示，只要点击的是不允许，那么前面的复选设置是不会起到任何效果的。
至此，答案已经出来，我们也不必担心用户是否会进行误操作，如果出现 IE 访问 VDI 门户没有启动 VDA 客户端的故障问题，那么直接从 VDA 下手排错即可，无需再在 IE 身上徘徊！
后来微软支持也给找到了一篇文档，原来早在2009年时就有微软人士详细讲解过这个安全功能，具体可参考下面这篇 Blog ：
[Tips]HOWTO: 关闭 Surface Pro 4 屏幕自动旋转功能
HOWTO: 关闭 Surface Pro 4 屏幕自动旋转功能
用户的需求总是各式各样，不可能完全满足，就在上周 gOxiA 遇到了一个“奇葩”的支持请求，一位 Surface Pro 4 用户希望不论在何时何地，何种姿态下，都不要自动旋转 Surface Pro 4 的屏幕，希望在连接键盘时就是一个笔记本电脑。
这个需求其实也容易理解，用户使用习惯也好，强迫症也好，总之不希望屏幕在连接键盘时自动旋转。那么要解决这个问题禁用自动旋转不就行了，可事实是当 Surface Pro 4 在连接键盘后默认的横屏工作模式下“旋转锁定”是不可用的，必须旋转至竖屏后方能锁定。
现在感觉到用户的需求“奇葩”了，咨询了 Surface 在线技术支持，人家解释说键盘连接不稳定，让重新连接键盘，可是那么多台都是这样吗？后来人家又改口说是设计使然，并且也没有关闭硬件功能的方案，还让把驱动卸载掉再试，gOxiA 也是只能放弃了！
自己研究还是妥妥的，既然拔掉键盘能够关闭旋转锁定，那就先拔掉键盘，关闭旋转锁定后再接上键盘，OK！用户需求搞定。但是这个 Workaround 也有不足，前面讲过键盘连接后“旋转锁定”是不可用状态，那也意味着用户如果突然想启用屏幕自动旋转时不能不拔掉键盘重新设置。
