大千世界 » Tech http://www.zhangdaqian.net Hold Infinity in the palm of your hand Thu, 05 Jan 2012 13:59:47 +0000 http://wordpress.org/?v=2.8.5 en hourly 1 Log Myself http://www.zhangdaqian.net/blog/log-myself.htm http://www.zhangdaqian.net/blog/log-myself.htm#comments Thu, 25 Aug 2011 15:31:59 +0000 admin http://www.zhangdaqian.net/blog/log-myself.htm 首先我面壁，我是码农！

我公司有一套自己写的log组件，这个组件最大的神奇之处就在于跨进程的log。这个是我第一次见，之前写的程序也没有这方面需求，只是自己log写文件就ok了。

但是我有个想法，这跨进程挺好的，可是万一我想跨机器log了，这不就嗝屁了吗？

不行！

于是自己折腾了一个log。当然是通过tcp了，这样有网络就行了。整个log只用了一个锁，跨进程间是不会互相影响的。即便这个锁，也是加在一个循环队列的buffer上的。以后完全有可能使用无锁的方式优化掉，这就相当于这个log组件完全无锁。唯一的缺点就是需要跑一个logserver来接收程序的log，当然你也是连在这个server上看log的。同时正在做一个web的前台，用户可以再前台设置log级别，查看log。最后，亲，跨平台的哦，支持windows/linux , c、c++、java哦，欢迎购买，包邮哦！

目前粗则了下性能，本机能够达到每秒5w+，log一个不丢。比较了下，功能没有log4cxx强大，但速度比log4系列的有优势。而且可以动态调整log级别。另外，在log极多的情况下，查看log的用户数越多，性能会下降。

然后，我深知诸多大神鄙视这种造轮子的行为，可TMD的真的没找到能跨机器log的东西啊啊啊啊啊。。。。。

log4CXX到是有socket的appender，可那个东西的效率实在不能接受的。

下面主要说具体的做法：

其实这玩意说白了就两件事：

1、从tcp接收纯文本。

2、把文本从tcp发出去。

但搞对了就不那么容易了，搞好了，就更难了。

如果你尝试写一个，你会发现以下的问题

1、tcp粘包的，拆包的问题。既如何区分出一条完整的log，这个不难。

2、网络异步的发送和接收。当然不能用同步的，那会导致导致恩你自己想。。。

3、log的格式自定义，这个有点难度。

4、动态log级别调整，这个也有难度。

5、网络异常后自动恢复。这个不难。

搞好了，就涉及到以下问题。

1、尽一切可能减少copy。这个用了shareptr来解决。

2、尽可能减少malloc。这个找了一个mempool来解决。（效果不明显）

3、在lan上是没有问题，在wan上就需要考虑数据的压缩。log都是纯文本，压缩来减少数据传送。当然，配套的读log的东西也是要自己写的。

4、多线程的问题，每连接一个线程的模型是不能接受的。事实上，数据接收和处理各有一个线程，两个线程而已（当然线程数目是可以配置的）。数据接收和发送各有一个thread pool。

5、界面。这个仁者见仁了，可能大部分人认为log还有个界面，不能理解。事实上，这玩意很有用，真的！

插播新闻：c++0x上个星期投票通过了！！！

boost是个好东西，居家旅行，杀人放火必备良器。boost:: shared_ptr boost::function boost:: bind boost::asio这些东西都太犀利了。 当然学习成本是有点高，而且这玩意难调得一腿啊，当时少写了个括号，报了几十个错误，还没一个错误正确指出错误的地方，shit！不过用熟悉了，也就知道怎么回事了，运行时错误，跟到boost代码里面，大部分也都豁然开朗了。现在公司里面就用stl，我经常想，要是这玩意用boost，至于写那么多线程，那么多锁吗。。。。还有就是那个ptlib，也不是说它不好，可是这玩意太小众了，还有一堆莫名其妙的地方。资料也木有，只能看源码，不过我也不想看，有时间看他的，还不如看看boost的。

看源码的话，现在小有点经验了，体验也多了，记得以前最怕看别人写的东西。在调程序的时候，看到boost的源码，当时就想说tnnd，竟然可以这样写。。。

今天就废话这么多，看哈利波特去了。

