IPv6地址规则

一、IPv6顾名思义,其地址长128bit(2的64次方)。
为了便于记忆,通常采用16进制表示,每4个16进制为一段,共8段(8*4*4=128):
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX
其中,XXXX范围为0000-FFFF

二、IPv6地址表示,主要有下面几种:
1、首选法,即每一位都写全,比如:
0234:0000:0000:0000:1234:0000:0000:2234
0000:0000:0000:0000:0234:0000:0000:2234
但这样不便于书写,于是人们想办法来进行缩写

2、将相连的0000,表示为::,但只允许出现一次,上面的地址可以缩写为
0234::1234:0000:0000:2234
::0234:0000:0000:2234

3、将每一段的前导0去掉,这样上面的地址变为
234::1234:0:0:2234
::234:0:0:2234
这样就便于人们记忆了

4、另外,IPv6可以兼容IPv4:
IPV4兼容的IPV6地址,用于在IPV4网络上建立自动隧道,以传输IPV6数据包:
0000:0000:0000:0000:0000:0000:YYY.YYY.YYY.YYY
其中,YYY范围为000-255
映射IPV4的IPV6地址,仅用于拥有IPV4和IPV6双协议栈节点的本地范围:
0000:0000:0000:0000:0000:FFFF:YYY.YYY.YYY.YYY
其中,YYY范围为000-255

三、IPv6的地址分为单播(Unicast)、多播(Multicast)和任意播(Anycast)。
其中单播分为本地链路,本站点地址,ULA,可聚合全球单播地址,回环。
1、本地链路地址(Link-Local Addresses):同一链路相邻节点之间通讯,不能被路由
地址前10个bit是1111 1110 10,规则为FE80::/64,即FE80::/10+54bit0+EUI-64
FE80:0000:0000:0000:EUI-64

2、本地站点地址(Site-Local Addresses):只能在一个站点内使用,私有地址
地址前10个bit是1111 1110 11,规则为FEC0::/48,即FEC0::/10+38bit0+16bit子网表示+EUI-64
FEC0:XXXX:XXXX:XXXX:EUI-64

3、唯一的本地IPv6单播地址(ULA,Unique Local IPv6 Unicast Address):用于替代Site-Local Addresses
地址规则为FD00::/8,后面跟一个被称为全局ID的40bit随机标识符。

4、可聚合全球单播地址(Aggregatable Global Unicast Addresses):公网地址,全球路由
前三bit为001,第一个地址为:
2000:0000:0000:0000:0000:0000:0000:0000
最后一个地址为:
3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

5、回环地址:
0000:0000:0000:0000:0000:0000:0000:0001
0:0:0:0:0:0:0:1
::1

6、未指定地址(Unspecified address)
0000:0000:0000:0000:0000:0000:0000:0000
0:0:0:0:0:0:0:0
::

四、多播地址:一对多
前8个bit为1111 1111,地址规则为FE00::/8
FF01::到FF0F::的多播地址是保留专用地址
FF01::1 节点本地范围所有节点多播地址
FF02::1 链路本地范围所有节点多播地址
FF01::2 节点本地范围所有路由器多播地址
FF02::2 链路本地范围所有路由器多播地址
FF05::2 站点本地范围所有路由器多播地址

五、任意播:任意播是多个设备共享一个地址,应用在一到附近模式(one-to-nearest)
发送方发送一个以任意播为目标地址的包,当路由器接受到这个包以后,就转发给具有这个地址的离它最近的设备。
任意播地址是从单播地址中划分出来的,对于那些没有配备任意播的的地址就是单播地址;但是当一个单播地址分配给不止一个接口的时候,单播地址就成了任意播地址。
所以单播地址与任意播地址的规则是一样的。

六、EUI-64计算方法:
假设电脑的MAC是00:0C:85:AB:50:01;
首先在MAC地址正中间插入FFFE,得到00:0C:85:FF:FE:AB:50:01
然后由左到右第七bit置反,得到02:0C:85:FF:FE:AB:50:01
将其改写为EUI-64规则,得到020C:85FF:FEAB:5001
需要对第七位取反的原因:
在MAC地址中,第7比特为1表示本地管理,为0表示全球管理
在EUI-64格式中,第7位为1表示全球惟一,为0表示本地惟一

七、隧道协议地址转换
6over4地址
[64bit-prefix]:0:0:WWXX:YYZZ,其中的WWXX:YYZZ是w.x.y.z IPv4公共地址的十进制点号表示法,用于一个使用6to4协议的隧道机制的节点。
6to4地址
2002:WWXX:YYZZ:[SLA ID]:[Interface ID],用于表示一个使用6to4协议的隧道机制节点。

