BlogJava-地狱男爵之博客无限-随笔分类-系统综合

Android中文文档v0.1 beta低调发布,期待更多同学来参加review

地狱男爵(hellboys) — Wed, 05 Dec 2007 08:42:00 GMT

第一阶段:Android中文文档v0.1 beta发布--由www.androidcn.net社区提供

Android中文文档阅读地址: http://www.androidcn.net/wiki/index.php/Documentation

Android中文文档大部分已经完成. 但是可能有不少细节和不足之处需要完善和修补.

感谢翻译的同学,已经在文档里面加入. 如果缺少,请联系我

第二阶段:请有时间的同学进行review.

review阶段既然采用wiki上面形式. 希望review的同学可以联系AndroidCN管理员和各版版主.

相信review阶段对同学理解Android可以有更快的理解和提高. 阅读文档也是对Android理解之初步.

所有在阅读文档的时候,希望同学们不吝啬自己的一笔之力,对于未完全或翻译有误的地方进行涂抹.

相信大家可以先阅读文档,然后提出翻译中的不足进行.

review 讨论区： http://www.androidcn.net/thread-119-1-1.html

地狱男爵(hellboys) 2007-12-05 16:42 发表评论

欢迎访问Android中国

地狱男爵(hellboys) — Thu, 15 Nov 2007 09:24:00 GMT

摘要: 欢迎访问Android中国, Android是google为手机开发的操作系统, 基于Linux2.6内核. 移动终端开发和使用是一个非常有趣,有挑战的活动.于是, 我们一些志同道合的朋友成立了Android中国, 致力于docs的中文化, 当然还有交流何使用经验, 共同开发Android项目. 欢迎您的光临和加入.

主页：http://www.androidcn.net 阅读全文

地狱男爵(hellboys) 2007-11-15 17:24 发表评论

一台主机被多台电脑监控 (keyword:cacti,snmp,snmpd.conf)

地狱男爵(hellboys) — Wed, 07 Mar 2007 02:27:00 GMT

SNMPD.CONF(5)                                       SNMPD.CONF(5)

NAME
       share/snmp/snmpd.conf - configuration file for the ucd-
       snmp SNMP agent.

DESCRIPTION
       snmpd.conf is the configuration file which defines how the
       ucd-smnp SNMP agent operates. These files may contain any
       of the directives found in the DIRECTIVES section below.
       This file is not required for the agent to operate and
       report mib entries.

PLEASE READ FIRST
       First, make sure you have read the snmp_config(5) manual
       page that describes how the ucd-snmp configuration files
       operate, where they are located and how they all work
       together.

