精华内容
下载资源
问答
  • IPSec穿越NAT报文

    2019-04-16 13:52:38
    IPSec报文穿越NAT报文
  • 1.1. 什么是NAT 在传统的标准的TCP/IP通信过程中,所有的路由器仅仅是充当一个中间人的角色,也就是通常所说的存储转发,路由器并不会对转发的数据包进行修改,更为确切的说,除了将源MAC地址换成自己的MAC地址以外...

    1.1. 什么是NAT

    在传统的标准的TCP/IP通信过程中,所有的路由器仅仅是充当一个中间人的角色,也就是通常所说的存储转发,路由器并不会对转发的数据包进行修改,更为确切的说,除了将源MAC地址换成自己的MAC地址以外,路由器不会对转发的数据包做任何修改。NAT(Network Address Translation网络地址翻译)恰恰是出于某种特殊需要而对数据包的源ip地址、目的ip地址、源端口、目的端口进行改写的操作。

    1.2. 为什么要进行NAT

    我们来看看再什么情况下我们需要做NAT。

    假设有一家ISP提供园区Internet接入服务,为了方便管理,该ISP分配给园区用户的IP地址都是伪IP,但是部分用户要求建立自己的WWW服务器对外发布信息,这时候我们就可以通过NAT来提供这种服务了。我们可以在防火墙的外部网卡上绑定多个合法IP地址,然后通过NAT技术使发给其中某一个IP地址的包转发至内部某一用户的WWW服务器上,然后再将该内部WWW服务器响应包伪装成该合法IP发出的包。

    再比如使用拨号上网的网吧,因为只有一个合法的IP地址,必须采用某种手段让其他机器也可以上网,通常是采用代理服务器的方式,但是代理服务器,尤其是应用层代理服务器,只能支持有限的协议,如果过了一段时间后又有新的服务出来,则只能等待代理服务器支持该新应用的升级版本。如果采用NAT来解决这个问题,

    因为是在应用层以下进行处理,NAT不但可以获得很高的访问速度,而且可以无缝的支持任何新的服务或应用。

    还有一个方面的应用就是重定向,也就是当接收到一个包后,不是转发这个包,而是将其重定向到系统上的某一个应用程序。最常见的应用就是和squid配合使用成为透明代理,在对http流量进行缓存的同时,可以提供对Internet的无缝访问。

    1.3. NAT的类型

    在linux2.4的NAT-HOWTO中,作者从原理的角度将NAT分成了两种类型,即源NAT(SNAT)和目的NAT(DNAT),顾名思义,所谓SNAT就是改变转发数据包的源地址,所谓DNAT就是改变转发数据包的目的地址。

    在“用iptales实现包过虑型防火墙”一文中我们说过,netfilter是Linux 核心中一个通用架构,它提供了一系列的"表"(tables),每个表由若干"链"(chains)组成,而每条链中可以有一条或数条规则(rule)组成。并且系统缺省的表是"filter"。但是在使用NAT的时候,我们所使用的表不再是"filter",而是"nat"表,所以我们必须使用"-t nat"选项来显式地指明这一点。因为系统缺省的表是"filter",所以在使用filter功能时,我们没有必要显式的指明"-t filter"。

    同filter表一样,nat表也有三条缺省的"链"(chains),这三条链也是规则的容器,它们分别是:

    PREROUTING:可以在这里定义进行目的NAT的规则,因为路由器进行路由时只检查数据包的目的ip地址,所以为了使数据包得以正确路由,我们必须在路由之前就进行目的NAT;

    POSTROUTING:可以在这里定义进行源NAT的规则,系统在决定了数据包的路由以后在执行该链中的规则。

    OUTPUT:定义对本地产生的数据包的目的NAT规则。

    如前所述,在使用iptables的NAT功能时,我们必须在每一条规则中使用"-t nat"显示的指明使用nat表。然后使用以下的选项:

    2.1. 对规则的操作

    加入(append) 一个新规则到一个链 (-A)的最后。

    在链内某个位置插入(insert) 一个新规则(-I),通常是插在最前面。

    在链内某个位置替换(replace) 一条规则 (-R)。

    在链内某个位置删除(delete) 一条规则 (-D)。

    删除(delete) 链内第一条规则 (-D)。

    2.2. 指定源地址和目的地址

    a. 使用完整的域名,如“www.linuxaid.com.cn”;

    b. 使用ip地址,如“192.168.1.1”;

    c. 用x.x.x.x/x.x.x.x指定一个网络地址,如“192.168.1.0/255.255.255.0”;

    d. 用x.x.x.x/x指定一个网络地址,如“192.168.1.0/24”这里的24表明了子网掩码的有效位数,这是 UNIX环境中通常使用的表示方法。

    缺省的子网掩码数是32,也就是说指定192.168.1.1等效于192.168.1.1/32。

    3.3. 指定网络接口

    可以使用--in-interface/-i或--out-interface/-o来指定网络接口。从NAT的原理可以看出,对于 PREROUTING链,我们只能用-i指定进来的网络接口;而对于POSTROUTING和OUTPUT我们只能用-o指定出去的网络接口。

    3.4. 指定协议及端口

    可以通过--protocol/-p选项来指定协议,如果是udp和tcp协议,还可--source-port/--sport和 --destination-port/--dport来指明端口。

    4.1. Full NAT

    MASQUERADE target support

    REDIRECT target support

    4.2. 要使用NAT表时,必须首先载入相关模块:

    modprobe ip_tables

    modprobe ip_nat_ftp

    iptable_nat 模块会在运行时自动载入。  

    5.1. 源NAT(SNAT)

    比如,更改所有来自192.168.1.0/24的数据包的源ip地址为1.2.3.4:

    iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to 1.2.3.4

    这里需要注意的是,系统在路由及过虑等处理直到数据包要被送出时才进行SNAT。

    有一种SNAT的特殊情况是ip欺骗,也就是所谓的Masquerading,通常建议在使用拨号上网的时候使用,或者说在合法ip地址不固定的情况下使用。比如

    # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

    可以看出,这时候我们没有必要显式的指定源ip地址等信息。

    5.2. 目的SNAT(DNAT)

    比如,更改所有来自192.168.1.0/24的数据包的目的ip地址为1.2.3.4:

    iptables -t nat -A PREROUTING -s 192.168.1.0/24 -i eth1 -j DNAT --to 1.2.3.4

    这里需要注意的是,系统是先进行DNAT,然后才进行路由及过虑等操作。

    有一种DNAT的特殊情况是重定向,也就是所谓的Redirection,这时候就相当于将符合条件的数据包的目的ip地址改为数据包进入系统时的网络接口的ip地址。通常是在与squid配置形成透明代理时使用,假设squid的监听端口是3128,我 们可以通过以下语句来将来自192.168.1.0/24,目的端口为80的数据包重定向到squid监听

    端口:

    iptables -t nat -A PREROUTING -i eth1 -p tcp -s 192.168.1.0/24 --dport 80

    -j REDIRECT --to-port 3128

    -------------------------------------------------------------------
    查看源文:http://biz.chinabyte.com/17/2048517.shtml

    展开全文
  • ipsec nat穿越报文.pcap

    2019-12-11 15:51:31
    抓包文件:关于ipsec nat 穿越的抓包文件,方便于对协议理解和学习!
  • IPSec协议抓包详解和IPSec NAT穿越报文解析

    万次阅读 多人点赞 2019-04-11 18:44:40
    目录 协议概述 2、IPSec作用 3、认证方式 3.1、预共享密钥 3.2、数字证书 4、ESP加密算法 4.1、ESP完整性检测 4.2、ESP防重放 4.3、ESP防窃听 5、IPSec工作原理 ...7、IPsec穿越NAT ...

    目录

     

    协议概述

    2、IPSec作用

    3、认证方式

    3.1、预共享密钥

    3.2、数字证书

    4、ESP加密算法

    4.1、ESP完整性检测

    4.2、ESP防重放

    4.3、ESP防窃听

    5、IPSec工作原理

    5.1、传输模式

    5.2、隧道模式

    6.1、主动模式

    6.1.1、Ikev1协商

    6.1.2、IPSec加密协商

    6.2、野蛮模式

    7、IPsec穿越NAT

    7.1、IPSec穿越NAT遇到的问题

    7.2、IKE身份确认及协商

    7.3、穿越NAT原理抓包解释


    协议概述

    IP Sec全称:IP Security

    IPSec协议,不是一个单独的协议,而是一系列为IP网络提供完整安全性的协议和服务的集合。

    IPSec协议是一个工作在IP网络层的协议

    作为一个隧道协议实现了VPN通信

    第三层隧道协议,可以在IP层上创建一个安全的隧道,使两个异地的私有网络连接起来,或者使公网上的计算机可以访问远程的企业私有网络。

    2、IPSec作用

    1、保证数据来源可靠

    在IPSec通信之前双方要先用IKE认证对方身份并协商密钥,只有IKE协商成功之后才能通信。由于第三方不可能知道验证和加密的算法以及相关密钥,因此无法冒充发送方,即使冒充,也会被接收方检测出来。

    2、保证数据完整性

    IPSec通过验证算法保证数据从发送方到接收方的传送过程中的任何数据篡改和丢失都可以被检测。

    3、保证数据机密性

    IPSec通过加密算法使只有真正的接收方才能获取真正的发送内容,而他人无法获知数据的真正内容

    3、认证方式

    3.1、预共享密钥

    预共享密钥认证是IPSec双方配置时手工指定的密钥,无需在网络中互相告知密钥

    3.2、数字证书

    1. 响应端发送数字证书到客户端
    2. 发送端收到响应端的数字证书后,会取出附带的数字证书,并读取证书中的发布机构(Issuer),然后从操作系统的受信任证书机构列表中查找该证书办发机构的公钥,如果找不到,说明这个证书颁发机构是个不受信任的,响应端发过来的信息是不安全的。
    3. 使用上一步取到的证书颁发机构的公钥,解出数字证书,得到响应端的用户信息和数字签名
    4. 发送端通过证书中指定的加密算法对响应端的用户信息进行hash加密
    5. 加密后的结果和证书中解出的数字签名进行对比,如果相同,就说明这份用户信息确实是响应端的,也就是说用户信息中包含的公钥确实是响应端的
    6. 后续响应端使用私钥加密数据,发送端使用公钥解密。
    7. 发送端使用公钥加密,响应端使用私钥解密

    4、ESP加密算法

    4.1、ESP完整性检测

    ESP报文最后有一个验证数据字段,数据验证字段包含完整性校验值 (ICV),也称为消息身份验证码,用于验证消息身份验证与完整性。接收方计算 ICV 值并对照发送方计算的值校验它,以验证完整性。ICV 是通过 ESP 报头、负载数据与 ESP 尾端计算的。

    4.2、ESP防重放

    作为可选功能,ESP还能进行防重放保护。防重放保护验证每个报文是唯一的且没有被复制,这种保护确保黑客不能拦截报文和在数据流中插入改变后的报文。

    防重放的工作原理:

    1. 跟踪报文顺序号并在目的端使用一个滑动窗口。当在源和目的间建立了一条连接时,两端的计数器被初始化为0。
    2. 每次有报文发送时,源给报文追加一个顺序号,目的端使用滑动窗口确定预期的顺序号。目的端验证的报文的顺序号不是复制的,并且以正确的顺序被接收。

    例:

    1、客户端发送ESP封装报文到服务端,序列号为81

    2、服务端响应报文通过ESP加密,响应报文的序列号为81

    3、客户端收到服务端发送的ESP报文后,查看ESP序列号,序列号排序正确则没有重放,排序错误则出现重放。

    4.3、ESP防窃听

    ESP通过3DES、DES、AES机密算法加密数据,做到防窃听功能

    5、IPSec工作原理

    ESP有两种模式:隧道模式和传输模式。

    隧道模式将发送的整个数据报文作为一个数据整体来处理,在整段数据前加上新的IP进行传输,不修改原报文。

    对于传输模式而言,需要拆解报文,对原报文的数据部分进行处理,加上ESP头部后,再装上原报文的IP部分。

    5.1、传输模式

    ESP处理流程:

    1、  将原IP报文的IP头和数据报文部分分离,在数据报文部分的尾部添加ESP尾部。ESP尾部包含:选择的加密算法需要对明文进行填充的数据Padding、填充长度Padding Length、下一头部Next Header标注被加密的数据报文类型,例如TCP协议。

    2、  对第一步得到的整体信息(原数据报文和ESP尾部)进行加密。具体的加密算法以及密钥由SA给出。

    3、对第二步得到的已经加密的信息添加ESP头部(SPI和序列号),组装成Enchilada。

    4、对第三步得到的Enchilada做摘要,得到完整性度量结果(ICV),附加在Enchilada尾部

    5、在第四步得到的数据前加上原IP头,将原IP头中的Protocol中的值改成50,代表ESP

    5.2、隧道模式

    ESP处理流程:

    1. 在原IP报文末尾添加尾部(ESP trailer)信息。如上图所示,尾部包含三部分。由所选加密算法可能是块加密,那么当最后一块长度不够时就需要进行填充(padding),附上填充长度(Pad length)方便解包时顺利找出用来填充的那一段数据。而Next header则用来标明被加密的数据报文的类型,例如TCP协议。 

    2. 将原IP报文以及第1步得到的ESP尾部作为一个整体进行加密。具体的加密算法与密钥由SA给出。

    3. 为第2步得到的加密数据添加ESP头部。如上图所示,ESP头由两部分组成,SPI和序号(Sequence number)。加密数据与ESP头合称为“enchilada”。 

    4. 附加完整性度量结果(ICV,Integrity check value)。对第三步得到的“enchilada”做摘要,得到一个完整性度量值,并附在ESP报文的尾部。

    5. 加上新的IP头。新构造的IP头附在ESP报文的前面组成一个新的IP报文。注意这个新的IP头的目的地址跟源地址可以不一样。协议类型为50,说明它里面装的是一个IPsec报文。

    1. IPSec协商模式

    IPSec建立分为两个阶段,第一接端为IKE协商,第二阶段为IPSec协商。

    6.1、主动模式

    6.1.1、Ikev1协商

    包1:发起端协商SA,使用的是UDP协议,端口号是500,上层协议是ISAKMP,该协议提供的是一个框架,里面的负载Next payload类似模块,可以自由使用。可以看到发起端提供了自己的cookie值,以及SA的加密套件,加密套件主要是加密算法,哈希算法,认证算法,生存时间等。

    • Initiator SPI:b0b5887b632a532b

    发起者的SPI值,告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

    • Responder SPI:

    响应者的SPI值,第一个包只有发起者没有响应者所以响应者的SPI为空

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Identity Protection (Main Mode) (2)

     IKE协商模式为主模式

    • IKE Attribute (t=12,l=4): Life-Duration: 86400

    密钥周期86400,密钥周期超过86400后会重新协商IKE

    • IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC

    IKE使用DES-CBC加密算法加密数据

    • IKE Attribute (t=2,l=2): Hash-Algorithm: MD5

    IKE使用MD5算法校验数据完整性

    • IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key

    使用预共享密钥认证

    • IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group

    Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度。

    包2:响应端收到发送端发送的加密套件后,对比自己是否有相对应的加密套件,如果有就使用和发送端相同的加密套件加密数据,把自己的cookie值和选择好的加密套件发送给发送端;如果没有相同加密套件则IKE建立失败响应。

    • Initiator SPI:b0b5887b632a532b

    发送端的SPI值,告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

    • Responder SPI:e5dd838c8d5138b9

    响应者的SPI值,告知发送端使用哪一把密钥加密数据包

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Identity Protection (Main Mode) (2)

     IKE协商模式为主模式

    • IKE Attribute (t=12,l=4): Life-Duration: 86400

    密钥周期86400,密钥周期超过86400后会重新协商IKE

    • IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC

    IKE使用DES-CBC加密算法加密数据

    • IKE Attribute (t=2,l=2): Hash-Algorithm: MD5

    IKE使用MD5算法校验数据完整性

    • IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key

    使用预共享密钥认证

    • IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group

    Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度。

    包3:发送端生成随机数和DH公共值,包3的主要目的是向响应端发送自己的DH公共值和Nonce随机数。用于生成加密时所需要的KEY值。

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Identity Protection (Main Mode) (2)

     IKE协商模式为主模式

    • Key Exchange Data: aba538345be9d5bfa1dff1e169b2db2a72d3771038f4cc8e...

    DH公共值,DH公共值通过Diffie-Hellman算法计算出来;在包1和包2中所协商的算法,它们必须需要一个相同的KEY(即,共享密钥中设置的密码),但同时这个KEY不能在链路中传递。所以,该过程的目的是分别在两个对等体间独立地生成一个DH公共值,然后在报文中发送给对端,对端通过公式计算出相同的KEY值

    包4:响应端收到包3后,自己生成一个随机数,然后通过Diffie-Hellman算法计算出DH公共值,把随机数和DH公共值传输给发送端。

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Identity Protection (Main Mode) (2)

     IKE协商模式为主模式

    • Key Exchange Data:74d204991cd082a20289989380d3b953e1505fc21af6bafc...

    DH公共值,用于生成加密时所需要的KEY值

    包5:发起方发起身份验证,报文中带有认证的数据(预共享密钥或者数字签名)。由于包1和包2已经协商好了加密算法,包3和包4协商好了加密的KEY值,所以包5的消息被加密了。

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Identity Protection (Main Mode) (2)

     IKE协商模式为主模式

    包6:响应端回应报文,同样发送认证的数据(预共享密钥或者数字签名),验证对方身份信息。包6的数据同样使用包1、包2协商的算法和包3、包4协商的key值加密数据,所以包6的认证数据是加密的。双方身份验证通过后,IKE协商结束。

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Identity Protection (Main Mode) (2)

     IKE协商模式为主模式

    6.1.2、IPSec加密协商

    包7:发起方主要是进行IPSEC SA的协商,建立安全联盟,报文内容主要是协商用的封装方式以及后面的加密算法以及生存时间和感兴趣流等等。由于数据加密所以无法查看。

    • Initiator SPI:b0b5887b632a532b

    发起者的SPI值是由上阶段IKE协商时已经确定的,所以IPSec协商依然使用上阶段的SPI

    • Responder SPI:e5dd838c8d5138b9

    响应者的SPI值是由上阶段IKE协商时已经确定的,所以IPSec协商依然使用上阶段的SPI

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Quick Mode(32)

    交换类型使用快速模式,IPSec协商时只有快速模式

    包8:响应方回包,同意包7发送的封装方式、加密算法、生存时间、感兴趣流等等,同时,也能起到确认收到对端消息的作用。由于数据加密所以无法查看。

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Quick Mode(32)

    交换类型使用快速模式,IPSec协商时只有快速模式

    包9:发送确认报文。其中包含一个HASH,其作用是确认接收方的消息以及证明发送方处于主动状态(表示发送方的第一条消息不是伪造的)。由于数据加密所以无法查看。

    • Version:1.0

    IKE版本号,1.0表示使用ikev1建立连接

    • Exchange type:Quick Mode(32)

    交换类型使用快速模式,IPSec协商时只有快速模式

    6.2、野蛮模式

    野蛮模式使用3个报文进行交换加密方式等消息

    1. 发起端协商SA,发起端提供了自己的cookie值,以及SA的传输集
    2. 响应端收到后,会将自己的sa协商消息附上签名认证信息后发回给sa的发起者
    3. 发起端发送自己的数字签名认证等信息

    野蛮模式无论是共享密钥认证还是证书认证都支持NAT穿越

    7、IPsec穿越NAT

    7.1、IPSec穿越NAT遇到的问题

    1、穿越NAT后的身份确认问题

    IPSec VPN中标准身份标识是IP地址,NAT处理过程中会改变IP地址,因此IPSec的身份确认机制必须能够适应IP地址变化;

    解决此问题的方法主要有两种:第一种是使用数字证书替代IP地址作为身份标识,第二种是使用字符串取代IP地址作为身份标识。

    2、IP地址复用

    IPSec由AH和ESP两个协议组成。

    因为AH对数据进行完整性检查,会对包括IP地址在内的整个IP包进行Hash运算。而NAT会改变IP地址,从而破坏AH的Hash值。因此AH报文无法通过NAT网关。

    ESP对数据进行完整性检查,不包括外部的IP头,IP地址转换不会破坏ESP的Hash值。但ESP报文中TCP的端口已经加密无法修改,所以对于同时转换端口的NAT来说,ESP没法支持。

    7.2、IKE身份确认及协商

    IPSec的身份确认最常见是通过IKE协议代劳,IKE支持的身份认证机制有两种:

     

    1、数字证书方式,通过CA数字证书体系确认身份,是最为安全、可靠的方式。

    2、身份标识+预共享密钥方式,通过发起方和响应方预先配置相同的密钥,如bigtree,完成双方对彼此身份的认证,这是最为常见的方式;在预共享秘密钥认证机制中,身份标识则可以分为几类:

    a> 指定IP地址,使用IP地址作为身份标识,是IKE的默认方式,响应方只允许指定IP地址发起协商,安全性比较高;

    认证成功:

    认证失败:

    b> 指定IP地址范围,这种方式依然使用IP地址作为身份标识,由于发起方必须要指定IP地址,否则无法发起协商,指定IP地址范围是响应方特性,如响应方可以指定2.0.0.0/8范围内的地址都可以发起协商,而不是只允许2.1.1.2发起协商,能够减少配置,但安全性略有下降;

    认证成功:

    认证失败:

    c> 什么都不指定,也是使用IP地址作为身份标识,但允许任意IP地址发起协商,只要预共享密钥一致,双方就能够通过身份确认,这种方式虽然不是非常安全,但是可以简化配置,安全性再次下降;

    认证成功:

    认证失败:

    d> 指定对端名字,发起方和响应方都预先配置好本端名字,使用该名字作为身份标识,与指定IP地址类似,通过指定对端名字方式,即使双方预共享密钥一致,只要对端名字不合法,立即中断协商,由于名字未与IP地址进行绑定,而且名字在网络中明文传递,故安全性不如指定IP地址方式高,但这种身份标识方式可以穿越NAT。

    认证成功:

    认证失败:

    7.3、穿越NAT原理抓包解释

    1. 开启NAT穿越时,IKEv1协商第一阶段的前两个消息会发送标识NAT穿越(NAT Traversal,简称NAT-T)能力的Vendor ID载荷(主模式和野蛮模式都是)。用于检查通信双方是否支持NAT-T。

    当双方都在各自的消息中包含了该载荷时,才会进行相关的NAT-T协商。

    2. 主模式消息3和消息4(野蛮模式消息2和消息3)中发送NAT-D(NAT Discovery)载荷。NAT-D载荷用于探测两个要建立IPSec隧道的网关之间是否存在NAT网关以及NAT网关的位置。

    通过协商双方向对端发送源和目的的IP地址与端口的Hash值,就可以检测到地址和端口在传输过程中是否发生变化。若果协商双方计算出来的Hash值与它收到的Hash值一样,则表示它们之间没有NAT。否则,则说明传输过程中对IP或端口进行了NAT转换。

    第一个NAT-D载荷为对端IP和端口的Hash值,第二个NAT-D载荷为本端IP和端口的Hash值。

    3. 发现NAT网关后,后续ISAKMP消息(主模式从消息5、野蛮模式从消息3开始)的端口号转换为4500。ISAKMP报文标识了“Non-ESP Marker”。

    4. 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPSec报文封装模式:UDP封装隧道模式报文(UDP-Encapsulated-Tunnel)和UDP封装传输模式报文(UDP-Encapsulated-Transport)通过为ESP报文封装UDP头,当封装后的报文通过NAT设备时,NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。

    展开全文
  • Linux内核2.6.x ...在WAN侧抓包偶尔会出现内网IP的TCP的RST、FIN报文 在iptables规则中添加 iptables -I FORWARD -p tcp -m state --state INVALID -j DROP 参考: ...

    Linux内核2.6.x


    在WAN侧抓包偶尔会出现内网IP的TCP的RST、FIN报文


    在iptables规则中添加

    iptables -I FORWARD -p tcp -m state --state INVALID -j DROP






    参考:

    http://ubuntuforums.org/showthread.php?t=1689959

    http://bugzilla.netfilter.org/show_bug.cgi?id=693

    http://bugzilla.netfilter.org/show_bug.cgi?id=627

    展开全文
  • 导读:这一部分将展示如何使用 iptables/nftables 报文跟踪功能来定位 NAT 相关的连接问题。本文字数:7648,阅读时长大约:10分钟https://linux.cn/...

     

    导读:这一部分将展示如何使用 iptables/nftables 报文跟踪功能来定位 NAT 相关的连接问题。

    本文字数:7648,阅读时长大约:10分钟

    https://linux.cn/article-13364-1.html
    作者:Florian Westphal
    译者:cooljelly

    这是有关网络地址转换(network address translation)(NAT)的系列文章中的第一篇。这一部分将展示如何使用 iptables/nftables 报文跟踪功能来定位 NAT 相关的连接问题。

    引言

    网络地址转换(NAT)是一种将容器或虚拟机暴露在互联网中的一种方式。传入的连接请求将其目标地址改写为另一个地址,随后被路由到容器或虚拟机。相同的技术也可用于负载均衡,即传入的连接被分散到不同的服务器上去。

    当网络地址转换没有按预期工作时,连接请求将失败,会暴露错误的服务,连接最终出现在错误的容器中,或者请求超时,等等。调试此类问题的一种方法是检查传入请求是否与预期或已配置的转换相匹配。

    连接跟踪

    NAT 不仅仅是修改 IP 地址或端口号。例如,在将地址 X 映射到 Y 时,无需添加新规则来执行反向转换。一个被称为 “conntrack” 的 netfilter 系统可以识别已有连接的回复报文。每个连接都在 conntrack 系统中有自己的 NAT 状态。反向转换是自动完成的。

    规则匹配跟踪

    nftables 工具(以及在较小的程度上,iptables)允许针对某个报文检查其处理方式以及该报文匹配规则集合中的哪条规则。为了使用这项特殊的功能,可在合适的位置插入“跟踪规则”。这些规则会选择被跟踪的报文。假设一个来自 IP 地址 C 的主机正在访问一个 IP 地址是 S 以及端口是 P 的服务。我们想知道报文匹配了哪条 NAT 转换规则,系统检查了哪些规则,以及报文是否在哪里被丢弃了。

    由于我们要处理的是传入连接,所以我们将规则添加到 prerouting 钩子上。prerouting 意味着内核尚未决定将报文发往何处。修改目标地址通常会使报文被系统转发,而不是由主机自身处理。

    初始配置

    # nft 'add table inet trace_debug'
    # nft 'add chain inet trace_debug trace_pre { type filter hook prerouting priority -200000; }'
    # nft "insert rule inet trace_debug trace_pre ip saddr $C ip daddr $S tcp dport $P tcp flags syn limit rate 1/second meta nftrace set 1"
    

    第一条规则添加了一张新的规则表,这使得将来删除和调试规则可以更轻松。一句 nft delete table inet trace_debug 命令就可以删除调试期间临时加入表中的所有规则和链。

    第二条规则在系统进行路由选择之前(prerouting 钩子)创建了一个基本钩子,并将其优先级设置为负数,以保证它在连接跟踪流程和 NAT 规则匹配之前被执行。

    然而,唯一最重要的部分是第三条规则的最后一段:meta nftrace set 1。这条规则会使系统记录所有匹配这条规则的报文所关联的事件。为了尽可能高效地查看跟踪信息(提高信噪比),考虑对跟踪的事件增加一个速率限制,以保证其数量处于可管理的范围。一个好的选择是限制每秒钟最多一个报文或一分钟最多一个报文。上述案例记录了所有来自终端 $C 且去往终端 $S 的端口 $P 的所有 SYN 报文和 SYN/ACK 报文。限制速率的配置语句可以防范事件过多导致的洪泛风险。事实上,大多数情况下只记录一个报文就足够了。

    对于 iptables 用户来讲,配置流程是类似的。等价的配置规则类似于:

    # iptables -t raw -I PREROUTING -s $C -d $S -p tcp --tcp-flags SYN SYN  --dport $P  -m limit --limit 1/s -j TRACE
    

    获取跟踪事件

    原生 nft 工具的用户可以直接运行 nft 进入 nft 跟踪模式:

    # nft monitor trace
    

    这条命令会将收到的报文以及所有匹配该报文的规则打印出来(用 CTRL-C 来停止输出):

    trace id f0f627 ip raw prerouting  packet: iif "veth0" ether saddr ..
    

    我们将在下一章详细分析该结果。如果你用的是 iptables,首先通过 iptables –version 命令检查一下已安装的版本。例如:

    # iptables --version
    iptables v1.8.5 (legacy)
    

    (legacy) 意味着被跟踪的事件会被记录到内核的环形缓冲区中。你可以用 dmesg 或 journalctl 命令来查看这些事件。这些调试输出缺少一些信息,但和新工具提供的输出从概念上来讲很类似。你将需要首先查看规则被记录下来的行号,并与活跃的 iptables 规则集合手动关联。如果输出显示 (nf_tables),你可以使用 xtables-monitor 工具:

    # xtables-monitor --trace
    

    如果上述命令仅显示版本号,你仍然需要查看 dmesg/journalctl 的输出。xtables-monitor 工具和 nft 监控跟踪工具使用相同的内核接口。它们之间唯一的不同点就是,xtables-monitor 工具会用 iptables 的语法打印事件,且如果你同时使用了 iptables-nft 和 nft,它将不能打印那些使用了 maps/sets 或其他只有 nftables 才支持的功能的规则。

    示例

    我们假设需要调试一个到虚拟机/容器的端口不通的问题。ssh -p 1222 10.1.2.3 命令应该可以远程连接那台服务器上的某个容器,但连接请求超时了。

    你拥有运行那台容器的主机的登录权限。现在登录该机器并增加一条跟踪规则。可通过前述案例查看如何增加一个临时的调试规则表。跟踪规则类似于这样:

    nft "insert rule inet trace_debug trace_pre ip daddr 10.1.2.3 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1"
    

    在添加完上述规则后,运行 nft monitor trace,在跟踪模式下启动 nft,然后重试刚才失败的 ssh 命令。如果规则集较大,会出现大量的输出。不用担心这些输出,下一节我们会做逐行分析。

    trace id 9c01f8 inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn
    trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)
    trace id 9c01f8 inet trace_debug trace_pre verdict continue
    trace id 9c01f8 inet trace_debug trace_pre policy accept
    trace id 9c01f8 inet nat prerouting packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp  tcp dport 1222 tcp flags == syn
    trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)
    trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200
    trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)
    trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)
    trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn
    

    对跟踪结果作逐行分析

    输出结果的第一行是触发后续输出的报文编号。这一行的语法与 nft 规则语法相同,同时还包括了接收报文的首部字段信息。你也可以在这一行找到接收报文的接口名称(此处为 enp0)、报文的源和目的 MAC 地址、报文的源 IP 地址(可能很重要 - 报告问题的人可能选择了一个错误的或非预期的主机),以及 TCP 的源和目的端口。同时你也可以在这一行的开头看到一个“跟踪编号”。该编号标识了匹配跟踪规则的特定报文。第二行包括了该报文匹配的第一条跟踪规则:

    trace id 9c01f8 inet trace_debug trace_pre rule ip daddr 10.2.1.2 tcp dport 1222 tcp flags syn limit rate 6/minute meta nftrace set 1 (verdict continue)
    

    这就是刚添加的跟踪规则。这里显示的第一条规则总是激活报文跟踪的规则。如果在这之前还有其他规则,它们将不会在这里显示。如果没有任何跟踪输出结果,说明没有抵达这条跟踪规则,或者没有匹配成功。下面的两行表明没有后续的匹配规则,且 trace_pre 钩子允许报文继续传输(判定为接受)。

    下一条匹配规则是:

    trace id 9c01f8 inet nat prerouting rule ip daddr 10.1.2.3  tcp dport 1222 dnat ip to 192.168.70.10:22 (verdict accept)
    

    这条 DNAT 规则设置了一个到其他地址和端口的映射。规则中的参数 192.168.70.10 是需要收包的虚拟机的地址,目前为止没有问题。如果它不是正确的虚拟机地址,说明地址输入错误,或者匹配了错误的 NAT 规则。

    IP 转发

    通过下面的输出我们可以看到,IP 路由引擎告诉 IP 协议栈,该报文需要被转发到另一个主机:

    trace id 9c01f8 inet filter forward packet: iif "enp0" oif "veth21" ether saddr .. ip daddr 192.168.70.10 .. tcp dport 22 tcp flags == syn tcp window 29200
    

    这是接收到的报文的另一种呈现形式,但和之前相比有一些有趣的不同。现在的结果有了一个输出接口集合。这在之前不存在的,因为之前的规则是在路由决策之前(prerouting 钩子)。跟踪编号和之前一样,因此仍然是相同的报文,但目标地址和端口已经被修改。假设现在还有匹配 tcp dport 1222 的规则,它们将不会对现阶段的报文产生任何影响了。

    如果该行不包含输出接口(oif),说明路由决策将报文路由到了本机。对路由过程的调试属于另外一个主题,本文不再涉及。

    trace id 9c01f8 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)
    

    这条输出表明,报文匹配到了一个跳转到 allowed_dnats 链的规则。下一行则说明了连接失败的根本原因:

    trace id 9c01f8 inet filter allowed_dnats rule drop (verdict drop)
    

    这条规则无条件地将报文丢弃,因此后续没有关于该报文的日志输出。下一行则是另一个报文的输出结果了:

    trace id 20a4ef inet trace_debug trace_pre packet: iif "enp0" ether saddr .. ip saddr 10.2.1.2 ip daddr 10.1.2.3 ip protocol tcp tcp dport 1222 tcp flags == syn
    

    跟踪编号已经和之前不一样,然后报文的内容却和之前是一样的。这是一个重传尝试:第一个报文被丢弃了,因此 TCP 尝试了重传。可以忽略掉剩余的输出结果了,因为它并没有提供新的信息。现在是时候检查那条链了。

    规则集合分析

    上一节我们发现报文在 inet 过滤表中的一个名叫 allowed_dnats 的链中被丢弃。现在我们来查看它:

    # nft list chain inet filter allowed_dnats
    table inet filter {
     chain allowed_dnats {
      meta nfproto ipv4 ip daddr . tcp dport @allow_in accept
      drop
       }
    }
    

    接受 @allow_in 集的数据包的规则没有显示在跟踪日志中。我们通过列出元素的方式,再次检查上述报文的目标地址是否在 @allow_in 集中:

    # nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
    Error: Could not process rule: No such file or directory
    

    不出所料,地址-服务对并没有出现在集合中。我们将其添加到集合中。

    # nft "add element inet filter allow_in { 192.168.70.10 . 22 }"
    

    现在运行查询命令,它将返回新添加的元素。

    # nft "get element inet filter allow_in { 192.168.70.10 . 22 }"
    table inet filter {
       set allow_in {
          type ipv4_addr . inet_service
          elements = { 192.168.70.10 . 22 }
       }
    }
    

    ssh 命令现在应该可以工作,且跟踪结果可以反映出该变化:

    trace id 497abf58 inet filter forward rule ct status dnat jump allowed_dnats (verdict jump allowed_dnats)
    
    trace id 497abf58 inet filter allowed_dnats rule meta nfproto ipv4 ip daddr . tcp dport @allow_in accept (verdict accept)
    
    trace id 497abf58 ip postrouting packet: iif "enp0" oif "veth21" ether .. trace id 497abf58 ip postrouting policy accept
    

    这表明报文通过了转发路径中的最后一个钩子 - postrouting

    如果现在仍然无法连接,问题可能处在报文流程的后续阶段,有可能并不在 nftables 的规则集合范围之内。

    总结

    本文介绍了如何通过 nftables 的跟踪机制检查丢包或其他类型的连接问题。本系列的下一篇文章将展示如何检查连接跟踪系统和可能与连接跟踪流相关的 NAT 信息。


    via: https://fedoramagazine.org/network-address-translation-part-1-packet-tracing/

    作者:Florian Westphal 选题:lujun9972 译者:cooljelly 校对:wxy

    本文由 LCTT 原创编译,Linux中国 荣誉推出


    欢迎遵照 CC-BY-NC-SA 协议规定转载,

    如需转载,请在文章下留言 “转载:公众号名称”,

    我们将为您添加白名单,授权“转载文章时可以修改”。

    展开全文
  • 在搭建NSX环境的过程,起先没有在Edge路由器上设置NAT,导致VM无法访问外网。经查阅资料后发现,需要配置NAT,配置完SNAT后,比较疑惑的是没有配置DNAT,响应包是怎么把数据包中目的...
  • NAT64与DNS64的报文交互

    千次阅读 2018-05-16 09:38:07
    DNS64Server与NAT64Router是完全独立的部分。其中64:FF9B::/96为DNS64的知名前缀,DNS64一般默认使用此前缀进行IPv4地址到IPv6地址的合成,同时该前缀也作为NAT64的转换前缀,实现匹配该前缀的流量才做NAT64转换。...
  • FTP协议报文详解及FTP穿越NAT

    万次阅读 多人点赞 2019-04-04 15:16:36
    目录 1、拓扑图 2、FTP协议简介 3、FTP工作原理 3.1、主动连接(PORT) 3.2、被动连接(PASV) 3.3、FTP主动模式穿越SNAT原理 3.4、FTP被动模式穿越DNAT原理 4、问题思考 ...4.4、思考NAT设备如...
  • H3C防火墙NAT类型及处理顺序

    万次阅读 2019-04-19 15:34:22
    H3C防火墙NAT处理顺序 本文主要适用于H3C V7版本防火墙,介绍了NAT的基本类型和执行顺序。...报文经过NAT设备时,在NAT接口上仅进行一次源IP地址转换或一次目的IP地址转换。对于内网访问外网的报文,在出...
  • mangle表的PREROUTING链添加mark规则,nat的PREROUTING链添加match规则,打几个流过后发现nat表里没有匹配上的报文。 规则如下: mangle表的PREROUTING链 ``` iptables -t mangle -A PREROUTING -j MARK --...
  • NAT

    2021-03-11 19:36:45
    一、NAT类型 根据转化方式的不同,NAT可以分为三类: ...源NAT是指对报文中的源地址进行转换。通过源NAT技术将私网IP地址转换成公网IP地址,使私网用户可以利用公网地址访问Internet。 1、NO—PA...
  • 简介 IP(网际互连协议,Internet Protocol)是...报文格式 IP报文格式 版本:占4位,指IP协议的版本。通信双方使用的IP协议的版本必须一致。目前广泛使用的IP协议版本号为4(即IPv4),以后要使用IPv6(即版本6的I
  • NAT(地址转换技术)详解

    万次阅读 多人点赞 2018-03-17 16:31:35
    NAT产生背景 ip地址基础知识 NAT技术的工作原理和特点 静态NAT 动态NAT NAT重载(经常应用到实际中) NAT技术的优缺点 优点 缺点 NAT穿越技术 应用层网关(ALG) ALG的实际应用 NAT技术的未来 参考文献 ...
  • teredo报文格式

    千次阅读 2016-06-27 19:18:46
    teredo报文是一项 IPv6 / IPv4 过渡技术,为能够通过 IPv4 NAT, IPv6 数据包作为基于 IPv4 的用户数据包协议(UDP) 消息发送出去。格式如下:注意,外层为V4报文,内层为V6报文,V4报文后的UDP报文的目的端口为3544...
  • Nat 对 tcp , udp , icmp 报文的处理

    千次阅读 2010-02-03 15:02:00
    的路由器记下了这个报文的端口之类的信息,那这个记录什么时候删除?   TCP : nat 删除记录有一个 timeout 值,这个值可以设置,一次 tcp 建立...
  • ○ 主机或路由器使用ICMP来发送差错报告报文和询问报文 ○ ICMP报文被封装在IP数据报中发送 ○ ICMP差错报告报文共有以下五种: ① 终点不可达 ② 源点抑制 ③ 时间超过 ④ 参数问题 ⑤ 改变路由(重定向) ○ ...
  • 华为防火墙双向NAT

    千次阅读 2019-09-19 10:32:30
    NAT根据报文在防火墙上的流动方向进行分类:域间NAT、域内NAT 域间NAT报文两个不同的安全区域之间流动时对报文进行NAT转换 根据流动方向的不同又可以分为 NAT Inbound:报文由低安全级别的安全区域向高...
  • 文章目录出现原因基本概念NAT技术基本原理源NAT技术静态NAT动态NATNAPTEasy IPNAT ALGNAT服务器双向NAT技术域间双向NATNAT Server+源NAT)域内双向NAT 出现原因 由于互联网快速发展,以及IPv4地址规划不合理的问题...
  • STU1.1 Full cone NAT(全锥形NAT)1.2 Restricted Cone NAT(地址受限锥形NAT)1.3 Port Restricted Cone NAT(端口受限锥形NAT)1.4 Symetric NAT(对称NAT)2.小结 参考文献: [1]...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 24,969
精华内容 9,987
关键字:

nat报文