Random Posts

]]> http://www.zhangdaqian.net/blog/log-myself.htm/feed 0 无题也是一种题目 http://www.zhangdaqian.net/blog/%e6%97%a0%e9%a2%98%e4%b9%9f%e6%98%af%e4%b8%80%e7%a7%8d%e9%a2%98%e7%9b%ae.htm http://www.zhangdaqian.net/blog/%e6%97%a0%e9%a2%98%e4%b9%9f%e6%98%af%e4%b8%80%e7%a7%8d%e9%a2%98%e7%9b%ae.htm#comments Tue, 12 Apr 2011 14:07:09 +0000 admin http://www.zhangdaqian.net/blog/%e6%97%a0%e9%a2%98%e4%b9%9f%e6%98%af%e4%b8%80%e7%a7%8d%e9%a2%98%e7%9b%ae.htm 每一个幸福的奥特曼背后都有一只默默挨打的小怪兽。

每一个复杂的问题的背后都有一个简单的原因。

Random Posts

]]> http://www.zhangdaqian.net/blog/%e6%97%a0%e9%a2%98%e4%b9%9f%e6%98%af%e4%b8%80%e7%a7%8d%e9%a2%98%e7%9b%ae.htm/feed 0 在Android上使用sip http://www.zhangdaqian.net/blog/%e5%9c%a8android%e4%b8%8a%e4%bd%bf%e7%94%a8sip.htm http://www.zhangdaqian.net/blog/%e5%9c%a8android%e4%b8%8a%e4%bd%bf%e7%94%a8sip.htm#comments Mon, 16 Aug 2010 16:55:51 +0000 admin http://www.zhangdaqian.net/blog/%e5%9c%a8android%e4%b8%8a%e4%bd%bf%e7%94%a8sip.htm 今天终于搞通了android to any voice。

其实android到gtalk，到msn，这些都不是问题，到qq这个不要想了，sigh！

主要是找到一家可靠的sip服务商，资费足够便宜，通话清晰。我用的LocalPhone，他到china的费率是0.12rmb，比市话便宜。在android上用fring做为sip的接入端。fring也支持msn，gtalk等。你要是在用个google voice就更好了。

顺便推荐一个美剧真爱如血，比较赞，（HBO出品，口味比较重）

Random Posts

]]> http://www.zhangdaqian.net/blog/%e5%9c%a8android%e4%b8%8a%e4%bd%bf%e7%94%a8sip.htm/feed 0 vlc太恶心了 http://www.zhangdaqian.net/blog/vlc%e5%a4%aa%e6%81%b6%e5%bf%83%e4%ba%86.htm http://www.zhangdaqian.net/blog/vlc%e5%a4%aa%e6%81%b6%e5%bf%83%e4%ba%86.htm#comments Tue, 25 May 2010 13:43:56 +0000 admin http://www.zhangdaqian.net/blog/vlc%e5%a4%aa%e6%81%b6%e5%bf%83%e4%ba%86.htm 情况是这样的，使用helix做rtp relay服务器，后来发现在server2003下helix工作ok，在linux下，无法工作。

我抓狂啊！

好吧！我来查，会不会是操作系统的问题？ok，我装了rad hat 4，我装了centos，还是依旧。好吧，会不会是虚拟机的问题？我上服务器上测。still，我想跳楼了。。。。。

然后我怀疑sdp的问题，我直接把server2003下可以正常工作的文件拷过了，还是不行。。。

然后折腾了两天，终于发现vlc生成的sdp中，源使用windows机器名，放linux当然跑不起来。。。。。。

疯了。。。。。。。。。。。。

Random Posts

]]> http://www.zhangdaqian.net/blog/vlc%e5%a4%aa%e6%81%b6%e5%bf%83%e4%ba%86.htm/feed 1 NAT Order of Operation http://www.zhangdaqian.net/blog/nat-order-of-operation.htm http://www.zhangdaqian.net/blog/nat-order-of-operation.htm#comments Thu, 08 Oct 2009 10:16:28 +0000 admin http://www.zhangdaqian.net/blog/nat-order-of-operation.htm Introduction

This document illustrates that the order in which transactions are processed using Network Address Translation (NAT) is based on whether a packet is going from the inside network to the outside network, or from the outside network to the inside network.

Prerequisites

Requirements

Readers of this document should have knowledge of the following topic:

  • Network Address Translation (NAT). For more information on NAT, see How NAT Works.