EXTENSIBLE-MIB
       The ucd-snmp SNMP agent reports much of its information
       through queries to the 1.3.6.1.4.1.2021 section of the mib
       tree.   Every mib in this section has the following table
       entries in it.

       .1 -- index
              This is the table's index numbers for each of the
              DIRECTIVES listed below.

       .2 -- name
              The name of the given table entry. This should be
              unique, but is not required to be.

       .100 -- errorFlag
              This is a flag returning either the integer value 1
              or 0 if an error is detected for this table entry.

       .101 -- errorMsg
              This is a DISPLAY-STRING describing any error trig-
              gering the errorFlag above.

       .102 -- errorFix
              If this entry is SNMPset to the integer value of 1
              AND the errorFlag defined above is indeed a 1, a
              program or script will get executed with the table
              entry name from above as the argument. The program
              to be executed is configured in the config.h file
              at compile time.

   Directives
       proc NAME

       proc NAME MAX

       proc NAME MAX MIN

              Checks to see if the NAME'd processes are running
              on the agent's machine. An error flag (1) and a
              description message are then   passed   to   the
              1.3.6.1.4.1.2021.2.100 and 1.3.6.1.4.1.2021.2.101
              mib tables (respectively) if the NAME'd program is
              not found in the process table as reported by
              "/bin/ps -e".

              If MAX and MIN are not specified, MAX is assumed to
              be infinity and MIN is assumed to be 1.

              If MAX is specified but MIN is not specified, MIN
              is assumed to be 0.

       procfix NAME PROG ARGS
              This registers a command that knows how to fix
              errors   with   the   given   process NAME.   When
              1.3.6.1.4.1.2021.2.102 for a given NAMEd program is
              set to the integer value of 1, this command will be
              called. It defaults to a compiled value set using
              the PROCFIXCMD definition in the config.h file.

       exec NAME PROG ARGS

       exec MIBNUM NAME PROG ARGS

              If MIBNUM is not specified, the agent executes the
              named PROG with arguments of ARGS and returns the
              exit status and the first line of the STDOUT output
              of   the   PROG   program   to   queries   of   the
              1.3.6.1.4.1.2021.8.100 and 1.3.6.1.4.1.2021.8.101
              mib tables (respectively).   All STDOUT   output
              beyond the first line is silently truncated.

              If MIBNUM is specified, it acts as above but
              returns the exit status to MIBNUM.100.0 and the
              entire STDOUT output to the table MIBNUM.101 in a
              mib table. In this case, the MIBNUM.101 mib con-
              tains the entire STDOUT output, one mib table entry
              per line of output (ie, the first line is output as
              MIBNUM.101.1, the second at MIBNUM.101.2, etc...).

              Note: The MIBNUM must be specified in dotted-inte-
                     ger notation and can not be specified as
                     ".iso.org.dod.internet..." (should instead
                     be

              Note: The agent caches the exit status and STDOUT
                     of the executed program for 30 seconds after
                     the initial query.   This is to increase
                     speed and maintain consistency of informa-
                     tion for consecutive table queries. The
                     cache can be flushed by a snmp-set request
                     of integer(1) to 1.3.6.1.4.1.2021.100.VER-
                     CLEARCACHE.

       execfix NAME PROG ARGS
              This registers a command that knows how to fix
              errors with the given exec or sh NAME. When
              1.3.6.1.4.1.2021.8.102 for a given NAMEd entry is
              set to the integer value of 1, this command will be
              called. It defaults to a compiled value set using
              the EXECFIXCMD definition in the config.h file.

       disk PATH

       disk PATH [ MINSPACE | MINPERCENT% ]

              Checks the named disks mounted at PATH for avail-
              able disk space. If the disk space is less than
              MINSPACE (kB) if specified or less than MINPERCENT
              (%) if a % sign is specified, or DEFDISKMINI-
              MUMSPACE (kB) if not specified, the associated
              entry in the 1.3.6.1.4.1.2021.9.100 mib table will
              be set to (1) and a descriptive error message will
              be returned to queries of 1.3.6.1.4.1.2021.9.101.

       load MAX1

       load MAX1 MAX5

       load MAX1 MAX5 MAX15

              Checks the load average of the machine and returns
              an error flag (1), and an text-string error message
              to   queries   of    1.3.6.1.4.1.2021.10.100    and
              1.3.6.1.4.1.2021.10.101   (respectively) when the
              1-minute, 5-minute, or 15-minute averages exceed
              the associated maximum values. If any of the MAX1,
              MAX5, or MAX15 values are unspecified, they default
              to a value of DEFMAXLOADAVE.

       file FILE [MAXSIZE]
              Monitors file sizes and makes sure they don't grow
              beyond a certain size. MAXSIZE defaults to infi-
              nite if not specified, and only monitors the size
              without reporting errors about it.

   Errors
       Any errors in obtaining the above information are reported
       via    the    1.3.6.1.4.1.2021.101.100    flag   and   the
       1.3.6.1.4.1.2021.101.101 text-string description.

SMUX SUB-AGENTS
       To enable and SMUX based sub-agent, such as gated, use the
       smuxpeer configuration entry

       smuxpeer OID PASS
              For gated a sensible entry might be

       .1.3.6.1.4.1.4.1.3 secret

ACCESS CONTROL
       snmpd supports the View-Based Access Control Model (vacm)
       as defined in RFC 2275. To this end, it recognizes the
       following keywords in the configuration file: com2sec,
       group, access, and view as well as some easier-to-use
       wrapper   directives: rocommunity, rwcommunity, rouser,
       rwuser.

       rocommunity COMMUNITY [SOURCE] [OID]

       rwcommunity COMMUNITY [SOURCE] [OID]
              These create read-only and read-write communities
              that can be used to access the agent. They are a
              quick method of using the following com2sec, group,
              access, and view directive lines. They are not as
              efficient either, as groups aren't created so the
              tables are possibly larger. In other words: don't
              use these if you have complex situations to set up.

              The format of the SOURCE is token is described in
              the com2sec directive section below. The OID token
              restricts access for that community to everything
              below that given OID.

       rouser USER [noauth|auth|priv] [OID]

       rwuser USER [noauth|auth|priv] [OID]
              Creates a SNMPv3 USM user in the VACM access
              configuration tables.   Again, its more efficient
              (and powerful) to use the combined com2sec, group,
              access, and view directives instead.

              The minimum level of authentication and privacy the
              user must use is specified by the first token
              (which defaults to "auth").   The OID parameter
              restricts access for that user to everything below
              the given OID.

       com2sec NAME SOURCE COMMUNITY
              This   directive   specifies the mapping from a
              source/community pair to a security name. SOURCE
              can be a hostname, a subnet, or the word "default".
              A subnet can be specified as IP/MASK or IP/BITS.
              The first source/community combination that matches
              the incoming packet is selected.

       group NAME MODEL SECURITY
              This directive defines the mapping from security-
              model/securityname to group. MODEL is one of v1,
              v2c, or usm.

       access NAME CONTEXT MODEL LEVEL PREFX READ WRITE NOTIFY
              The access directive maps from   group/security
              model/security level to a view. MODEL is one of
              any, v1, v2c, or usm.   LEVEL is one of noauth,
              auth, or priv. PREFX specifies how CONTEXT should
              be matched against the context of the incoming pdu,
              either exact or prefix.   READ, WRITE and NOTIFY
              specifies the view to be used for the corresponding
              access.   For v1 or v2c access, LEVEL will be
              noauth, and CONTEXT will be empty.

       view NAME TYPE SUBTREE [MASK]
              The defines the named view. TYPE is either included
              or excluded.   MASK is a list of hex octets, sepa-
              rated by '.' or ':'. The MASK defaults to "ff" if
              not specified.

              The reason for the mask is, that it allows you to
              control access to one row in a table, in a rela-
              tively simple way. As an example, as an ISP you
              might consider giving each customer access to his
              or her own interface:

              view cust1 included interfaces.ifTable.ifEntry.ifIndex.1 ff.a0
              view cust2 included interfaces.ifTable.ifEntry.ifIndex.2 ff.a0

              (interfaces.ifTable.ifEntry.ifIndex.1 == .1.3.6.1.2.1.2.2.1.1.1,
              ff.a0 == 11111111.10100000. which nicely covers up and including
              the row index, but lets the user vary the field of the row)

       VACM Examples:
              #       sec.name source          community
              com2sec local     localhost       private
              com2sec mynet     10.10.10.0/24   public
              com2sec public    default         public

              #             sec.model sec.name
              group mygroup v1         mynet
              group mygroup v2c        mynet
              group mygroup usm        mynet
              group local   v1         local
              group local   v2c        local
              group local   usm        local
              group public v1         public
              group public v2c        public
              group public usm        public

              #           incl/excl subtree                          mask
              view all    included .1                               80
              view system included system                           fe
              view mib2   included .iso.org.dod.internet.mgmt.mib-2 fc

              #              context sec.model sec.level prefix read   write notify
              access mygroup ""      any       noauth    exact mib2   none none
              access public ""      any       noauth    exact system none none
              access local   ""      any       noauth    exact all    all   all

       Default VACM model
              The default configuration of the agent, as shipped, is functionally
              equivalent to the following entries:
              com2sec   public    default   public
              group     public    v1   public
              group     public    v2c public
              group     public    usm public
              view      all included .1
              access    public    ""   any noauth    exact     all none none

SNMPv3 CONFIGURATION
       engineID STRING
              The snmpd agent needs to be configured with an
              engineID to be able to respond to SNMPv3 messages.
              With this configuration file line, the engineID
              will be configured from STRING. The default value
              of the engineID is configured with the first IP
              address found for the hostname of the machine.

       createUser username (MD5|SHA) authpassphrase [DES] [priv-
       passphrase]
              This directive should be placed into the "/var/ucd-
              snmp"/snmpd.conf file instead of the other normal
              locations. The reason is that the information is
              read from the file and then the line is removed
              (eliminating the storage of the master password for
              that user) and replaced with the key that is
              derived from it. This key is a localized key, so
              that if it is stolen it can not be used to access
              other agents. If the password is stolen, however,
              it can be.

              MD5 and SHA are the authentication types to use,
              but you must have built the package with openssl
              installed in order to use SHA. The only privacy
              protocol currently supported is DES. If the pri-
              vacy passphrase is not specified, it is assumed to
              be the same as the authentication passphrase. Note
              that the users created will be useless unless they
              are also added to the VACM access control tables
              described above.

              Warning: the minimum pass phrase length is 8 char-
              acters.

              SNMPv3 users can be created at runtime using the
              snmpusm command.

SETTING SYSTEM INFORMATION
       syslocation STRING

       syscontact STRING

              Sets the system location and the system contact for
              the agent. This information is reported by the
              'system' table in the mibII tree.

       authtrapenable NUMBER
              Setting authtrapenable to 1 enables generation of
              authentication failure traps. The default value is
              2 (disable).

       trapcommunity STRING
              This defines the default community string to be
              used when sending traps. Note that this command
              must be used prior to any of the following three
              commands that are intended use this community
              string.

       trapsink HOST [COMMUNITY [PORT]]

       trap2sink HOST [COMMUNITY [PORT]]

       informsink HOST [COMMUNITY [PORT]]
              These commands define the hosts to receive traps
              (and/or inform notifications). The daemon sends a
              Cold Start trap when it starts up. If enabled, it
              also sends traps on authentication failures.   Mul-
              tiple trapsink, trap2sink and informsink lines may
              be specified to specify multiple destinations. Use
              trap2sink to send SNMPv2 traps and informsink to
              send inform notifications.   If COMMUNITY is not
              specified, the string from a preceding trapcommu-
              nity directive will be used. If PORT is not speci-
              fied, the well known SNMP trap port (162) will be
              used.

PASS-THROUGH CONTROL
       pass MIBOID EXEC
              Passes entire control of MIBOID to the EXEC pro-
              gram.   The EXEC program is called in one of the
              following three ways:

              EXEC -g MIBOID

              EXEC -n MIBOID

                     These call lines match to SNMP get and get-
                     next requests. It is expected that the EXEC
                     program will take the arguments passed to it
                     and return the appropriate response through
                     it's stdout.

                     The first line of stdout should be the mib
                     OID of the returning value. The second line
                     should be the TYPE of value returned, where
                     TYPE is one of the text strings: string,
                     integer, unsigned,   objectid,   timeticks,
                     ipaddress, counter, or gauge.   The third
                     line of stdout should be the VALUE corre-
                     sponding with the returned TYPE.

                     For instance, if a script was to return the
                     value integer value "42" when a request for
                     .1.3.6.1.4.100 was requested, the script
                     should return the following 3 lines:
                       .1.3.6.1.4.100
                       integer
                       42

                     To indicate that the script is unable to
                     comply with the request due to an end-of-mib
                     condition or an invalid request, simple exit
                     and return no output to stdout at all. A
                     snmp error will be generated corresponding
                     to the SNMP NO-SUCH-NAME response.

              EXEC -s MIBOID TYPE VALUE

                     For SNMP set requests, the above call method
                     is used. The TYPE passed to the EXEC pro-
                     gram is one of the text strings: integer,
                     counter, gauge, timeticks, ipaddress, objid,
                     or string, indicating the type of value
                     passed in the next argument.

                     Return nothing to stdout, and the set will
                     assumed to have been successful. Otherwise,
                     return one of the following error strings to
                     signal an error: not-writable, or wrong-type
                     and the appropriate error response will be
                     generated instead.

                      Note: By   default,   the only community
                             allowed to write (ie snmpset) to
                             your script will be the "private"
                             community,or community #2 if defined
                             differently by the "community" token
                             discussed above. Which communities
                             are allowed write access are con-
                             trolled by the RWRITE definition in
                             the snmplib/snmp_impl.h source file.

EXAMPLE
       See the EXAMPLE.CONF file in the top level source direc-
       tory for a more detailed example of how the above informa-
       tion is used in real examples.

RE-READING snmpd.conf and snmpd.local.conf
       The ucd-snmp agent can be forced to re-read its configura-
       tion files. It can be told to do so by one of two ways:

       1.     An       snmpset       of       integer(1)       to
              1.3.6.1.4.1.2021.100.VERUPDATECONFIG.

       2.     A "kill -HUP" signal sent to the snmpd agent pro-
              cess.

FILES
       share/snmp/snmpd.conf

SEE ALSO
       snmp_config(5), snmpd(1), EXAMPLE.conf, read_config(3).

                           27 Jan 2000              SNMPD.CONF(5)

地狱男爵(hellboys) 2007-03-07 10:27 发表评论

妙解网络多台dhcp引起的IP冲突

地狱男爵(hellboys) — Wed, 15 Nov 2006 02:22:00 GMT

客人在我所供职的酒店上网的时候，经常会弹出一个对话框，显示一些提示，如上网的注意事项和消费标准等信息;并且有自己的电影和歌曲服务器，DHCP-server也是其中的一台服务器，宾馆、酒店就是用这台机器，为客户分配IP地址提供上网功能，即客户把自己的计算机连上网线，网卡配置自动获取IP地址，就会从动态主机配置协议(DHCP)服务器分配到一个IP地址;采用DHCP server可以自动为用户设置网络IP地址、掩码、网关、DNS、Wins 等网络参数，简化了用户网络设置，提高了管理效率。

　　那么我们的问题也出现了:常见的，很多用户抱怨用这种方法上不了网，但不是所有客户都上不了网。经过调查发现，住宾馆、酒店的人绝大多数是商务人员和工程师，他们携带的手提电脑一般安装的是Windows server版本，server版本默认启动了DHCP server功能，当一台这样的计算机连入网络，在他之后的计算机就会把他当成DHCP服务器，并被分配了不正确的IP地址，从而上不了网。

　　DHCP服务器地址分配方式

　　DHCP是一种用于简化主机IP配置管理的协议标准。通过采用DHCP标准，可以使用DHCP服务器为网络上所有启用了DHCP的客户端分配、配置、跟踪和更改(必要时)所有TCP/IP设置。此外，DHCP还可以确保不使用重复地址、重新分配未使用的地址，并且可以自动为主机连接的子网分配适当的IP地址。当一个网络中，有2个或2个以上的DHCP服务器时，提醒切勿将DHCP地址池定义的过大，以免多个地址池之间出现“包含于”的关系，或者是部分客户端手工指定的IP地址包含于DHCP服务器的地址池中，从而造成DHCP的一些异常故障。

　　针对不同的需求，DHCP服务器有三种机制分配IP地址:

　　自动分配 DHCP服务器给首次连接到网络的某些客户端分配固定IP地址，该地址由用户长期使用;

　　动态分配 DHCP服务器给客户端分配有时间限制的IP地址，使用期限到期后，客户端需要重新申请地址，客户端也可以主动释放该地址。绝大多数客户端主机得到的是这种动态分配的地址;

　　手动分配由网络管理员为客户端指定固定的IP地址。

　　三种地址分配方式中，只有动态分配可以重复使用客户端不再需要的地址。

　　每项技术都是有利有弊的，DHCP也不例外，由于DHCP有着配置简单，管理方便的优点，问题也随之产生，由于DHCP的运作机制，通常服务器和客户端没有认证机制，如果网络上存在多台DHCP服务器将会给网络造成混乱。由于用户不小心配置了DHCP服务器引起的网络混乱非常常见，足可见此问题的普遍性。

　　本人在从事网络工作的几年里，遇到过很多问题，其中有关DHCP-server冲突的不在少数，在解决问题的同时也总结了一些经验，在这里简单介绍一下，与大家分享，希望给在解决此类问题的同行一些帮助，也希望广大高手指出其中的不足和需要改进的地方。

DHCP服务器冲突的解决方法

　　使用DHCP snooping技术来解决

　　针对这种DHCP服务器冲突的解决方法有很多，最直接的方法就是贴告示，让入住的客户在上网时关闭Windows的DHCP网络服务，这个选项在‘控制面板’，‘管理工具’里的‘DHCP网络服务’，进入关闭即可。这里要注意的是，非server版的Windows不用关闭，并且不要把‘控制面板’，‘管理工具’，‘服务’中的DHCP client给停止了，这样是分配不到地址的。

　　当然上面的方法比较被动也不合常理，更不便于我们网络的管理，所以还是应该从我们网络本身出发来解决问题。

　　既然是DHCP的问题，那么我们就用DHCP的技术来解决问题，比较有代表的就是DHCP snooping技术。DHCP snooping技术是DHCP安全特性，通过建立和维护DHCP snooping绑定表过滤不可信任的DHCP信息，这些信息是指来自不信任区域的DHCP信息。DHCP snooping绑定表包含不信任区域的用户mac地址、IP地址、租用期、vlan-id接口等信息。

　　首先定义交换机上的信任端口和不信任端口，其中信任端口连接DHCP服务器或其他交换机的端口;不信任端口连接用户或网络。不信任端口将接收到的DHCP服务器响应的DHCP ack 和DHCP off报文丢弃;而信任端口将此配置中的命令都是以CISCO的设备为基础，但不管是哪个公司的设备，总体设计思想是一致的，不同的可能在命令格式上略有差异，工作人员应该根据具体的实际情况来解决相应的问题。

　　在全局模式下启动DHCP snooping功能，这个默认是关闭的，而且不是所有设备都支持这个功能，最好先看使用说明。

　　switch(config)#ip dhcp-snooping

　　如果有vlan就使用下面的命令来监测具体的vlan

　　switch(config)#ip dhcp-snooping vlan vlan-id

　　然后定义可信任的端口，默认情况交换机的端口均为不信任端口，通常网络设备接口， TRUNK 接口和连接DHCP服务器的端口定义为可信任端口。

　　switch(config)#int f0/x

　　switch(config-if)#ip dhcp snooping trust

使用PVLAN技术来解决

　　有很多二层的技术可以防止DHCP-server冲突的，PVLAN就是其中一个运用比较广的技术。

　　PVLAN私有局域网(private vlan)，在PVLAN的概念里，端口有3种类型:Isolated port，Community port, Promiscuous port;它们分别对应不同的vlan类型:Isolated port属于Isolated PVLAN，Community port属于Community PVLAN，而代表一个Private vlan整体的是Primary vlan，前面两类vlan需要和它绑定在一起，同时它还包括Promiscuous port。在Isolated PVLAN中，Isolated port只能和Promiscuous port，彼此之间不能访问;在Community PVLAN中，vlan与vlan之间都不能访问，同一Community vlan的接口可以互相访问，并且所有Community vlan的接口都可以与Promiscuous port进行通信。利用这项技术，我们可以把上连或连接DHCP服务器的接口定义为Promiscuous port，其他接口分配到Isolated vlan里，这样所有接口都只能与上连或DHCP服务器进行通信，即使有一台机器设为DHCP服务器，其他机器也不会与它产生流量，把它做为服务器。

　　利用这个技术解决DHCP-server冲突的方法有很多，也很灵活，下面介绍一种比较简单的方法，也是用的比较多的:

　　首先把交换机配置成transparents模式:　　

　　switch(config)#vtp mode transparent

　　顺便可以打开端口的保护功能，它的意思是打开端口保护的端口之间不能访问，但打开保护的端口可以与没有开启此项功能的端口通信，可以根据自己的需求来打开保护功能:

　　switch(config)#int range f0/124

　　switch(config-if-range)#switchitchport protected

　　建立isolated vlan和primary vlan，把isolated vlan定义为primary lan的附属vlan，因为要与primary互相访问:

　　switch(config)#vlan 14

　　switch(config-vlan)private-vlan isolated

　　switch(config)#vlan 44

　　switch(config-vlan)#private-vlan primary

　　switch(config-vlan)#private-vlan association 14

地狱男爵(hellboys) 2006-11-15 10:22 发表评论

P2P之UDP穿透NAT的原理与实现

地狱男爵(hellboys) — Tue, 12 Sep 2006 16:32:00 GMT

P2P之UDP穿透NAT的原理与实现 - 增强篇(附修改过的源代码)

------------------------------------------------------------------------------------------------------------

NAT(The IP Network Address Translator) 的概念和意义是什么?

NAT, 中文翻译为网络地址转换。具体的详细信息可以访问RFC 1631 - http://www.faqs.org/rfcs/rfc1631.html, 这是对于NAT的定义和解释的最权威的描述。网络术语都是很抽象和艰涩的，除非是专业人士，否则很难从字面中来准确理解NAT的含义。

要想完全明白NAT 的作用，我们必须理解IP地址的两大分类，一类是私有IP地址，在这里我们称作内网IP地址。一类是非私有的IP地址，在这里我们称作公网IP地址。关于IP地址的概念和作用的介绍参见我的另一篇文章: http://hwycheng.blogchina.com/2402121.html

内网IP地址: 是指使用A/B/C类中的私有地址, 分配的IP地址在全球不惧有唯一性，也因此无法被其它外网主机直接访问。
公网IP地址: 是指具有全球唯一的IP地址，能够直接被其它主机访问的。

NAT 最初的目的是为使用内网IP地址的计算机提供通过少数几台具有公网的IP地址的计算机访问外部网络的功能。NAT 负责将某些内网IP地址的计算机向外部网络发出的IP数据包的源IP地址转换为NAT自己的公网的IP地址，目的IP地址不变, 并将IP数据包转发给路由器，最终到达外部的计算机。同时负责将外部的计算机返回的IP数据包的目的IP地址转换为内网的IP地址，源IP地址不变，并最终送达到内网中的计算机。

        ----------------------                           ----------------------
        | 192.168.0.5        | Internat host            | 192.168.0.6        | Internat host
        ----------------------                           ----------------------
                ^ port:2809                                      ^port: 1827
                |                                                |
                V                                                V
        ----------------------                           ----------------------
        | 192.168.0.1        | NAT device                | 192.168.0.2        | NAT device
        | 61.51.99.86        |                           | 61.51.77.66        |
        ----------------------                           ----------------------
                ^                                                ^
                |                                                |
                V port:80                                        V port: 80
        ----------------------                           ----------------------
        | 61.51.202.88       | Internet host             | 61.51.76.102       | Internet host
        ----------------------                           ----------------------

                              图一: NAT 实现了私有IP的计算机分享几个公网IP地址访问Internet的功能。

随着网络的普及，IPv4的局限性暴露出来。公网IP地址成为一种稀缺的资源，此时NAT 的功能局限也暴露出来，同一个公网的IP地址，某个时间只能由一台私有IP地址的计算机使用。于是NAPT(The IP Network Address/Port Translator)应运而生，NAPT实现了多台私有IP地址的计算机可以同时通过一个公网IP地址来访问Internet的功能。这在很大程度上暂时缓解了IPv4地址资源的紧张。

NAPT 负责将某些内网IP地址的计算机向外部网络发出的TCP/UDP数据包的源IP地址转换为NAPT自己的公网的IP地址，源端口转为NAPT自己的一个端口。目的IP地址和端口不变, 并将IP数据包发给路由器，最终到达外部的计算机。同时负责将外部的计算机返回的IP数据包的目的IP地址转换内网的IP地址，目的端口转为内网计算机的端口，源IP地址和源端口不变，并最终送达到内网中的计算机。

                ----------------------                           ----------------------
                | 192.168.0.5        | Internat host            | 192.168.0.6        | Internat host
                ----------------------                           ----------------------
                        port: 2809      ^                   ^ port: 1827
                                         \                 /
                                          v               v
                                        ----------------------
                                        | 192.168.0.1        | NAT device
                                        | 61.51.99.86        |
                                        ----------------------
        map port:9882 to 192.168.0.5:2809 ^              ^ map port: 9881 to 192.168.0.6:1827
                                         /                \
                             port:80    v                  v    port:80
                ----------------------                           ----------------------
                | 61.51.202.88       | Internet host             | 61.51.76.102       | Internet host
                ----------------------                           ----------------------

                              图二: NAPT 实现了私有IP的计算机分享一个公网IP地址访问Internet的功能。

在我们的工作和生活中, NAPT的作用随处可见，绝大部分公司的网络架构，都是通过1至N台支持NAPT的路由器来实现公司的所有计算机连接外部的Internet网络的。包括本人在写这篇文章的时候，也是在家中使用一台IBM笔记本通过一台宽带连接的台式机来访问Internet的。我们本篇文章主要讨论的NAPT的问题。

NAPT(The IP Network Address/Port Translator) 为何阻碍了P2P软件的应用?

通过NAPT 上网的特点决定了只能由NAPT内的计算机主动向NAPT外部的主机发起连接，外部的主机想直接和NAPT内的计算机直接建立连接是不被允许的。IM(即时通讯)而言，这意味着由于NAPT内的计算机和NAPT外的计算机只能通过服务器中转数据来进行通讯。对于P2P方式的下载程序而言，意味着NAPT内的计算机不能接收到NAPT外部的连接，导致连接数用过少，下载速度很难上去。因此P2P软件必须要解决的一个问题就是要能够在一定的程度上解决NAPT 内的计算机不能被外部连接的问题。

NAT(The IP Network Address Translator) 进行UDP穿透的原理是什么?

TCP/IP 传输时主要用到TCP和UDP协议。TCP协议是可靠的，面向连接的传输协议。UDP是不可靠的，无连接的协议。根据TCP和UDP协议的实现原理，对于 NAPT来进行穿透，主要是指的UDP协议。TCP协议也有可能，但是可行性非常小，要求更高，我们此处不作讨论，如果感兴趣可以到Google上搜索，有些文章对这个问题做了探讨性的描述。下面我们来看看利用UDP协议来穿透NAPT的原理是什么:

                        ----------------------                           ----------------------
                        | 192.168.0.5        | Internat host            | 192.168.0.6        | Internat host
                        ----------------------                           ----------------------
                          UDP port: 2809        ^                   ^ UDP port: 1827
                                                 \                 /
                                                  v               v
                                                ----------------------
                                                | 192.168.0.1        | NAT device
                                                | 61.51.99.86        |
                                                ----------------------
Session(192.168.0.6:1827 <-> 61.51.76.102:8098) ^              ^ Session(192.168.0.6:1827 <-> 61.51.76.102:8098)
               map port:9882 to 192.168.0.5:2809 /                \map port: 9881 to 192.168.0.6:1827
                                  UDP port:8098 v                  v    UDP port:8098
                        ----------------------                           ----------------------
                        | 61.51.202.88       | Internet host             | 61.51.76.102       | Internet host
                        ----------------------                           ----------------------


                                      图三: NAPT 是如何将私有IP地址的UDP数据包与公网主机进行透明传输的。

UDP协议包经NAPT透明传输的说明:

NAPT 为每一个Session分配一个NAPT自己的端口号，依据此端口号来判断将收到的公网IP主机返回的TCP/IP数据包转发给那台内网IP地址的计算机。在这里Session是虚拟的，UDP通讯并不需要建立连接，但是对于NAPT而言，的确要有一个Session的概念存在。NAPT对于UDP协议包的透明传输面临的一个重要的问题就是如何处理这个虚拟的Session。我们都知道TCP连接的Session以SYN包开始，以FIN包结束， NAPT可以很容易的获取到TCP Session的生命周期，并进行处理。但是对于UDP而言，就麻烦了，NAPT并不知道转发出去的UDP协议包是否到达了目的主机，也没有办法知道。而且鉴于UDP协议的特点，可靠很差，因此NAPT必须强制维持Session的存在，以便等待将外部送回来的数据并转发给曾经发起请求的内网IP地址的计算机。NAPT具体如何处理UDP Session的超时呢？不同的厂商提供的设备对于NAPT的实现不近相同，也许几分钟，也许几个小时，些NAPT的实现还会根据设备的忙碌状态进行智能计算超时时间的长短。

                  [192.168.0.6:1827]
                            | UDP Packet[src ip:192.168.0.6 src port:1827 dst ip:61.51.76.102 dst port 8098]
                            v
        [pub ip: 61.51.99.86]NAT[priv ip: 192.168.0.1]
                            | UDP Packet[src ip:61.51.99.86 src port:9881 dst ip:61.51.76.102 dst port 8098]
                            v
                  [61.51.76.102:8098]

                                    图四: NAPT 将内部发出的UDP协议包的源地址和源端口改变传输给公网IP主机。


                  [192.168.0.6:1827]
                            ^
                            | UDP Packet[src ip:61.51.76.102 src port:8098 dst ip:192.168.0.6 dst port 1827]
        [pub ip: 61.51.99.86]NAT[priv ip: 192.168.0.1]
                            ^
                            | UDP Packet[src ip:61.51.76.102 src port:8098 dst ip:61.51.99.86 dst port 9881]
                  [61.51.76.102:8098]

                                    图五: NAPT 将收到的公网IP主机返回的UDP协议包的目的地址和目的端口改变传输给内网IP计算机。
现在我们大概明白了NAPT如何实现内网计算机和外网主机间的透明通讯。现在来看一下我们最关心的问题，就是NAPT是依据什么策略来判断是否要为一个请求发出的UDP数据包建立Session的呢？主要有一下几个策略:

A. 源地址(内网IP地址)不同，忽略其它因素, 在NAPT上肯定对应不同的Session
B. 源地址(内网IP地址)相同，源端口不同，忽略其它的因素，则在NAPT上也肯定对应不同的Session
C. 源地址(内网IP地址)相同，源端口相同，目的地址(公网IP地址)相同，目的端口不同，则在NAPT上肯定对应同一个Session
D. 源地址(内网IP地址)相同，源端口相同，目的地址(公网IP地址)不同，忽略目的端口，则在NAPT上是如何处理Session的呢？

D的情况正式我们关心和要讨论的问题。依据目的地址(公网IP地址)对于Session的建立的决定方式我们将NAPT设备划分为两大类:

Symmetric NAPT:
对于到同一个IP地址，任意端口的连接分配使用同一个Session; 对于到不同的IP地址, 任意端口的连接使用不同的Session.
我们称此种NAPT为 Symmetric NAPT. 也就是只要本地绑定的UDP端口相同，发出的目的IP地址不同，则会建立不同的Session.

        [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696]
                ^               ^                       ^
                |               |                       |
                v               v                       v
               9883            9882                    9881
                                 |
                             \ [NAT] /
                                 ^
                                 |
                                 v
                          [192.168.0.6:1827]

                          图六: Symmetric 的英文意思是对称。多个端口对应多个主机，平行的，对称的!

Cone NAPT:
对于到同一个IP地址，任意端口的连接分配使用同一个Session; 对于到不同的IP地址，任意端口的连接也使用同一个Session.
我们称此种NAPT为 Cone NAPT. 也就是只要本地绑定的UDP端口相同，发出的目的地址不管是否相同，都使用同一个Session.

[202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696]

                        ^          ^         ^
                         \         |        /
                          v        v       v
                                 9881
                                 [NAT]
                                   ^
                                   |
                                   v
                          [192.168.0.6:1827]

                          图七: Cone 的英文意思是锥。一个端口对应多个主机，是不是像个锥子?

现在绝大多数的NAPT属于后者，即Cone NAT。本人在测试的过程中，只好使用了一台日本的Symmetric NAT。还好不是自己的买的，我从不买日货, 希望看这篇文章的朋友也自觉的不要购买日本的东西。Win9x/2K/XP/2003系统自带的NAPT也是属于 Cone NAT的。这是值的庆幸的，因为我们要做的UDP穿透只能在Cone NAT间进行，只要有一台不是Cone NAT，对不起，UDP穿透没有希望了，服务器转发吧。后面会做详细分析!

下面我们再来分析一下NAPT 工作时的一些数据结构，在这里我们将真正说明UDP可以穿透Cone NAT的依据。这里描述的数据结构只是为了说明原理，不具有实际参考价值，真正感兴趣可以阅读Linux的中关于NAT实现部分的源码。真正的NAT实现也没有利用数据库的，呵呵，为了速度！

Symmetric NAPT 工作时的端口映射数据结构如下:

内网信息表:

[NAPT 分配端口] [ 内网IP地址 ] [ 内网端口 ] [ 外网IP地址 ] [ SessionTime 开始时间 ]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依据[NAPT 分配端口]建立主键，必须唯一且建立索引，加快查找.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ] ) -> 表示这两个字段联合起来不能重复.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ], [ 外网IP地址 ] ) -> 表示这三个字段联合起来不能重复.

