linux防火墙需要指定协议类型么

Linux防火墙是由Netfilter组件提供的，Netfilter工作在内核空间，集成在linux内核中

Netfilter采用模块化设计，具有良好的可扩充性，提供扩展各种网络服务的结构化底层框架。Netfilter与IP协议栈是无缝契合，并允许对数据报进行过滤、地址转换、处理等 *** 作

一、Linux防火墙基础

Linux 的防火墙体系主要工作在网络层，针对 TCP/IP 数据包实施过滤和限制，属于典型的包过滤防火墙（或称为网络层防火墙）。

体现在对包内的 IP 地址、端口等信息的处理上

Linux 系统的防火墙基于内核编码实现，具有非常稳定的性能和极高的效率，也因此获得广泛的应用

防火墙区域（zone）

过滤规则集合：zone

一个zone一套过滤规则，数据包经过某个zone进出站，不同zone规则不同，fierwalld将网卡对应到不同zone，默认9个区域（CentOS系统默认区域为public），有优先级，高优先级可以到优先级，低优先级到优先级需做规则过滤

区域

public（公共）

dmz（非军事区）：内外网之间的一层网络区域，主要管理内网到外网的安全限制/访问规则

trusted（信任）

1.防火墙工具介绍

netfilter/iptables:IP信息包过滤系统，它实际上由两个组件 netfilter_和 iptables组成。主要工作在网络层，针对IP数据包，体现在对包内的IP地址、端口等信息的处理。

1.iptables

iptables是一种用来管理Linux防火墙的命令程序，它使插入、修改和删除数据包过滤表中的规则变得容易，通常位于/sbin/iptables目录，属于“用户态”(User. Space，又称为用户空间) 的防火墙管理体系。

iptables是基于内核的防火墙，其中内置了raw、mangle、 nat和filter四个规则表。表中所有规则配置后，立即生效，不需要重启服务。

核心意义：控制不同网络之间的数据包/流量数据的访问规则/约束

2.netfilter

netfilter是内核的一部分，由一些数据包过滤表组成，不以程序文或文件的形式存在，这些表包含内核用来控制数据包过滤处理的规则集，属于“内核态”(Kernel Space，又称为内核空间)的防火墙功能体系。

2.iptables的四表五链

iptables的作用是为包过滤机制的实现提供规则（或称为策略），通过各种不同的规则，告诉 netfilter 对来自某些源、前往某些目的或具有某些协议特征的数据包应该如何处理

iptables采用了表和链的分层结构，所以它会对请求的数据包的包头数据进行分析，根据我们预先设定的规则进行匹配来决定是否可以进入主机。

其中，每个规则表相当于内核空间的一个容器，根据规则集的不同用途划分为默认的四个表，在每个表容器内又包括不同的规则链，根据处理数据包的不同时机划分为五种链

表为处理动作（ *** 作指令）

链为具体位置

1.规则表

表的作用：容纳各种规则链

表的划分依据：防火墙规则的作用相似

1.4个规则表

raw表：确定是否对该数据包进行状态跟踪

mangle表：为数据包设置标记

nat表：修改数据包中的源、目标IP地址或端口

filter表（默认表）：确认是否放行该数据包（过滤）（核心）

2.规则链

**规则的作用：**对数据包进行过滤或处理

**链的作用：**容纳各种防火墙规则

**链的分类依据：**处理数据包的不同时机

1.5种规则链

INPUT: 处理入站数据包，匹配目标IP为本机的数据包

OUTPUT: 处理出站数据包，一般不在此链上做配置

FORWARD: 处理转发数据包，匹配流经本机的数据包

PREROUTING链: 在进行路由选择前处理数据包，用来修改目的地址，用来做DNAT。相当于把内网服务器的IP和端口映射到路由器的外网IP和端口上

POSTROUTING链: 在进行路由选择后处理数据包，用来修改源地址，用来做SNAT。相当于内网通过路由器NAT转换功能实现内网主机通过一个公网IP地址上网

3.默认表、链的结构示意图

在这里插入图片描述

在iptables 的四个规则表中，mangle 表 和raw表的应用相对较少

在iptables 的五个规则链中，一般用input比较多（限制进入），output用的比较少，forward一般用在代理服务器上

