winrm

winrm 协议报文：

 

当windows上存在了一个“未识别的网络”时（该网络被设置为了“公用”），于是winrm就不能使用，错误如下：

表现为： winrm请求虽然已经连接上了，但是不响应client发送的请求报文

理论上来讲，应该可以设置winrm listen的端口，不去listen那个“公用”的网络连接就可以了

 

参考资料：

vnc 学习

vncserve命令示例：

启动vnc：

 

查看有哪些session：

再启动一个：

查看：

删除指定session：

 

vncserve listen哪个端口？

每个session占用一个单独的端口，每个session同时只能有一个用户使用； 通过 :number 启动的session，其listen的端口号为 5900 + number

对于client来讲，使用vnc不同于其他服务，不需要指定端口号，而是指定number，如：

172.16.10.10:1

那么client就按照约定的规则，连接 172.16.10.10:5901 端口

linux 之多网卡问题

现象：

centos  6或7上配置两块（或者多块）网卡，如果默认网关配置在eth1（ip1）上，则通过另外一块网卡（如eth2（ip2））访问该主机就是访问不了的；但是，如果在eth2上做一个桥br2（ip2），该主机上面的虚拟机桥接该网卡，并且虚拟机的ip地址为ip3，则从其它主机上虽然访问不了ip2，但是可以访问ip3，就是说，访问虚拟机是正常的