映射表:

[NAPT 分配端口] [ 外网端口 ]

UNIQUE( [NAPT 分配端口], [ 外网端口 ] ) -> 表示这两个字段联合起来不能重复.

Cone NAPT 工作时的端口映射数据结构如下:

内网信息表:

[NAPT 分配端口] [ 内网IP地址 ] [ 内网端口 ] [ SessionTime 开始时间 ]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依据[NAPT 分配端口]建立主键，必须唯一且建立索引，加快查找.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ] ) -> 表示这两个字段联合起来不能重复.

外网信息表:

[ wid 主键标识 ] [ 外网IP地址 ] [ 外网端口 ]

PRIMARY KEY( [ wid 主键标识 ] ) -> 表示依据[ wid 主键标识 ]建立主键，必须唯一且建立索引，加快查找.
UNIQUE( [ 外网IP地址 ], [ 外网端口 ] ) -> 表示这两个字段联合起来不能重复.

映射表: 实现一对多，的

[NAPT 分配端口] [ wid 主键标识 ]

UNIQUE( [NAPT 分配端口], [ wid 主键标识 ] ) -> 表示这两个字段联合起来不能重复.
UNIQUE( [ wid 主键标识 ] ) -> 标识此字段不能重复.

看完了上面的数据结构是更明白了还是更晕了？呵呵! 多想一会儿就会明白了。通过NAT,内网计算机计算机向外连结是很容易的，NAPT会自动处理，我们的应用程序根本不必关心它是如何处理的。那么外部的计算机想访问内网中的计算机如何实现呢？我们来看一下下面的流程：