Components Used

This document is not restricted to specific software and hardware versions.

Note: The information in this document is based on the Software Version, Cisco IOS® Software Release 12.2(27)

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.


NAT Overview

In the table below, when NAT performs the global to local, or local to global, translation is different in each flow.

Inside-to-Outside

Outside-to-Inside

  • If IPSec then check input access list

  • decryption – for CET (Cisco Encryption Technology) or IPSec

  • check input access list

  • check input rate limits

  • input accounting

  • policy routing

  • routing

  • redirect to web cache

  • NAT inside to outside (local to global translation)

  • crypto (check map and mark for encryption)

  • check output access list

  • inspect (Context-based Access Control (CBAC))

  • TCP intercept

  • encryption

  • Queueing

  • If IPSec then check input access list

  • decryption – for CET or IPSec

  • check input access list

  • check input rate limits

  • input accounting

  • NAT outside to inside (global to local translation)

  • policy routing

  • routing

  • redirect to web cache

  • crypto (check map and mark for encryption)

  • check output access list

  • inspect CBAC

  • TCP intercept

  • encryption

  • Queueing

NAT Configuration and Output

The following example demonstrates how the order of operations can effect NAT. In this case, only NAT and routing are shown.

5a-1.gif

In the above example, Router-A is configured to translate the inside local address 171.68.200.48 to 172.16.47.150, as shown in the configuration below.

!
version 11.2
no service udp-small-servers
no service tcp-small-servers
!
hostname Router-A
!
enable password ww
!
ip nat inside source static 171.68.200.48 172.16.47.150

              !--- This command creates a static NAT translation !--- between 171.68.200.48 and 172.16.47.150 
            
ip domain-name cisco.com
ip name-server 171.69.2.132
!
interface Ethernet0
 no ip address
 shutdown
!
interface Serial0
 ip address 172.16.47.161 255.255.255.240
 ip nat inside

              !--- Configures Serial0 as the NAT inside interface
            
 no ip mroute-cache
 no ip route-cache
 no fair-queue
!
interface Serial1
 ip address 172.16.47.146 255.255.255.240
 ip nat outside

              !--- Configures Serial1 as the NAT outside interface
            
 no ip mroute-cache
 no ip route-cache
!
no ip classless
ip route 0.0.0.0 0.0.0.0 172.16.47.145

              !--- Configures a default route to 172.16.47.145
            

ip route 171.68.200.0 255.255.255.0 172.16.47.162
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 password ww
 login
!
end

The translation table indicates that the intended translation exists.

Router-A#show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.47.150      171.68.200.48      ---                ---

The following output is taken from Router-A with debug ip packet detail and debug ip nat enabled, and a ping issued from device 171.68.200.48 destined for 172.16.47.142.

Note: Debug commands generate a significant amount of output. Use them only when traffic on the IP network is low, so other activity on the system is not adversely affected. Before issuing debug commands, please see Important Information on Debug Commands.

IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=172.16.47.161 (local), d=171.68.200.48 (Serial0), len 56, sending
    ICMP type=3, code=1
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=172.16.47.161 (local), d=171.68.200.48 (Serial0), len 56, sending
    ICMP type=3, code=1
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=171.68.200.48 (Serial0), d=172.16.47.142, len 100, unroutable
    ICMP type=8, code=0
IP: s=172.16.47.161 (local), d=171.68.200.48 (Serial0), len 56, sending
    ICMP type=3, code=1

Since there are no NAT debug messages in the output above, you know that the existing static translation is not being used and that the router does not have a route for the destination address (172.16.47.142) in its routing table. The result of the non-routable packet is an ICMP Unreachable message, which is sent to the inside device.

However, Router-A has a default route of 172.16.47.145, so why is the route considered non-routable?

Router-A has no ip classless configured, which means if a packet destined for a “major” network address (in this case, 172.16.0.0) for which subnets exist in the routing table, the router does not rely on the default route. In other words, issuing the no ip classless command turns off the router’s ability to look for the route with the longest bit match. To change this behavior, you have to configure ip classless on Router-A. The ip classless command is enabled by default on Cisco routers with IOS Version 11.3 and above.

Router-A#configure terminal
Enter configuration commands, one per line.  End with CTRL/Z.
Router-A(config)#ip classless
Router-A(config)#end