调试：

  1. ping ip2 的时候，在eth2上是可以用tcpdump抓到数据包的，显示，服务器收到了数据包，但是出于某种原因，服务器没有回包
  2. 在服务器上使用ping -I eth2 ipx(这里假定其它主机的ip地址为ipx），eth2上没有数据包出现，显然，出于某种原因，服务器根本没有发包出去
  3. 两块网卡配置没有太多差异，唯一的差异就是默认网关在谁身上，默认网关很大程度上（不完全）表现在默认路由上，好吧，把默认路由删掉，给ipx单独添加一条路由，结果对上述测试没有任何影响

分析：

  1. 应该和服务器本身有关系，和其他外部的设备都没有关系
  2. 应该和内核有关系吧（晕，不好猜吧）

查资料：

  1. 发现和一个叫做 rp_filter的内核参数似乎有关系，修改如下：

    结果： 好了
    参考资料： http://blog.csdn.net/cybertan/article/details/9087829

    说明：

    1. 两个配置都需要，如果其中一个为1，则内核就参考谁
    2. 如果是br2桥接到eth2上的情况，访问br2是否正常则和eth2的该配置没关系，需要设置br2的该参数

关于rp_filter:

rp_filter : BOOLEAN
默认值为False

  • 1 – 通过反向路径回溯进行源地址验证(在RFC1812中定义)。对于单网卡主机和stub网络路由器推荐使用该选项。
  • 0 – 不通过反向路径回溯进行源地址验证。
  • 默认值为0，但某些发布在启动时自动将其打开。 (router默认会路由所有东西﹐就算该封包’显然’不属於我们的网路的。常见的例子﹐莫过於将私有 IP 泄漏到 internet 上去。假如某个网卡﹐其上设定的网络地址段為
    195.96.96.0/24﹐那么理论上不会有212.64.94.1 这样的地址段封包会到达这个网卡上。许多人都不想转发非本网段的数据包﹐因此核心设计者也打开了方便之门。在 /proc 裡面有些档案﹐透过它们您可以让核心為您做到这点。此方法被称為 “逆向路径过滤(Reverse Path Filtering)”。基本上﹐假如对此封包作出的回应﹐不是循其进入的网卡送出去﹐那它就被置之不理。)

docker mount on fly（容器动态挂卷）

理论上来讲，mount操作一定是发生在容器启动之后的（包括宿主机也如此）；但是，docker只是在create好run的时候提供了挂载卷的方法，一旦容器被创建，我们将再没有机会给容器挂载新的卷了；如果非要这么做的话，只能销毁、重新创建容器，好生繁琐。

既然理论上可以在容器启动之后挂载新的卷，docker没有提供相应的API，那么又该如何做呢？

  1. 办法一： hack一下docker，提供这方面的功能； 缺点： 随着docker版本的升级，代码维护起来比较麻烦
  2. 办法二： 从系统层面来实现，参考： https://jpetazzo.github.io/2015/01/13/docker-mount-dynamic-volumes/

办法二还是比较科学的，这里测试了一下，确实好用，脚本如下：

 

docker-enter 下载地址： https://github.com/jpetazzo/nsenter

注意：

  1. 这里用到了一个importenv的程序，可以参考容器环境变量来设置执行命令的环境变量，是个不错的办法，只是引入了一个其他的程序
  2. 这个要求容器中安装mount命令，该命令的依赖比较多，而且很少使用，所以，容器中一般都没有，需要手动安装，如果去掉那些依赖，单独安装一个mount命令会好一些
  3. 这个方法不适用于不基于块设备的文件系统，只有在/proc/mounts能正确得到块设备节点（上面谈到，并不总是能正确得到）的时候才能起作用。（比如： cephfs挂在的目录就不行）

ftp之EPRT/EPSV

参考资料：

https://tools.ietf.org/html/rfc2428

当知道了ftp有主动模式、被动模式，而且能在合适的时候选择使用合适的模式时，觉得自己NB了不少，然后在写简历的时候就写“精通ftp”。

突然，有一天，使用curl拉取ftp服务器上的文件，主动模式和被动模式都不好使了，但是使用原始的ftp client却没有问题，遂无所适从。

抓包分析发现，其实，二者差别不太大，就主动模式来讲，curl使用的是EPORT指令，而命令行ftp使用的是PORT 指令，没准儿问题就出现在这里；curl提供了一个–disable-eprt 选项，添加该选项，curl便不再使用EPORT 而是使用PORT了，问题解决；相应地，curl还有一个–disable-epsv 选项，告知curl在被动模式下，使用PSV 而不是EPSV;

E 即： extend

为了迎接ipv6的到来，ftp命令也做了一些支持ipv6的扩展，就比如说是EPORT、EPSV，但是有些ftp服务器可能不支持该特性或是禁用了该特性，这时候就只好退而求其次了

squid是一个很经典的代理，是支持ftp的，默认情况下是使用的新的ftp指令，如果遇到上述情况，可以通过修改squid配置文件来禁用扩展的指令： ftp_eprt off  或  ftp_epsv off  ( http://www.squid-cache.org/Doc/config/ftp_eprt/ )

当portal认证遇上https

参考资料：

  1. http://www.cnblogs.com/lightsong/p/5229411.html
  2. http://serverfault.com/questions/596844/ssl-certificate-errors-in-captive-portals
  3. https://groups.google.com/forum/#!topic/android-platform/ATSxh0kG7cc

背景：

对于公司内部的无线网络来讲，如果只有一个固定的无线密码，是不科学的；公司员工离职之后依然可以使用公司的网络，每有员工离职就修改密码也不现实；常见的解决办法就是使用portal认证。portal认证说来也容易，在网络设备上配置一下就行了，但是，如果要做一个能用的portal认证还是需要了解一些相关知识的，比如，如何实现使用公司员工账号进行认证？这个问题相对好解决，这里不去讨论；下面讨论一个几乎没有完美解决办法的问题。

一般来讲，连接到一个需要portal认证的网络后，系统会自动弹出来一个portal认证页面（哇赛，咋实现的?），如果手欠，没有登录就关掉了，如何再次打开该页面？

首先，如果不小心关掉了portal认证页面也没关系，打开浏览器，输入http://baidu.com 就能看到portal认证页面； 问题是，百度早使用https了，你很可能输入的会是https://baidu.com ,这样的话，你就看不到portal页面，你只好很生气给给网管打电话：….

网管也很郁闷，好不容易做了点儿事儿，还得因为这个经常挨骂，窝心啊…

下面我们就来讨论一下几个问题：

  1. 为什么连网之后会自动弹出portal认证页面
  2. 为什么输入http://baidu.com 就能看到认证页面
  3. 为什么输入https://baidu.com 就看不到认证页面

先说问题2：

  1. 你连网之后，按照管理员的配置，你的网关上配置了portal认证，你想上网的话，网关必然是知道的，而且网关知道你还没有认证过呢；刚好网关发现你发起的是一个http请求，然后就根本不转发你的请求，而是直接把你重定向到了一个早已准备好的portal认证页面，这一切都得益于http是明文的，于是你就看到了portal认证页面

再说问题3：

  1. 通过问题1的分析可知，因为https是密文的，网关就没有能力将你重定向到portal认证页面了

再说问题1：

  1. 通过上述的分析，操作系统的网络管理部件完全可以在连网之后直接发送一个http请求探测一下是否被拦截了，如果被拦截了，则很可能就是一个portal认证页面，然后弹窗显示就行了，真的吗？
  2. 事实上就是这么实现的
    1. mac上默认访问的http地址是： http://captive.apple.com/hotspot-detect.html
    2. android 手机上据说访问的是： http://clients3.google.com/generate_204
    3. windows上访问的是： http://www.msftncsi.com/ncsi.txt

其实上面的做法存在一些问题，网络上为了安全都在启用https，但是上述几个地址却是内置的http请求，如果进行dns投毒，则很容易让用户访问到自己定制的页面的