c 是一台在NAPT后面的内网计算机，s是一台有外网IP地址的计算机。c 主动向 s 发起连接请求，NAPT依据上面描述的规则在自己的数据结构中记录下来，建立一个Session. 然后 c 和 s 之间就可以实现双向的透明的数据传输了。如下面所示:

c[192.168.0.6:1827] <-> [priv ip: 192.168.0.1]NAPT[pub ip: 61.51.99.86:9881] <-> s[61.51.76.102:8098]

由此可见，一台外网IP地址的计算机想和NAPT后面的内网计算机通讯的条件就是要求NAPT后面的内网计算机主动向外网IP地址的计算机发起一个UDP数据包。外网IP地址的计算机利用收到的UDP数据包获取到NAPT的外网IP地址和映射的端口，以后就可以和内网IP的计算机透明的进行通讯了。

现在我们再来分析一下我们最关心的两个NAPT后面的内网计算机如何实现直接通讯呢? 两者都无法主动发出连接请求，谁也不知道对方的NAPT的公网IP地址和NAPT上面映射的端口号。所以我们要靠一个公网IP地址的服务器帮助两者来建立连接。当两个NAPT后面的内网计算机分别连接了公网IP地址的服务器后，服务器可以从收到的UDP数据包中获取到这两个NAPT设备的公网IP地址和这两个连接建立的Session的映射端口。两个内网计算机可以从服务器上获取到对方的NAPT设备公网IP地址和映射的端口了。