4.数据包过滤的匹配流程

1.规则表之间的顺序

raw ---->mangle ---->nat ---->filter

2.规则链之间的顺序

入站：PREROUTING->INPUT

来自外界的数据包到达防火墙后，首先被 PEROUTING 链处理（是否修改数据包地址等），然后进行路由选择（判断该数据包应该发往何处）；如果数据包的目标地址是防火墙本机，那么内核将其传递给 INPUT 链进行处理（决定是否允许通过），通过后再交给系统上层的应用程序进行相应 *** 作

出站：OUTPUT->POSTROUTING

防火墙本机向外部地址发送数据包，首先被 OUTPUT 链处理，然后进行路由选择，再交给 POSTROUTING 链进行处理（是否修改数据包的地址等）

转发：PREROUTING->FORWARD->POSTROUTING

来自外界的数据包到达防火墙后，首先被 PREOUTING 链处理，然后再进行路由选择；如果数据包的目标地址是其他外部地址，则内核将其传递给 FORWARD 链进行处理（允许转发、拦截或丢弃），最后交给 POSTROUTING 链进行处理（是否修改数据包的地址等）

3.规则链内的匹配顺序

按顺序一次检查，匹配即停止（LOG策略例外）

若找不倒相匹配的规则，则按该链的默认策略处理

在这里插入图片描述

在进行TCP的代理时，只要在NET表上无脑进行REDIRECT就好了。例如使用ss-redir,你只要把tcp的流量redirect到ss-redir监听的端口上就OK了。但是当你使用这种方法的时候，就会不正常，因为对于UDP进行redirect之后，原始的目的地址和端口就找不到了。

这是为什么呢？

ss-redir的原理很简单：使用iptables对PREROUTING与OUTPUT的TCP/UDP流量进行REDIRECT（REDIRECT是DNAT的特例），ss—redir在捕获网络流量后，通过一些技术手段获取REDIRECT之前的目的地址（dst）与端口（port），连同网络流量一起转发至远程服务器。

针对TCP连接，的确是因为Linux Kernel连接跟踪机制的实现才使获取数据包原本的dst和port成为可能，但这种连接跟踪机制并非只存在于TCP连接中，UDP连接同样存在，conntrack -p udp便能看到UDP的连接跟踪记录。内核中有关TCP与UDP的NAT源码/net/netfilter/nf_nat_proto_tcp.c和/net/netfilter/nf_nat_proto_udp.c几乎一模一样，都是根据NAT的类型做SNAT或DNAT。

那这究竟是怎么一回事？为什么对于UDP连接就失效了呢？

回过头来看看ss-redir有关获取TCP原本的dst和port的源码，核心函数是getdestaddr：

在内核源码中搜了下有关SO_ORIGINAL_DST的东西，看到了getorigdst：

We only do TCP and SCTP at the moment。Oh，shit！只针对TCP与SCTP才能这么做，并非技术上不可行，只是人为地阻止罢了。

为了在redirect UDP后还能够获取原本的dst和port，ss-redir采用了TPROXY。Linux系统有关TPROXY的设置是以下三条命令：

大意就是在mangle表的PREROUTING中为每个UDP数据包打上0x2333/0x2333标志，之后在路由选择中将具有0x2333/0x2333标志的数据包投递到本地环回设备上的1080端口；对监听0.0.0.0地址的1080端口的socket启用IP_TRANSPARENT标志，使IPv4路由能够将非本机的数据报投递到传输层，传递给监听1080端口的ss-redir。IP_RECVORIGDSTADDR与IPV6_RECVORIGDSTADDR则表示获取送达数据包的dst与port。

可问题来了：要知道mangle表并不会修改数据包，那么TPROXY是如何做到在不修改数据包的前提下将非本机dst的数据包投递到换回设备上的1080端口呢？

这个问题在内核中时如何实现的，还待研究，但是确定是TPROXY做了某些工作。

TPROXY主要功能：

TPROXY要解决的两个重要的问题

参考：

https://blog.csdn.net/ts__cf/article/details/78942294

https://vvl.me/2018/06/09/from-ss-redir-to-linux-nat/

---