Router-A#show ip nat translation
%SYS-5-CONFIG_I: Configured from console by console nat tr
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.47.150      171.68.200.48      ---                ---

Repeating the same ping test as before, we see that the packet gets translated and the ping is successful.

Ping Response on device 171.68.200.48

D:\>ping 172.16.47.142
Pinging 172.16.47.142 with 32 bytes of data:

Reply from 172.16.47.142: bytes=32 time=10ms TTL=255
Reply from 172.16.47.142: bytes=32 time<10ms TTL=255
Reply from 172.16.47.142: bytes=32 time<10ms TTL=255
Reply from 172.16.47.142: bytes=32 time<10ms TTL=255

Ping statistics for 172.16.47.142:
    Packets: Sent = 4, Received = 4, Lost = 0 (0%)
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  10ms, Average =  2ms

Debug messages on Router A indicating that the packets generated by device
171.68.200.48 are getting translated by NAT. 

Router-A#
*Mar 28 03:34:28: IP: tableid=0, s=171.68.200.48 (Serial0), d=172.16.47.142 (Serial1), routed via RIB
*Mar 28 03:34:28: NAT: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [160]
*Mar 28 03:34:28: IP: s=172.16.47.150 (Serial0), d=172.16.47.142 (Serial1), g=172.16.47.145, len 100, forward
*Mar 28 03:34:28: ICMP type=8, code=0
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [160]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0), g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [161]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [161]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0),
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [162]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [162]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0),
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [163]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [163]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0),
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0
*Mar 28 03:34:28: NAT*: s=171.68.200.48->172.16.47.150, d=172.16.47.142 [164]
*Mar 28 03:34:28: NAT*: s=172.16.47.142, d=172.16.47.150->171.68.200.48 [164]
*Mar 28 03:34:28: IP: tableid=0, s=172.16.47.142 (Serial1), d=171.68.200.48
(Serial0), routed via RIB
*Mar 28 03:34:28: IP: s=172.16.47.142 (Serial1), d=171.68.200.48 (Serial0),
g=172.16.47.162, len 100, forward
*Mar 28 03:34:28: ICMP type=0, code=0

Router-A#undebug all
All possible debugging has been turned off

The above example shows that when a packet is traversing inside to outside, a NAT router checks its routing table for a route to the outside address before it continues to translate the packet. Therefore, it is important that the NAT router has a valid route for the outside network. The route to the destination network must be known through an interface that is defined as NAT outside in the router configuration.

It is important to note that the return packets are translated before they are routed. Therefore, the NAT router must also have a valid route for the Inside local address in its routing table.

你还想看

]]> http://www.zhangdaqian.net/blog/nat-order-of-operation.htm/feed 0 NAT/PAT中对于FTP的处理，以及PAT后的非标准21 FTP端口设置 http://www.zhangdaqian.net/blog/natpat%e4%b8%ad%e5%af%b9%e4%ba%8eftp%e7%9a%84%e5%a4%84%e7%90%86%ef%bc%8c%e4%bb%a5%e5%8f%8apat%e5%90%8e%e7%9a%84%e9%9d%9e%e6%a0%87%e5%87%8621-ftp%e7%ab%af%e5%8f%a3%e8%ae%be%e7%bd%ae.htm http://www.zhangdaqian.net/blog/natpat%e4%b8%ad%e5%af%b9%e4%ba%8eftp%e7%9a%84%e5%a4%84%e7%90%86%ef%bc%8c%e4%bb%a5%e5%8f%8apat%e5%90%8e%e7%9a%84%e9%9d%9e%e6%a0%87%e5%87%8621-ftp%e7%ab%af%e5%8f%a3%e8%ae%be%e7%bd%ae.htm#comments Sat, 19 Sep 2009 14:40:06 +0000 admin http://www.zhangdaqian.net/blog/natpat%e4%b8%ad%e5%af%b9%e4%ba%8eftp%e7%9a%84%e5%a4%84%e7%90%86%ef%bc%8c%e4%bb%a5%e5%8f%8apat%e5%90%8e%e7%9a%84%e9%9d%9e%e6%a0%87%e5%87%8621-ftp%e7%ab%af%e5%8f%a3%e8%ae%be%e7%bd%ae.htm
这里先要对FTP的两种模式说一下：