我们假设两个内网计算机分别为A和B，对应的NAPT分别为AN和BN，如果A在获取到B对应的BN的IP地址和映射的端口后，迫不急待的向这个IP
地址和映射的端口发送了个UDP数据包，会有什么情况发生呢？依据上面的原理和数据结构我们会知道，AN会在自己的数据结构中生成一条记录，标识一个新 Session的存在。BN在收到数据包后，从自己的数据结构中查询，没有找到相关记录，因此将包丢弃。B是个慢性子，此时才慢吞吞的向着AN的IP地址和映射的端口发送了一个UDP数据包，结果如何呢？当然是我们期望的结构了，AN在收到数据包后，从自己的数据结构中查找到了记录，所以将数据包进行处理发送给了A。A 再次向B发送数据包时，一切都时畅通无阻了。OK, 大工告成！且慢，这时对于Cone NAPT而言，对于Symmetric NAPT呢？呵呵，自己分析一下吧...

NAPT(The IP Network Address/Port Translator) 进行UDP穿透的具体情况分析!

首先明确的将NAPT设备按照上面的说明分为: Symmetric NAPT 和 Cone NAPT, Cone NAPT 是我们需要的。Win9x/2K/XP/2003 自带的NAPT也为Cone NAPT。

第一种情况, 双方都是Symmetric NAPT:

此情况应给不存在什么问题，肯定是不支持UDP穿透。

第二种情况, 双方都是Cone NAPT:

此情况是我们需要的，可以进行UDP穿透。

第三种情况, 一个是Symmetric NAPT, 一个是Cone NAPT:

此情况比较复杂，但我们按照上面的描述和数据机构进行一下分析也很容易就会明白了, 分析如下,

假设: A -> Symmetric NAT, B -> Cone NAT

1. A 想连接 B, A 从服务器那儿获取到 B 的NAT地址和映射端口, A 通知服务器，服务器告知 B A的NAT地址和映射端口, B 向 A 发起连接，A 肯定无法接收到。此时 A 向 B 发起连接， A 对应的NAT建立了一个新的Session，分配了一个新的映射端口， B 的 NAT 接收到UDP包后，在自己的映射表中查询，无法找到映射项，因此将包丢弃了。

2. B 想连接 A, B 从服务器那儿获取到 A 的NAT地址和映射端口, B 通知服务器, 服务器告知 A B的NAT地址和映射端口,A 向 B 发起连接, A 对应的NAT建立了一个新的Session，分配了一个新的映射端口B肯定无法接收到。此时 B 向 A 发起连接, 由于 B 无法获取 A 建立的新的Session的映射端口，仍是使用服务器上获取的映射端口进行连接，因此 A 的NAT在接收到UDP包后，在自己的映射表中查询，无法找到映射项, 因此将包丢弃了。

根据以上分析，只有当连接的两端的NAT都为Cone NAT的情况下，才能进行UDP的内网穿透互联。

NAPT(The IP Network Address/Port Translator) 进行UDP穿透如何进行现实的验证和分析!

需要的网络结构如下:

三个NAT后面的内网机器，两个外网服务器。其中两台Cone NAPT，一台 Symmetric NAPT。

验证方法:

可以使用本程序提供的源码，编译，然后分别运行服务器程序和客户端。修改过后的源码增加了客户端之间直接通过IP地址和端口发送消息的命令，利用此命令，你可以手动的验证NAPT的穿透情况。为了方便操作，推荐你使用一个远程登陆软件，可以直接在一台机器上操作所有的相关的计算机，这样很方便，一个人就可以完成所有的工作了。呵呵，本人就是这么完成的。欢迎有兴趣和经验的朋友来信批评指正，共同进步。

原始作者: Hwycheng Leo(FlashBT@Hotmail.com)

源码下载: http://bbs.hwysoft.com/download/UDP-NAT-LEO.rar
参考：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
P2P之UDP穿透NAT的原理与实现(shootingstars)

文章说明:

关于UDP穿透NAT的中文资料在网络上是很少的，仅有< >这篇文章有实际的参考价值。本人近两年来也一直从事P2P方面的开发工作，比较有代表性的是个人开发的BitTorrent下载软件 - FlashBT(变态快车). 对P2P下载或者P2P的开发感兴趣的朋友可以访问软件的官方主页: http://www.hwysoft.com/chs/ 下载看看，说不定有收获。写这篇文章的主要目的是懒的再每次单独回答一些网友的提问, 一次性写下来, 即节省了自己的时间，也方便了对于P2P的UDP穿透感兴趣的网友阅读和理解。对此有兴趣和经验的朋友可以给我发邮件或者访问我的个人Blog留言: http://hwycheng.blogchina.com.
您可以自由转载此篇文章，但是请保留此说明。

再次感谢shootingstars网友的早期贡献. 表示谢意。

地狱男爵(hellboys) 2006-09-13 00:32 发表评论

desktop推荐使用ubuntu

地狱男爵(hellboys) — Tue, 29 Aug 2006 09:40:00 GMT

在安装ubuntu6.061LTS 以后,感觉非常不错.

桌面部分ubuntu5 和ubuntu6有很大的改进.不要自己费劲去装输入法了. 自带的scim感觉很不错.兼容性也可以.影音部分只要安装个 w32code就可以rth可以很流畅的play 决大部分格式的文件.
驱动也支持的比较好.不过自己又做了一下nv的驱动.感觉也没什么太大的变化.
还有一贯的继承deb的安装包组织.可以很舒服的setup 一些东东. 这个就不做广告了. 有兴趣的可以试试.

感觉可惜的就是 apt-get 是lock单任务的, 安装很多东东的时候不太方便.

其实不必要用她和windows来比较. 因为各自的方式.如何你很喜欢shell,那么linux更加方便.当然,ubuntu6用户体验已经有了很大的提升,已经和windows很接近了.其实就是用户习惯的问题.

单张光盘的iso也让人非常满意.

地狱男爵(hellboys) 2006-08-29 17:40 发表评论

了解SNMP简单网络管理协议

地狱男爵(hellboys) — Fri, 14 Jul 2006 09:10:00 GMT

了解 SNMP 简单网络管理协议

1. 基于 T C P / I P 的网络管理包含 3 个组成部分：

1) 一个管理信息库 M I B （ Management Information Base ）。管理信息库包含所有代理进程

的所有可被查询和修改的参数。

2) 关于 M I B 的一套公用的结构和表示符号。叫做管理信息结构 S M I 。例如： S M I

定义计数器是一个非负整数，它的计数范围是 0~4 294 967 295 ，当达到最大值时，又从 0 开始

计数。

3) 管理进程和代理进程之间的通信协议，叫做简单网络管理协议 S N M P （ Simple Network

Management Protocol ）

一般是 udp 协议，默认端口 udp:161.

2. 协议

关于管理进程和代理进程之间的交互信息， S N M P 定义了 5 种报文：

1) g e t - r e q u e s t 操作：从代理进程处提取一个或多个参数值。

2) g e t - n e x t - r e q u e s t 操作：从代理进程处提取一个或多个参数的下一个参数值（关于“下一个（ n e x t ）”的含义将在后面的章节中介绍）。

3) s e t - r e q u e s t 操作：设置代理进程的一个或多个参数值。

4) g e t - r e s p o n s e 操作：返回的一个或多个参数值。这个操作是由代理进程发出的。它是前面 3 中操作的响应操作。

5) t r a p 操作：代理进程主动发出的报文，通知管理进程有某些事情发生。

版本字段是 0 。该字段的值是通过 S N M P 版本号减去 1 得到的。显然 0 代表 SNMP v1 。

差错状态字段是一个整数，它是由代理进程标注的，指明有差错发生。图是参数值、名称和描述之间的对应关系。

差错索引字段是一个整数偏移量，指明当有差错发生

时，差错发生在哪个参数。它是由代理进程标注的，并且

只有在发生 n o S u c h N a m e 、 r e a d O n l y 和 b a d V a l u e 差错

时才进行标注。

3. 对象标识符

对象标识是一种数据类型，它指明一种“授权”命名的对象。“授权”的意思就是这些标

识不是随便分配的，它是由一些权威机构进行管理和分配的