Wireshark过滤规则

Wireshark是一个很好用的sniffer工具,插件十分强大。有时,为了判断问题,在日常工作中也会用到一些,现在记录一部分常用的过滤规则:

1、运算符

lt < 小于
le <= 小于等于
eq == 等于
gt > 大于
ge >= 大于等于
ne != 不等
and && 与操作
or || 或操作
not ! 非操作

2、ip、mac和port过滤

#过滤ip地址为192.168.1.102的全部数据包
ip.addr eq 192.168.1.102
#过滤从192.168.1.102发来的数据包 或 发往192.168.1.102的数据包
ip.src eq 192.168.1.102 or ip.dst eq 192.168.1.102

#过滤MAC地址为00:00:00:01:02:03的所有包
eth.add eq 00:00:00:01:02:03
#过滤MAC地址为00:00:00:01:02:03发送的包 或 发往00:00:00:01:02:03的包
eth.src eq 00:00:00:01:02:03 or eth.dst eq 00:00:00:01:02:03

#过滤8080端口全部tcp数据包(接收和发送)
tcp.port eq 8080
#过滤8080端口发送的全部tcp数据包 或 发送到8080端口全部tcp数据包
tcp.srcport eq 8080 or tcp.dstport eq 8080

#过滤21端口全部udp数据包(接收和发送)
upd.port eq 21
#过滤21端口发送的全部udp数据包 或 发送到21端口全部udp数据包
udp.srcport eq 21 or udp.dstport eq 21

#过滤1024以内端口数据包
tcp.port <= 1024

#去掉tcp数据包
!tcp
#或
not tcp

3、包长度过滤

#udp报文长度等于100
udp.length eq 100

#udp数据长度等于92
udp.len eq 92

#经常可以用到eth(farme),ip,arp,tcp,udp等协议的包长度
#注意区分包长度和payload长度

4、HTTP协议

#过滤GET方法的HTTP数据包
http.request.method == "GET"

#按URI过滤HTTP数据包
http.request.uri == "/image/logo.gif"

#按内容过滤HTTP数据包
http contains "Content-Type: application/dicom"

5、匹配规则

\d 0-9的数字
\D \d的补集
\w 单词字符,即大小写字母、0-9的数字、下划线
\W \w的补集
\s 空白字符,包括换行符\n、回车符\r、制表符\t、垂直制表符\v、换页符\f
\S \s的补集
. 除换行符\n外的任意字符
.* 匹配任意文本
[…] 匹配[]内所列出的所有字符
[^…] 匹配非[]内所列出的字符
^ 表示其后的字符必须位于字符串的开始处
$ 表示其前面的字符必须位于字符串的结束处
\b 匹配一个单词的边界
\B 匹配一个非单词的边界
{n} 匹配前面的字符n次
{n,} 匹配前面的字符n次或多于n次
{n,m} 匹配前面的字符n到m次
? 匹配前面的字符0或1次
+ 匹配前面的字符1次或多于1次
* 匹配前面的字符0次或式于0次

6、包匹配

#字节匹配,比如匹配payload第一个字节0x14的UDP数据包
udp[8]==14

#范围匹配,经常使用到tcp[offset,n],比如匹配payload的前4个字节0x0004002a
udp[8:4]==00:04:00:2a

#正则匹配,要用match,比如匹配HTTP1.1协议的数据包
tcp[20:] matches "^GET [ -~]*HTTP/1.1\\x0d\\x0a"

Nginx反向代理upstream跳转错误

前两天架设Nginx反向代理时,用ip hash的方法设置了几个upstream(backend1,backend2,backend3…)

发现有一个网站总是去查找
http://backend2/
最后域名解析失败。
可其他网站都是好的啊。

无奈用Firebug看了一下网页,http header中赫然写着一行
baseurl=http://backend2/

找出jsp文件,发现是MyEclipse生成模板是,会加这么几行

<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>

<head>
    <base href="<%=basePath%>"]
</head>

Nginx做负载均衡

只需要3步:

1、在nginx.conf中的http段增加upstream服务器

    upstream backend{  
        server 192.168.140.15:18080 weight=2;  
        server 192.168.140.81:18080;  
        server 192.168.140.82:18080;  
    }