引用一张Cisco上面的图：
pix-asa-enable-ftp-2.gif

FTP分为两种模式： 主动Active 被动 Passive
主动模式下是使用21作为控制， 20作为数据口。
首先是客户端通过大于1023的端口发起到服务器21端口的控制连接，信息交换完成后。服务器从20端口发起连接到客户端提供的接收端口。
这是传统意义上的FTP行为。
被动模式是使用21作为控制，然后服务器自动选择一个大于1023的端口作为数据。
首先是客户端通过大于1023的端口发起到服务器21端口的控制连接，信息交换完成后。服务器告诉客户端一个大于1023的端口作为数据口，
然后客户端再以另外一个大于1023的端口发起连接到服务器提供的数据端口进行数据传输。
目前大多数服务器都支持这种模式，而且大部分客户端都默认采用被动模式和服务器进行传输。
好了，当我们在内网有两台服务器FTP SEVER1和FTP SERVER2都需要被外网访问的时侯，我们会分别为这两个服务器做映射出去。
假定FTP SERVE1(10.0.0.100)占用公网IP(x.x.x.x)的21端口，FTP SERVER2(10.0.0.200)占用公网IP(x.x.x.x)的2211端口。那么我们就会这么写：
ip nat inside source static tcp 10.0.0.100 21 x.x.x.x 21 extendable
ip nat inside source static tcp 10.0.0.200 21 x.x.x.x 2211 extendable
这样做了以后，我们会发现FTP SERVER1是正常的，而FTP SERVER2却不正常，表现为登录以后无法列出目录:
以下为FTP 客户端的LOG：
[xx:xx:03] PASV
[xx:xx:03] 227 Entering Passive Mode (10,0,0,200,6,32)
[xx:xx:24] Data Socket Error: Connection timed out
[xx:xx:24] List Complete: 0 bytes in 21.44 (1.00 KBps)
这是为什么呢？
答案就是在被动模式下，FTP SEVER告诉客户端的数据端口，无法被访问。为什么 FTP SERVER1又可以呢？
因为FTP SERVER1在对外映射的时侯采用了21端口，IOS会自动识别这个端口是FTP控制口，
从而去检查里面FTP数据控制数据发现服务器告诉客户端的这个用于传送数据的端口，然后自动的添加一条映射。
phanx# sh ip nat tr | in 10.0.0.100:
tcp x.x.x.x:21 10.0.0.100:21 y.y.y.y:1585 y.y.y.y:1585
tcp x.x.x.x:21 10.0.0.100:21 – -
tcp x.x.x.x:1812 10.0.0.20:1812 y.y.y.y:1594 y.y.y.y:1594
而FTP SERVER2映射的端口2211无法自动被识别成FTP端口，所以IOS不会自动的为它建立数据端口的映射。
解决的办法就是用 ip nat service 来指定这个端口。
access-list 10 permit 10.0.0.200
ip nat service 10 ftp tcp port 21
注意，这里的tcp port 21是指的 10.0.0.200的FTP端口21而不是 x.x.x.x的2211。如果FTP SERVER2用的FTP端口是其他的，那么就写对应的端口号。
这样做了以后，我们的FTP SERVER2就可以以 x.x.x.x:2211 的方式被公网访问了。
说道这里，问题已经解决了。但是，有人可能会提出来，既然FTP SERVER1用被动很正常，x.x.x.x:20端口并没有使用，
那为什么不用把FTP SERVER2主动模式来映射呢？比如这样做:
ip nat inside source static tcp 10.0.0.200 20 x.x.x.x 20 extendable
ip nat inside source static tcp 10.0.0.200 21 x.x.x.x 2211 extendable