对象标识是一个整数序列，以点（“ . ”）分隔。这些整数构成一个树型结构，类似于 D N S

或 U n i x 的文件系统。对象标识从树的顶部开始，顶部没有标识，以 r o o t 表示（这和

U n i x 中文件系统的树遍历方向非常类似）。树上的每个结点同时还有一个文字名。例如标识 1 . 3 . 6 . 1 . 2 . 1 就和 i s o . o r g . d o d .

i n t e r n e t . m e m t . m i b 对应。这主要是为了人们阅读方便。在实际应用中，也就是说在管理进程

和代理进程进行数据报交互时， M I B 变量名是以对象标识来标识的，当然都是以 1 . 3 . 6 . 1 . 2 . 1 开头的。

在图中，我们除了给出了 m i b 对象标识外，还给出了 i s o . o r g . d o d . i n t e r n e t .

p r i v a t e . e n t e r p r i s e s （ 1 . 3 . 6 . 1 . 4 . 1 ）这个标识。这是给厂家自定义而预留的。在 A s s i g n e d

Number RFC 中列出了在该结点下大约 4 0 0 个标识。

此篇自做个人参考 .

更多了解请看 TCPIP 协议详解卷一 ( 协议 ) 25 章 .

地狱男爵(hellboys) 2006-07-14 17:10 发表评论

Mysql 集群简介和配置

地狱男爵(hellboys) — Wed, 28 Jun 2006 03:58:00 GMT

1．先了解一下你是否应该用 mysql 集群。

减少数据中心结点压力和大数据量处理，采用把 mysql 分布，一个或多个 application 对应一个 mysql 数据库。把几个 mysql 数据库公用的数据做出共享数据，例如购物车，用户对象等等，存在数据结点里面。其他不共享的数据还维持在各自分布的 mysql 数据库本身中。

2．集群 Mysql 中名称概念 .( 如上图 )

1 ） Sql 结点（ SQL node-- 上图对应为 mysqld ） : 分布式数据库。包括自身数据和查询中心结点数据 .

2 ）数据结点 (Data node -- ndbd): 集群共享数据 ( 内存中 ).

3 ）管理服务器 (Management Server – ndb_mgmd): 集群管理 SQL node,Data node.

3 ．配置

mysql-max 版本，当然现在 mysql 集群系统 windonws 平台上面不被支持 .

安装 mysql 就不多说了，网上一打堆，简明扼要。

A:192.168.1.251 – Data node 和 Management Server.

B:192.168.1.254 – SQL node.

当然，你也可以让一个机器同时为 3 者。

A,B my.inf 加上：

[MYSQLD]

ndbcluster # run NDB engine

ndb-connectstring=192.168.1.251 # location of MGM node

# Options for ndbd process:

[MYSQL_CLUSTER]

ndb-connectstring=192.168.1.251 # location of MGM node

A: /var/lib/mysql-cluster/config.ini

[NDBD DEFAULT]

NoOfReplicas=1 # Number of replicas

DataMemory=80M # How much memory to allocate for data storage

IndexMemory=18M # How much memory to allocate for index storage

# For DataMemory and IndexMemory, we have used the

# default values. Since the "world" database takes up

# only about 500KB, this should be more than enough for

# this example Cluster setup.

# TCP/IP options:

[TCP DEFAULT]

portnumber=2202 # This the default; however, you can use any

# port that is free for all the hosts in cluster

# Note: It is recommended beginning with MySQL 5.0 that

# you do not specify the portnumber at all and simply allow

# the default value to be used instead

# Management process options:

[NDB_MGMD]

hostname=192.168.1.251 # Hostname or IP address of MGM node

datadir=/var/lib/mysql-cluster # Directory for MGM node logfiles

# Options for data node "A":

[NDBD]

# (one [NDBD] section per data node)

hostname=192.168.1.251 # Hostname or IP address

datadir=/usr/local/mysql/data # Directory for this data node's datafiles

# SQL node options:

[MYSQLD]

hostname=192.168.1.254

#[MYSQLD] # 这个相当于 192.168.1.251

4. 启动测试

· 在管理服务器上面(这里是192.168.1.251):

				
						·                
				
				
						shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini

· 在数据结点服务器上面(依然是192.168.1.251 and more):

				
						·                
				
				
						shell> ndbd --initial (
						
								第一次时加 --initial 参数)

· SQL 结点服务器上面(192.168.1.254):

				
						·                
				
				
						shell> mysqld &

在 251 上面察看

./ndb_mgm

-- NDB Cluster -- Management Client --

ndb_mgm> show

Connected to Management Server at: 192.168.1.251:1186

Cluster Configuration

---------------------

[ndbd(NDB)] 1 node(s)

id=2 @192.168.1.251 (Version: 5.0.22, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 1 node(s)

id=1 @192.168.1.251 (Version: 5.0.22)

[mysqld(API)] 1 node(s)

id=3 @192.168.1.254 (Version: 5.0.22)

关闭集群：

shell> ndb_mgm -e shutdown

5 ．基本的集群说明

1 ）在mysql 集群中.当table引擎为NDBCLUSTER时才做集群，其他非NDBCLUSTER表和一般mysql数据库表一样，不会共享数据. NDBCLUSTER 表数据存储在Data node服务器内存中，Data Node可以为1台或多台服务器，它们之间存放共享数据。Data Node服务器可以分组数据copy。

例如：2,3,4,5 为四台Data Node服务器ID. 2,3为组0。 4，5为组1。 2，3维持数据相同， 4，5维持数据相同。组0和组1维持数据不同。

2 ） sql node 服务器中，非NDBCLUSTER数据存在本身数据库中，table引擎为NDBCLUSTER时，数据存储在Data Node 中。当查询NDBCLUSTER表时，它会从Data node集群中提起数据.

3)Manager server

管理SQl node 和Data node 状态。

6 深入了解

http://dev.mysql.com/doc/refman/5.0/en/ndbcluster.html

地狱男爵(hellboys) 2006-06-28 11:58 发表评论

基于Linux的VPN服务器

地狱男爵(hellboys) — Sat, 29 Apr 2006 16:21:00 GMT

VPN(Virtual Private Network，虚拟专用网络)是专用网络的延伸，它可以通过共享Internet或公共网络连接模拟点对点专用连接的方式，在本地计算机和远程计算机之间发送数据。
它具有良好的保密性和不受干扰性，使双方能够进行自由而安全的点对点连接。下面介绍一种快速构建VPN服务器的方法。

安装软件

1.安装PPP

安装PPP（Point-to-Point Protocol，点到点协议）2.4.2以上的版本，可以到http://sourceforge.net/project/showfiles.php?group_id=44827下载ppp-2.4.3-0.cvs_20040527.1.i386.rpm软件包。

安装命令如下：

#rpm -Uvh ppp-2.4.3-0.cvs_20040527.1.i386.rpm

2.安装内核MPPE补丁

安装内核MPPE（Microsoft Point to Point Encryption，微软点对点加密）补丁需要根据内核选择相应的版本。笔者使用的Linux内核是2.4.20-31.9版本，可以到http: //pptpclient.sourceforge.net/mppe/kernel-mppe-2.4.20-31.9.i686.rpm下载相应的 kernel-mppe-2.4.20-31.9.i686.rpm软件包。安装命令如下：

#rpm -ivh kernel-mppe-2.4.20-31.9.i686.rpm

用以下命令检查内核MPPE补丁是否安装成功：

#modprobe ppp-compress-18

3.检查PPP是否支持MPPE

用以下命令检查PPP是否支持MPPE：

#strings '/usr/sbin/pppd' |grep -i mppe | wc --lines

如果以上命令输出为“0”则表示不支持；输出为“30”或更大的数字就表示支持。
4.安装PPTPD

到http://sourceforge.net/project/showfiles.php?group_id=44827下载pptpd-1.1.4-b4.i386.rpm软件包，并安装。

# rpm -ivh pptpd-1.1.4-b4.i386.rpm

修改配置文件

1.修改modules.conf文件

编辑/etc/modules.conf配置文件，加入如下内容：

alias net-pf-47 ip_gre

2.修改pptpd.conf文件

编辑/etc/pptpd.conf配置文件，添加如下内容，确定本地VPN服务器的IP地址和客户端登录后分配的IP地址范围。

debug
option /etc/ppp/options.pptpd
localip 192.168.0.254 #本地VPN服务器的IP
remoteip 192.168.1.1-254 #客户端被分配的IP范围

3.修改options.pptpd文件

编辑/etc/ppp/options.pptpd配置文件，替换成如下内容：

auth
lock
debug
proxyarp
lock
name rh9vpn #VPN服务器的名字
multilink
refuse-pap
refuse-chap
refuse-mschap
refuse-eap
refuse-mschap-v2
require-mppe
ms-wins 192.168.1.2 #把想要在网络邻居中看到的机器的IP填写到这里
ms-dns 192.168.1.2 #DNS服务器地址
dump
logfile /var/log/pptpd.log #日志存放的路径
4.修改chap-secrets文件

编辑/etc/chap-secrets配置文件，添加如下内容：

# client server secret IP addresses
"test@gd.cn" * "test" *

上面第二行代码的四项内容分别对应第一行中的四项。“test@gd.cn” 是Client端的VPN用户名；“server”对应的是VPN服务器的名字，该名字必须和/etc/ppp/options.pptpd文件中指明的一样，或者设置成“*”号来表示自动识别服务器；“secret”对应的是登录密码；“IP addresses”对应的是可以拨入的客户端IP地址，如果不需要做特别限制，可以将其设置为“*”号。

5.设置IP伪装转发

只有设置了IP伪装转发，通过VPN连接上来的远程计算机才能互相ping通，实现像局域网那样的共享。用下面的命令进行设置：