2、在nginx.conf中的http段增加server

    server {
        listen       18080;
        server_name  localhost;

        location / {
            proxy_pass http://backend/;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

3、重启Nginx

正向代理和反向代理

1、forward proxy
正向代理是一个位于client和origin server之间的proxy,为了从origin server取得内容,client向proxy发送一个请求并指定目标(origin server),然后proxy向origin server转交request并将获得的resopnse返回给client。client必须要进行一些特别的设置才能使用正向代理。

2、reverse proxy
反向代理对于client而言就像是origin server,并且clinet不需要进行任何特别的设置。client向反proxy发送普通请求,接着proxy将判断向何处(origin server)转交request,并将response返回给client,proxy在client看起来就像origin server一样。

3、两者区别
从网络角色来讲:
正向代理隐藏的是client,clinet可以感觉到正向代理的存在,proxy对server隐藏了client的细节。
反向代理隐藏的是origin server,client感觉不到反向代理的存在,proxy对clinet隐藏了server的细节。

从用途上来讲:
正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径,正向代理还可以使用缓冲特性减少网络使用率。
反向代理的典型用途是将防火墙后面的服务器提供给Internet用户访问,反向代理还可以为后端的多台服务器提供负载平衡,或为后端较慢的服务器提供缓冲服务。另外,反向代理还可以启用高级URL策略和管理技术,从而使处于不同web服务器系统的web页面同时存在于同一个URL空间下。

从安全性来讲:
正向代理允许client通过它访问任意网站并且隐藏client自身,因此你必须采取安全措施以确保仅为经过授权的客户端提供服务。
反向代理对clinet都是透明的,clinet并不知道自己访问的是一个代理。

4、透明代理
透明代理技是指客户端感觉不到代理的存在,不需要在浏览器中设置任何代理,客户只需要设置缺省网关,客户的访问外部网络的数据包被发送到缺省网关,而这时缺省网关运行有一个代理服务器,数据实际上被被重定向到代理服务器的代理端口,即由本地代理服务器向外请求所需数据然后拷贝给客户端。理论上透明代理可以对任何协议通用。一般透明代理用于防火墙技术比较多。

Nginx中的upstream

Nginx中upstream有以下几种方式:

1、轮询(weight=1)
默认选项,当weight不指定时,各服务器weight相同,
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

upstream bakend {
server 192.168.1.10;
server 192.168.1.11;
}

2、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
如果后端服务器down掉,能自动剔除。
比如下面配置,则1.11服务器的访问量为1.10服务器的两倍。

upstream bakend {
server 192.168.1.10 weight=1;
server 192.168.1.11 weight=2;
}

3、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session不能跨服务器的问题。
如果后端服务器down掉,要手工down掉。

upstream resinserver{
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}

4、fair(第三方插件)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。

upstream resinserver{
server 192.168.1.10:8080;
server 192.168.1.11:8080;
fair;
}

5、url_hash(第三方插件)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存服务器时比较有效。
在upstream中加入hash语句,hash_method是使用的hash算法

upstream resinserver{
server 192.168.1.10:8080;
server 192.168.1.11:8080;
hash $request_uri;
hash_method crc32;
}

设备的状态有:
1.down 表示单前的server暂时不参与负载
2.weight 权重,默认为1。 weight越大,负载的权重就越大。
3.max_fails 允许请求失败的次数默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误
4.fail_timeout max_fails次失败后,暂停的时间。
5.backup 备用服务器, 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

VPN有效,SVN连不上

这同样是一个超级悲剧的事情,在同事家,连上了公司VPN,
准备上传代码,但SVN无论如何都告诉我,“俺找不到服务器啊”

这个。。。

我刚在宾馆就是可以连上的,而且速度也很快。
那就找原因吧。

同样是ipconfig -all一下,发现,妈呀,
这些人居然把路由的网段和公司内部网段设成了相同的

不由倒吸一口凉气,
你用固定IP也就罢了,麻烦一些我也忍了,
可以用DCHP为什么还要用同一个网段啊

哥哥们啊。。。

能获取IP却连不上互联网

由于公司项目需要外出,就在一家宾馆住下了,闲着无聊,就连上网线准备看看新闻。
把IP地址获取模式设为DHCP,IP也正常获取到了,192.168.1.???,但无论如何都连不上网
打电话向前台确认,他们百般保证,绝对可以上网。

于是ipconfig -all一下,发现,居然没有网关。
这个可是个大悲剧了。

查了整整半个小时,发现:
天啊,居然是因为,VMWare的一块网卡的地址竟然是192.168.1.1

面壁去了。。。

话说回来,这不是第一次了
前几个月在EMC测试产品的时候,
别人的笔记本都可以联网,就是我的没反应
同样是因为这块VMWare的虚拟网卡

继续面壁。。。