OK. 这样做其实对于一部分情况是没有问题的。例如客户机的地址是公网地址，或者说能被FTP SERVER2所访问的地址。
但是如果客户机也是通过NAT/PAT上网的呢？假设客户端地址是192.168.1.111我们将看到这样的情况：
[00:14:10] PORT 192,168,1,111 ,6,179
[00:14:10] 200 PORT Command successful.
[00:14:10] REST 2028256
[00:14:10] 350 Restarting at 2028256. Send STORE or RETRIEVE.
[00:14:10] RETR fool.exe
[00:14:10] 150 Opening BINARY mode data connection for fool.exe (924668 Bytes).
[00:14:11] 425 Cannot open data connection.
[00:14:11] Transfer Failed!
因为是主动模式，是服务器主动送数据给客户机。那客户机通过控制信息就需要告诉服务器往哪里送，
但是FTP客户端并不知道自己的公网地址和端口，并且客户机也没有能力去自己的NAT/PAT网关上去开放一个端口让服务器来送数据。
所以它是以自己的实际地址去告诉服务器的。对于服务器而言，这个地址是无法被访问到的，所以这个办法也有行不通的地方。
当然，如果FTP客户端支持uPNP能识别到翻译后的公网地址，NAT/PAT网关也有uPNP的能力的话，主动模式的这个问题应该就能解决。
BTW：主动模式的FTP又被称为 “firewall UNfriendly”，什么原因？ 好好理解哦～
PIX/ASA上面的配置方法见：

你还想看

]]> http://www.zhangdaqian.net/blog/natpat%e4%b8%ad%e5%af%b9%e4%ba%8eftp%e7%9a%84%e5%a4%84%e7%90%86%ef%bc%8c%e4%bb%a5%e5%8f%8apat%e5%90%8e%e7%9a%84%e9%9d%9e%e6%a0%87%e5%87%8621-ftp%e7%ab%af%e5%8f%a3%e8%ae%be%e7%bd%ae.htm/feed 0 about ip address http://www.zhangdaqian.net/blog/about-ip-address.htm http://www.zhangdaqian.net/blog/about-ip-address.htm#comments Thu, 27 Aug 2009 09:27:58 +0000 admin http://www.zhangdaqian.net/blog/about-ip-address.htm http://www.rfc-editor.org/rfc/rfc3330.txt 
 Address Block             Present Use                       Reference
   ---------------------------------------------------------------------
   0.0.0.0/8            "This" Network                 [RFC1700, page 4]
   10.0.0.0/8           Private-Use Networks                   [RFC1918]
   14.0.0.0/8           Public-Data Networks         [RFC1700, page 181]
   24.0.0.0/8           Cable Television Networks                    --
   39.0.0.0/8           Reserved but subject
                           to allocation                       [RFC1797]
   127.0.0.0/8          Loopback                       [RFC1700, page 5]
   128.0.0.0/16         Reserved but subject
                           to allocation                             --
   169.254.0.0/16       Link Local                                   --
   172.16.0.0/12        Private-Use Networks                   [RFC1918]
   191.255.0.0/16       Reserved but subject
                           to allocation                             --
   192.0.0.0/24         Reserved but subject
                           to allocation                             --
   192.0.2.0/24         Test-Net
   192.88.99.0/24       6to4 Relay Anycast                     [RFC3068]
   192.168.0.0/16       Private-Use Networks                   [RFC1918]
   198.18.0.0/15        Network Interconnect
                           Device Benchmark Testing            [RFC2544]
   223.255.255.0/24     Reserved but subject
                           to allocation                             --
   224.0.0.0/4          Multicast                              [RFC3171]
   240.0.0.0/4          Reserved for Future Use        [RFC1700, page 4]

Random Posts

]]> http://www.zhangdaqian.net/blog/about-ip-address.htm/feed 1 Understanding SVI Autostate Exclude http://www.zhangdaqian.net/blog/understanding-svi-autostate-exclude.htm http://www.zhangdaqian.net/blog/understanding-svi-autostate-exclude.htm#comments Mon, 24 Aug 2009 15:28:00 +0000 admin http://www.zhangdaqian.net/blog/understanding-svi-autostate-exclude.htm To be “up/up,” a router VLAN interface must fulfill the following general conditions:

•The VLAN exists and is “active” on the VLAN database of the switch.

•The VLAN interface exists on the router and is not administratively down.

•At least one Layer 2 (access port or trunk) port exists, has a link “up” on this VLAN and is in spanning-tree forwarding state on the VLAN.