#echo 1 > /proc/sys/net/ipv4/ip_forward

可以将这条命令放到文件/etc/rc.d/rc.local里面，以实现每次开机时自动运行该命令。

6.打开防火墙端口

将Linux服务器的1723端口和47端口打开，并打开GRE协议。

#/sbin/iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
#/sbin/iptables -A INPUT -p tcp --dport 47 -j ACCEPT
#/sbin/iptables -A INPUT -p gre -j ACCEPT

启动服务.

　　/etc/rc.d/init.d/pptpd start

在RHEL系列配置服务:
   cp /usr/sbin/pptpd /etc/rc.d/init.d/
   可以用chkconfig --add pptpd 来添加/sbin/service pptpd 下面服务
   笨方法/etc/rc.d/rc.l/sbin/service pptpd start

      cat rc.local
#!/bin/sh
/sbin/service pptpd start
echo 1 > /proc/sys/net/ipv4/ip_forward

到这里Linux服务器的设置就完成了，下面将利用Windows客户端进行测试。
测试

下面以Windows Server 2003为例来进行测试。

1.新建连接

单击“开始→设置→网络和拨号连接”打开“网络和拨号连接”的窗口，再单击“新建连接”打开“网络连接向导”的窗口，然后依次选择或填写“连接到我的工作场所网络→虚拟专用网络连接→公司名（可以随便填写）→不拨初始连接→IP地址（填入VPN服务器的IP地址）”，最后单击“确定”，就建立了一个新的连接。

2. 修改连接属性

右击刚才创建的连接，再依次单击“属性→网络（选择TCP/IP协议）→属性→高级”，然后把“在远程网络上使用默认网关”前面的勾去掉后单击“确定”。

3.建立连接

双击刚才建立好的连接，填入提前设置好的用户名和密码，单击“确定”进行连接。如果连接成功，在连接的“详细信息”里应该可以看到服务器所分配的IP地址等信息。这时，就可以跟连接进入的局域网里的其它计算机进行通信了。

如果客户端使用的仍然是Windows 95或Windows 98，则需要到http://support.microsoft.com/support/kb/articles/q285/1/89.asp下载相关的拨号程序。

地狱男爵(hellboys) 2006-04-30 00:21 发表评论

How Windows Peer-to-Peer Networking Works

地狱男爵(hellboys) — Sat, 01 Apr 2006 17:07:00 GMT

How Windows Peer-to-Peer Networking Works

In this section, we briefly describe the Windows Peer-to-Peer Networking architecture and then describe the details of the fundamental peer-to-peer capabilities of peer discovery and name resolution, graphing, grouping, replicated storage, and searching.

Windows Peer-to-Peer Networking Architecture

The architecture of Windows Peer-to-Peer Networking is shown in Figure 1.

Figure 1: Windows Peer-to-Peer Networking architecture
See full-sized image.

Windows Peer-to-Peer Networking architecture consists of the following components:

•	Graphing The Graphing component is responsible for maintaining a set of connected nodes known as a graph and providing flooding and replication of data across the graph. The Graphing component uses the Flood & Synchronization, Store, and Graph Maintenance subcomponents.
•	Grouping The Grouping component is the security layer provided by default on top of a graph. The security layer defines the security model behind group creation, invitation, and connection to the group. In addition, Grouping leverages PNRP as the name resolution protocol - and enables multiple applications to share the same graph. The Grouping component uses the Group Security and Group Security Service Provider (SSP) subcomponents.
•	NSP The Name Service Provider (NSP) component provides a mechanism to access an arbitrary name service provider. In the case of Windows Peer-to-Peer Networking, peer-to-peer applications use the NSP interface to access PNRP.
•	PNRP The PNRP component provides peer-to-peer name resolution.
•	Identity Manager Identity manager enables the creation and management of peer-to-peer identities.
•	Microsoft TCP/IP version 6 protocol The Microsoft TCP/IP version 6 protocol (IPv6) provides the transport over which Windows Peer-to-Peer Networking operates.

The details of how Windows Peer-to-Peer Networking works are described in the following sections:

•	IPv6 and NAT traversal
•	Name resolution and peer discovery with PNRP
•	Graphing
•	Grouping
•	Replicated store
•	Searching

IPv6 and NAT Traversal

Windows Peer-to-Peer Networking uses IPv6 as its Internet layer. IPv6 was chosen because it restores the end-to-end computing model to networking. With IPv6, there are no issues with address shortage that require the use of Network Address Translators (NATs). For more information about how NATs translate addresses and port numbers and use port mappings, see Windows 2000 Network Address Translator (NAT). NATs for IPv4 extend the lifetime of the IPv4 public address space, but at the expense of breaking end-to-end communication.

IPv6 support was included in Windows XP and Windows XP with SP1 as a developer preview edition. A production-quality release of an IPv6 protocol is available in Windows XP with SP1, Windows XP with SP2, and the Windows Server™ 2003 family. A common misconception about IPv6 is that the existing IPv4 infrastructure (your intranet and the Internet) must be upgraded to support IPv6 before it can be used. This is not true. The designers of IPv6 realized that IPv4 infrastructures will be in place for the foreseeable future and created a series of transition technologies that allow IPv6 traffic to be sent over an IPv4 network by encapsulating an IPv6 packet with an IPv4 header.

The two transition technologies that are recommended for use and enabled by default for the IPv6 protocol for Windows XP and the Windows Server 2003 family are the following:

•

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

ISATAP is an address assignment and automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet. ISATAP is described in the Internet draft titled "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)".

•

6to4

6to4 is an address assignment and automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. 6to4 is described in RFC 3056.

For more information about ISATAP and 6to4, see the IPv6 Transition Technologies white paper.

For IPv6 connectivity across the IPv4 Internet, 6to4 is the preferred address assignment and tunneling technology. However, 6to4 depends on the assignment of a public IP address to a computer connected to a private network that acts as a 6to4 router. The IPv6 protocol for Windows XP and the Windows Server 2003 family can be used as a 6to4 router either automatically by enabling Internet Connection Sharing (ICS) or through manual configuration. Many Network Address Translators (NATs) that are used to connect small office or home office networks to the Internet do not yet have 6to4 router capability. Additionally, there might be more than one NAT between a host on a private network and the IPv4 Internet, in which case 6to4 would not work even if the NAT connected to the private network had 6to4 functionality. Another issue with NATs is their default inability to forward traffic that does not use either TCP or UDP. IPv6 over IPv4 traffic uses protocol 41. If this type of traffic is not recognized by the NAT, it is discarded.

To address the need for an IPv6 over IPv4 address assignment and tunneling solution that works for hosts that are located across NATs that cannot also be 6to4 routers, Microsoft is working with the Internet standards bodies to define Teredo, also known as IPv6 NAT Traversal (NAT-T). Teredo is defined in an Internet draft titled "Teredo: Tunneling IPv6 over UDP through NATs".

Teredo works by assigning global IPv6 addresses that are based on the public IPv4 address of the NAT interface that is connected to the Internet and then encapsulating IPv6 packets with both an IPv4 header and a UDP header. By using both an IPv4 and a UDP header, most NATs can translate Teredo traffic.

Teredo client support is included with Windows XP SP2. For computers running Windows XP with SP1, you must install the Advanced Networking Pack for Windows XP.

For additional information about how Teredo works, see the "Teredo Overview" white paper.

Name Resolution and Peer Discovery with PNRP

In order for communication to occur between peers, they must be able to discover each other's presence and resolve each other's network locations (addresses, protocols, and ports) from names or other types of identifiers. How peers discover each other and resolve each other's names for communication is complicated by transient connectivity and the lack of address records in DNS.

Windows Peer-to-Peer Networking solves this problem with a name resolution and peer discovery scheme with the following attributes:

•	Distributed and serverless for name resolution Like DNS, the complete list of names is stored on computers throughout the cloud. Unlike DNS, there are no servers that provide name resolution. Each peer stores a portion of the list in its cache and can refer to other peers. Central servers are not used to resolve names. Windows Peer-to-Peer Networking is not strictly serverless, as there is a seed node that facilitates initialization.
•	The use of identifiers (IDs) instead of names Rather than using a name, such as a fully qualified domain name in DNS, IDs are used to identify peer entities. IDs are just numbers and therefore are not subject to language and trademark or copyright issues.
•	The use of multiple IDs Each separate peer computer, user, group, device, service or other type of peer node can have its own peer ID.
•	Ability to scale to large numbers of IDs The list of IDs is distributed among the peers using a multi-level cache and referral system that allows name resolution to scale to billions of IDs, while requiring minimal resources on each node.

The protocol used to send messages between peers for name resolution and peer discovery is Peer Name Resolution Protocol (PNRP).

PNRP uses multiple clouds, in which a cloud is a grouping of computers that use addresses of a specific scope. A scope is an area of the network over which the address is unique. PNRP clouds are based on the address scopes for IPv6 addresses. The following clouds are defined:

•	The global cloud corresponds to the global IPv6 address scope and represents all the computers on the entire IPv6 Internet. There is only a single global could.
•	The site-specific cloud corresponds to the site IPv6 address scope and site-local addresses. A site is a portion of an organization network that has defined geographical or topological boundaries. There can be multiple site-specific clouds.
•	The link-local cloud corresponds to the link-local IPv6 address scope and link-local addresses. A link-local cloud is for a specific link, typically the same as the locally attached subnet. There can be multiple link-local clouds.

地狱男爵(hellboys) 2006-04-02 01:07 发表评论

NAT和P2P网络

地狱男爵(hellboys) — Sat, 01 Apr 2006 17:00:00 GMT