Random Posts

]]> http://www.zhangdaqian.net/blog/understanding-svi-autostate-exclude.htm/feed 0 DNS缓存投毒细节泄露 http://www.zhangdaqian.net/blog/dns%e7%bc%93%e5%ad%98%e6%8a%95%e6%af%92%e7%bb%86%e8%8a%82%e6%b3%84%e9%9c%b2.htm http://www.zhangdaqian.net/blog/dns%e7%bc%93%e5%ad%98%e6%8a%95%e6%af%92%e7%bb%86%e8%8a%82%e6%b3%84%e9%9c%b2.htm#comments Thu, 30 Apr 2009 13:36:56 +0000 admin http://www.zhangdaqian.net/blog/dns%e7%bc%93%e5%ad%98%e6%8a%95%e6%af%92%e7%bb%86%e8%8a%82%e6%b3%84%e9%9c%b2.htm 昨天Mantasano上的一篇文章描述了Dan Kaminsky的DNS域名服务器攻击的细节。该文章发表了几分钟之后即被删掉了。
虽然Dan Kaminsky已经联合厂商发布了补丁，但是仍处于补丁推送阶段，目前仍有相当一部分域名服务器还没有打补丁。如果被恶意利用的话，对整个互联网还是很有威胁的。这也是为什么Dan 希望 “not speculate publicly”。
大概看了一下那篇hypothesis，基本上还是利用了”Cache 投毒”（cache poisoning）的方法，不过使用了一些新的技巧。

DNS查询是如何进行的？对于绝大多数桌面系统来说，DNS的查询并不是由自己的机器完成的，DNS查询会提交给另一台DNS服务器（这台服务器通常是由 ISP或者公司提供），然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓存下来，从而提高查询效率并降低由 DNS带来的流量开销。
一台缓存DNS服务器（与权威DNS相对，这类系统提供的）下面的桌面系统可能有几百、几千、几万甚至几十万台桌面系统。
DNS缓存中毒攻击指的是更改了DNS服务器的DNS缓存中某项，这样缓存中与主机名相关的IP地址就不再指向正确的位置。例如，如果 www.example.com映射到IP地址192.168.0.1且DNS服务器的缓存中存在这个映射，则成功向这个服务器的DNS缓存投毒的攻击者就可以将www.example.com映射到10.0.0.1。在这种情况下，试图访问www.example.com的用户就可能与错误的Web服务器联络。
当攻击者试图请求查询某站点的域名时，DNS服务器首先会检查自己的DNS缓存中是否存在该域名，如果存在则将该域名所对应的IP地址返回给请求者，如果不存在则向上一级DNS或者权威DNS查询。这就会给攻击者带来一定的困难，如果是大一点的站点的话，攻击者发起DNS查询时，DNS服务器直接从缓存应答了，根本不会去请求权威域名服务器。怎么才能解决这个问题呢？云舒在他的DNS缓存中毒漏洞的一点推测中也提到过。
比如我们要攻击www.google.com.首先向目的DNS服务器查询根本不存在的二级域名，比如：aaa.google.com. DNS服务器在缓存中查找aaa.google.com,没有找到，则会向上级DNS或者权威DNS查询 。这时我们可以生成伪造的DNS Response数据包并发送这些的伪造DNS Response数据包给目的服务器。让目的DNS在上级DNS或者权威DNS服务器响应到达之前，接受到恶意的应答。
从表面上看这样只是截持了一个不存在的二级域名，只能用来钓钓鱼罢了。
其实DNS Response数据包可以不仅仅包含aaa.google.com的IP地址，还可以在DNS 数据包的Additional resource record中包含www.google.com的IP地址（当然该IP地址可以是伪造的）。当目的DNS收到该数据报时会将伪造的IP地址与 www.google.com关联起来并刷新到缓存上。这样就完成了主域名的截持。

Random Posts

]]> http://www.zhangdaqian.net/blog/dns%e7%bc%93%e5%ad%98%e6%8a%95%e6%af%92%e7%bb%86%e8%8a%82%e6%b3%84%e9%9c%b2.htm/feed 0 通过emule做DDOS是否可行？ http://www.zhangdaqian.net/blog/%e9%80%9a%e8%bf%87emule%e5%81%9addos%e6%98%af%e5%90%a6%e5%8f%af%e8%a1%8c%ef%bc%9f.htm http://www.zhangdaqian.net/blog/%e9%80%9a%e8%bf%87emule%e5%81%9addos%e6%98%af%e5%90%a6%e5%8f%af%e8%a1%8c%ef%bc%9f.htm#comments Thu, 30 Apr 2009 13:25:38 +0000 admin http://www.zhangdaqian.net/blog/%e9%80%9a%e8%bf%87emule%e5%81%9addos%e6%98%af%e5%90%a6%e5%8f%af%e8%a1%8c%ef%bc%9f.htm by 云舒

今天抽空看了下emule协议几个可能会出问题的地方，初步感觉是可能真的有问题。下了代码回来看了，不过代码太大，目前还没找到地方，没法对想法进行印证。我简单的说下，看哪位代码牛人能够在项目中找到对应的代码。

首先是在客户端连接到服务器之后，搜索文件时，服务器返回结果的报文。报文中返回的结果是一个集合，每个集合表示一条记录。但是每条记录中，并不包含拥有该文件的客户端的IP地址，而是返回的拥有该文件的客户端的ClientID和端口。这里我猜测ClientID的计算是可逆的，搜索发起者可以根据这个 ClientID计算出IP地址，然后连接，请求下载文件。具体报文结构如下：

名称 大小（字节） 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文和大小域的报文大小
类型 1 0×16 操作码 OP SEARCHRESULT 的值
结果数 4 N/A 此报文中包含的结果数目
结果列表 可变 N/A 一个结果的列表

搜索结果列表项格式：

名称 大小（字节） 默认值 注释
文件HASH 16 N/A 用于识别文件的 Hash 值
客户端 ID 4 N/A eMule服务器分配给客户端的ID
客户端端口 2 N/A 客户端的监听的TCP端口
标志数 4 N/A 其后的属性标志个数
标志列表 可变 N/A 标志列表

其次的第二个地方是下载文件的地方，客户端要求下载一个文件时，服务器会返回一个源查找结果报文。该报文也是只包含源的ClientID和端口，客户端应该是按照ClientID计算出IP地址，再去连接下载文件的。具体报文如下：

名称 大小（字节） 默认值 注释
协议类型 1 0xE3
大小 4 N/A 不包含报文头和大小域的报文大小
类型 1 0×42 操作码 OP FOUNDSOURCES 的值
文件HASH 16 N/A 相关文件的 Hash 值
源数量 1 N/A 拥有该文件的机器的数量
源列表 可变 N/A 源列表内容，每一条是一个可用源

每一条源的报文格式如下：

名称 大小（字节） 默认值 注释
客户端 ID 4 N/A 共享该文件的客户端的 ID
客户端端口 2 N/A 共享该文件的客户端端口

可以看到，搜索某个文件时，服务器返回的搜索列表中按照ClientID来区分不同的其它客户端。在开始下载一个文件时，服务器返回的可用源列表中，每个源也是以一个ClientID来表示的。也就是说，没一个ClientID就可以确定一个源，区分开彼此。而emule可以根据这个ClientID找到对应的客户端，去连接指定端口，请求文件。那么，现在的问题是这个ClientID是哪里来的？

原来这个ClientID在正常情况下，是我们连接到emule服务器时，服务器分配给我们的。但是注意到，在连接之后，我们可以像服务器提供我们所拥有的文件列表，报文格式如下：

名称 大小（字节） 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文和大小域的报文大小
类型 1 0×15 操作码 OP SEARCHRESULT 的值
文件数 4 N/A 共享列表中的文件数，这个数不超过 200
文件列表 可变 N/A 可选的文件列表,单个项的描述见下

单个文件条目描述我就不细写了，比较有用的字段是文件Hash码，ClientID，以及端口。这样看来，我们在连接到服务器之后，告诉它baidu的IP地址，TCP80端口，有赤壁下载，或者有XXX片下载，别人下载的时候，emule客户端会不会从服务器返回的可用源列表中，找到这条记录，并且去连接？

关键问题到了ClientID的计算，协议中这样描述的：假设 IP 地址为 X.Y.Z.W,则客户端 ID 按公式 X+28*Y+216*Z+24*W (Big Endian[6])计算。如果想法是正确的，那么我们可以先计算出百度的IP地址的ClientID，端口设置为80，然后通知服务器，这个 ClientID有高树的片子可以看……

你还想看

]]> http://www.zhangdaqian.net/blog/%e9%80%9a%e8%bf%87emule%e5%81%9addos%e6%98%af%e5%90%a6%e5%8f%af%e8%a1%8c%ef%bc%9f.htm/feed 0