互联网是基于32位IP地址的，这意味着互联网理论上最大电脑数目约为四万亿。由于IP地址使用方式的无效性，实际的数量会少得多。实际上，互联网过不了多久就会将IP地址用完。

因为可用的IP地址越来越少，一种被称为网络地址解析或箭称NAT的技术被开发出来，它允许以一个IP地址来代表整个网络的电脑。

一个NAT处在公用互联网与它所服务的网络之间，重写数据中IP头部的IP地址和端口号以使所有的包看上去都象从一个NAT设备的公用IP地址发来（或到它去）的，而不是发自（往）实际的源或者目标。

NAT如今已经在小型家庭－办公室路由被普遍租用,也在很多软件中被用户使用以连接几台PC到一个唯一的电缆MODEM。它甚至被一些ISP使用。

（NAT不是唯一可能的解决办法，代理服务器也被普遍使用，但需要更多的配置，有时还需要要定制的客户端软件。而最终，我们都将转换到IPｖ6，它将使用128位地址，可以解决已有的及所有的问题，但那将在很久后才会普及。

某些协议是非NAT友好的

一些应用程序将IP和端口号隐藏在它们的数据包中发送，NAT不能正确重写它们，所以当你想在NAT网络内使用那些程序的话，它们将不会正确运行。

一些NAT，由于安全原因，只允许从已经发送过数据去的外部地址接收数据。这意味着处于不同NAT后的两个人不能以通常的方式建立连接。

解决办法

希望NAT友好的Peer-to-peer（点对点）协议必须明确：其所嵌入数据包的任何地址在通过NAT时都可能变梦扌В虼诵枰咕取Ｒ桓隹尚械姆椒ㄈ缦拢?/p>

两点之间所有的数据流都通过一个单一的UDP端口。存在着一个不处于任何NAT之后的地址服务器，用户首先与地址服务器连接，并发送他们认为拥有的IP地址；服务器标记该地址和它在UDP头部所看到的地址。然后服务器将两个地址都送往其它点。这样，所有人都知道其它人的地址。

为打开点对点的连接，所有的旧（结）点发送一个UDP包到新的（结）点，且新（结）点发送一个UDP包到每一个老（结）点。因为无人知道开始它们是否处于同一个NAT之后，第一个包往往被同时送往公有和私有地址。

这导致每个人的NAT为UDP数据流的通过打开一个双向的洞。一旦第一个响应从每个（结）点返回，发送者就知道使用哪个返回地址，并能停止向两个地址发送数据。

兼容性需求

基于和超越基本的NAT　RFC，一个想支持这个技术的NAT设备必须有以下要求的属性：

＞＞NAT不允许改变被数据流使用的UDP端口号。
如果一个处于NAT之后的主机从一个单一的UDP口发送了一系列的包，被NAT接棒后的包也必须表现为来自同一主机和UDP口。

RFC蓝图

我正在拟订这项技术RFC蓝图更为详细的细节。如果你感兴趣，请与我联系。

兼容性测试结果

我正在测试实现几个NAT通讯的兼容性。这里是部分结果：

已知的NAT实现的兼容性

＞＞NAT1000：完全兼容。感谢Nevod技术人员早期所帮助做的兼容性测试。无任何东西需要改变；这项技术与他们的NAT一起运行很稳定。Nevod已经不再存在了，它已被微软兼并。
＞＞Win98 SE包含的网络联接共享软件，起源贜AT1000，所以一定运行良好。
＞＞SYGATE：完全兼容。
＞＞NAT32：1999年1月5号公布的BETA测试版完全兼容。现在公布的版本也应该完全兼容。
＞＞LINUX　IP　Masquerading（LINUX　IP伪装）：2.2.1版本内核和后续版本可以正常运行。请到http://juanjox.linuxhq.com/?寻找早期2.1版本的补丁。2.0版本的补丁见Glenn Lamb的页面：http://home.indyramp.com/lists/masq/msg03024.html：
ftp://ftp.netcom.com/pub/mu/mumford/loose-udp-2.0.36.patch.gz；
Glenn的端口使之拥有一个配置时选项CONFIG_IP_MASQ_LOOSE_UDP，这是一个很好的举措。
＞＞WinNAT：当前版本工作正常。

NAT实现即将可兼容的

＞＞Arescom Apex 1100 ISDN路由：Arescom在1999年1月针对此问题发布了一个固件补丁；也许现在已经并入其标准固件里了,但我还没有证实。
＞＞Vicomsoft Softrouter Plus：Vicom曾公布过一个版本以解决这个问题，但我还没有机会来测试一下。注意：为使这个实现正常运行，你必须把网关设备上除指向内部以太适配器外的所有本地TCP绑定禁止。在使用Vicom的安装助手之前请阅读其文档。

未知是否兼容的

＞＞Cisco IOS有一内置的NAT兼容特性，也许有用也许不然。
＞＞我们已经测试了我们手上所有能得到的WIN32软件。但还没有测试嵌入到许多小型家庭办公路由中的NAT，也没有测试外置的NAT如SonicWall等。

不兼容的

＞＞所有的纯代理服务器解决办法，如WINGATE2或者PPPShar，都不能正常运行。

使用这项技术的软件

以下软件包是已知的支持在NAT后操作的：
＞＞Civilization: Call To Power
＞＞Heavy Gear 2

讨论区

我想听到其它开发者对于这项技术的想法，以及Masq如何被重写以正确复用UDP端口。加入NAT-peer-games（http://onelist.com/viewarchive.cgi?listname=nat-peer-games）邮件列表让我们一起讨论。

实施问题

在测试SYGATE和近期NAT1000版本时，我遇到一些实施方面的问题。当运行网关的机器是通过MODEM与INTERNET联接的话所有一切均正常。但如果网关机器是通过以太网与INTERNET联接的话，客户端不能访问那个外部以太网上的其它主机。看上去就象那台网关送出来的包完全被外部以太网上的其它主机丢弃了。然而路由器不会丢弃数据，所以与远程主机联接没有问题。想了解更多信息，请到my Usenet post（http://www.dejanews.com/getdoc.xp?AN=427631763）获取。

我倾向于相信这是硬件原因，但谁知道呢...

链接

＞＞IETF Working Group on NAT：
http://www.ietf.org/html.charters/nat-charter.html
新的RFC草图和邮件列表。其中一个文档
http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-issues-01.txt
提到这项技术；搜索关键词“Activision”

＞＞NAT页面：
http://www.uq.edu.au/~gadmacka/the-nat-page/
列出了一些可行的NAT实现

＞＞LINUX　IP伪装：
http://www.indyramp.com/masq/
都是关于NAT实现的LINUX之Masq。

＞＞MASQ邮件列表的可查询索引：
http://www.mail-archive.com/masq@tori.indyramp.com/

＞＞LINUX　IP　NAT论坛：
http://serf.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html
NAT论文，老式的不支持的LINUX　NAT实现和一个讨论区。多半为了历史兴趣。

历史

相对于我的知识来讲这是一项新技术。我在1997年开始研究它，并在1998年用它完成了我的第一个作品。这项技术在制作Activision多玩家游戏中被开发。

地狱男爵(hellboys) 2006-04-02 01:00 发表评论

IDS：Intrusion Detection System

地狱男爵(hellboys) — Fri, 24 Mar 2006 06:52:00 GMT

入侵检测系统（IDS）主要检测计算机网络中的非法、错误或者异常行为。运行在主机上，并且负责检测该主机上恶意破坏行为的 ID 系统，被称之为主机型 ID 系统。

　　主机型 IDS 软件被安装于需要监控的系统上。IDS 软件上的数据源是日志文件和/或系统审计代理。主机型 IDS 不仅着眼于计算机中通信流量的出入，同时也校验用户系统文件的完整性，并检测可疑程序。为了能使基于主机的 IDS 完整地覆盖受控站点，需要在每台计算机上都安装 IDS 系统。

　　主机型入侵检测软件主要有两种类型：主机 wrapper /个人防火墙和基于代理的软件。与网络型 IDS 相比，主机型 IDS 中每种检测内部攻击（即所谓的异常行为）的方法都更为高效，但相对而言，两者在检测外部攻击方面都非常有效。主机 wrapper 或者个人防火墙都可以配置来着眼于受控机器的所有网络数据包，连接尝试或登录尝试等。另外还包含拨号尝试或者其它非网络相关通信端口等功能。

　　网络型 IDS 的数据源是网络上的数据包，IDS 监控各网段的数据包流量作为。网络接口卡被设置为混合模式，以获取跨越各网段的所有网络流量。但网络型 IDS 不能监控其它各段上的网络流量。

　　网络型 IDS 着眼于经过传感器的网络数据包。传感器只能看到与其相连的网络段上装载的数据包。如果为这些数据包都匹配一个标志，那么主要有以下三种标志类型：

串标志（String Signature）：着眼于文本串，表示可能性功能。为降低串信号错误数量，使用复合串信号是非常必要的。
端口标志（Port Signature）：着眼于众所周知的、高频率的攻击端口的连接尝试。例如 telnet（TCP 端口23）、FTP（TCP 端口21/20）、SUNRPC（TCP/UDP 端口111）和 IMAP （TCP 端口143）等端口。
头标志（Header Signature）：着眼于危险的或不合理的数据包头结合。其中最著名的例子是 Winnuke，数据包被指定 NetBIOS 端口和紧急指针，或者设置带外指针。对微软系统来说这将导致“蓝频死机”现象。

　　网络型和主机型 IDS 都具有正反两面。所以通常情况下，网络中结合两种技术提供完整保护功能。总之，有关何处使用到这三种类型，以及如何整合数据都是一个切实且日益关注的主题。

地狱男爵(hellboys) 2006-03-24 14:52 发表评论