网络代理方法及相关设备

技术领域

本发明涉及网络通信领域，尤其涉及一种网络代理方法及相关设备。

背景技术

当前网络代理方式中，多数代理采用了全局代理的方式,而全局代理的方式不够灵活,意味着全局仅能使用一个代理。还有一些网络代理方式是基于特征IP地址进行网络配置,那么对于非固定IP来说,每次网络连接,都要重新记录分配的IP,在IP频繁变更的情况下，需要不断调整规则，增加了不稳定。并且当前很多代理程序实现代理域名的方式都不同,缺乏统一的方法来管理。

发明内容

鉴于上述问题，本发明实施例提供一种网络代理方法及相关设备，能够解决网络代理方式不够灵活、对于非固定ip的网络请求网络代理的稳定性差且难以统一管理的问题。

为解决上述至少一种技术问题，第一方面，本发明提供了一种网络代理方法，该方法包括：

获取目标网络数据包来源信息，其中，所述来源信息包括实体端口信息和虚拟接口信息；

基于目标网络数据包的来源信息对网络数据包进行分类标记；

根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。

可选的，所述获取目标网络数据包来源信息，包括：

在所述目标网络数据包来自实体端口的情况下，通过DSA模式获取目标网络数据包来源的实体端口信息。

可选的，所述方法还包括：

通过无线设备管理工具iw虚拟化出至少一个iw虚拟接口；

在所述目标网络数据包是基于无线传输的情况下，通过所述iw虚拟接口接收所述目标网络数据包；

所述获取目标网络数据包来源信息，包括：

获取目标网络数据包来源的iw虚拟接口信息。

可选的，所述基于目标网络数据包的来源信息对网络数据包进行分类标记，包括：

使用ebtables桥接工具基于目标网络数据包的来源信息对网络数据包进行分类标记。

可选的，所述方法还包括：

通过iptables工具为基于来源信息分类后的目标网络数据包添加标识信息，以管理网络数据包的过滤规则。

可选的，所述方法还包括：

在识别到所述目标网络数据包来源为DNS查询端口的情况下，使用nfqueue工具对所述目标网络数据包进行处理。

可选的，所述在识别到所述目标网络数据包来源为DNS查询端口的情况下，使用nfqueue工具对所述目标网络数据包进行处理，包括：

在所述目标网络数据的来源信息为UDP53端口的情况下，使用nfqueue工具提取DNS消息，以基于DNS消息生成动态代理决策。

可选的，所述方法还包括：

创建ipset集合，所述ipset集合用于存储需要通过代理处理的目标地址；

通过iptables工具为确认需要代理的目标网络数据包添加初步确认代理标记，以避免目标网络数据包再次被捕获并发送回nfqueue形成回环情况；将标记有初步确认代理标记的目标网络数据再发次送回iptables，以通过iptables添加最终确认代理标记；

在目标网络数据包的目标地址在ipset集合中的情况下，则为所述目标网络数据包添加最终确认代理标记；

在DNS响应返回到本地终端之前，将所述DNS响应转发到nfqueue进行检查，确定是否需要将解析出的IP地址添加到所述ipset集合。

第二方面，本发明实施例还提供了一种网络代理装置，包括：

获取单元，用于获取目标网络数据包来源信息，其中，所述来源信息包括实体端口信息和虚拟接口信息；

分类单元，用于基于目标网络数据包的来源信息对网络数据包进行分类标记；

代理单元，用于根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。

为了实现上述目的，根据本发明的第三方面，提供了一种计算机可读存储介质，上述计算机可读存储介质包括存储的程序，其中，在上述程序被处理器执行时实现上述的网络代理方法。

为了实现上述目的，根据本发明的第四方面，提供了一种电子设备，包括至少一个处理器、以及与上述处理器连接的至少一个存储器；其中，上述处理器用于调用上述存储器中的程序指令，执行上述的网络代理方法。

借由上述技术方案，本发明实施例提供的网络代理方法，通过获取目标网络数据包来源信息，其中，所述来源信息包括实体端口信息和虚拟接口信息。并基于目标网络数据包的来源信息对网络数据包进行分类标记。再根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。由此，通过上述方案实现了一个相对统一的针对不同网络请求的网络代理处理框架，创建了一个统一的流量管理和处理框架，在这个框架内，流量可以被统一捕获、标记、过滤和路由，无论它们来自有线还是无线网络。并将流量管理规则，如哪些流量需要代理、哪些直连等，集中在一处进行判断和处理，简化了网络管理。不需要在每个代理服务器或虚拟专用网络程序中分别设置规则，代理程序或虚拟专用网络只需专注于它们的核心功能，而不必担心流量的选择和路由问题。这种分工明确的模式使得代理和虚拟专用网络更加高效且易于管理，提高了网络代理维护的效率和一致性。

相应地，本发明实施例提供的网络代理装置、电子系统和计算机可读存储介质，也同样具有上述技术效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种网络代理方法的流程示意图；

图2示出了本发明实施例提供的一种网络代理装置的组成示意框图；

图3示出了本发明实施例提供的一种网络代理电子设备的组成示意框图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

可以理解的是，在网络代理中，目前比较常用的全局代理由于是将网络设备或应用程序的所有网络流量都通过一个代理服务器进行转发和处理。虽然全局代理的设置通常适用于需要简单、统一管理网络流量的场景。然而，这种设置方式确实存在灵活性、性能、安全性等问题，例如全局代理使得所有流量都必须通过同一个代理服务器。这意味着无法根据不同的网络请求或应用程序选择最适合的代理服务器。并且当所有流量都通过一个代理服务器时，该服务器可能会因为处理过多的数据而变得拥堵，导致速度减慢和响应时间延迟。尤其在数据密集型应用(如视频流、大型下载)中，这个问题会更加明显。另外，使用单一的代理服务器可能会增加安全风险。如果这个代理服务器被攻击或者出现安全漏洞，那么所有通过这个代理的数据都可能会受到威胁。

在一些情况下，会采用基于IP地址进行配置实现网络代理，然而基于特定IP地址的网络设置(例如固定的白名单或黑名单)。对于动态IP地址(非固定IP)，这样的设置会有问题。动态IP地址是指每次设备连接到网络时都可能获得不同的IP地址。因此，如果安全或访问控制策略是基于特定IP地址设置的，那么这些策略需要不断更新以匹配新的IP地址，这会导致管理变得复杂和不稳定。

在一些情况下，会采用代理程序实现网络代理，一些代理程序可以捕获设备上的网络流量并根据预设规则来转发这些流量。例如，可以将特定的网站或服务的流量重定向到指定的代理服务器。但是，如果Clash根据来源IP地址来决定流量路由，那么在使用动态IP地址(例如大多数家庭宽带或移动网络)的情况下，这种配置可能不够稳定。用户的IP地址可能会频繁变更，导致需要不断调整规则。并且，代理程序的配置和规则不能简单地应用于其他代理程序。比如，一个特定于某个代理程序的配置文件可能不适用于另一个代理软件，因为不同的程序可能有不同的配置语法或支持的功能集，这限制了配置的可移植性和灵活性。特别在网络游戏的流量传输过程中，网络代理的稳定性和灵活性会直接影响到网络游戏的响应速度。

为了解决上述问题，本发明实施例提供了一种网络代理方法，如图1所示，该方法包括：S101至S103。

在S101中，获取目标网络数据包来源信息，其中，上述来源信息包括实体端口信息和虚拟接口信息。

示例性的，网络流量是以网络数据包的形式进行传输的。那么这些网络流量的来源可以根据目标网络数据包来划分为实体端口来源的网络流量和虚拟接口来源的网络流量。上述网络流量可以是网络游戏中需要转发至游戏服务器的网络数据包。

在S102中，基于目标网络数据包的来源信息对网络数据包进行分类标记。

示例性，例如实体端口可以包括lan1和lan2，虚拟接口可以包括wlan1和wlan2。那么可以为来源于lan1的流量设置标记A，来源于lan2的流量设置标记B，来源于wlan1的流量设置标记C，来源于wlan2的流量设置标记D。当然，也可以根据目标网络数据包的来源信息将多个实体端口和/或虚拟接口设置同一标记，以进行合并分类，例如，可以为来源于lan1的流量、来源于lan2的流量以及来源于wlan2的流量设置标记A，而将来源于wlan1的流量设置标记B。

在S103中，根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。

借由上述技术方案，本发明实施例提供的网络代理方法，通过获取目标网络数据包来源信息，其中，所述来源信息包括实体端口信息和虚拟接口信息。并基于目标网络数据包的来源信息对网络数据包进行分类标记。再根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。由此，通过上述方案实现了一个相对统一的针对不同网络请求的网络代理处理框架，创建了一个统一的流量管理和处理框架，在这个框架内，流量可以被统一捕获、标记、过滤和路由，无论它们来自有线还是无线网络。并将流量管理规则，如哪些流量需要代理、哪些直连等，集中在一处进行判断和处理，简化了网络管理。不需要在每个代理服务器或虚拟专用网络程序中分别设置规则，代理程序或虚拟专用网络只需专注于它们的核心功能，而不必担心流量的选择和路由问题。这种分工明确的模式使得代理和虚拟专用网络更加高效且易于管理，提高了网络代理维护的效率和一致性。可用于游戏加速等业务，具有能够降低游戏网络延迟的特点。

在一种实施例中，上述获取目标网络数据包来源信息，可以包括：

在上述目标网络数据包来自实体端口的情况下，通过DSA模式获取目标网络数据包来源的实体端口信息。

可以理解的是，DSA(Distributed Switch Architecture，分布式交换机体系结构)是一种用于管理交换机的网络架构。可以被用来区分通过不同lan端口进入的流量。这意味着，不同物理端口的数据流可以被单独识别和管理，为每个端口提供定制化的网络处理。

在一种实施例中，上述方法还包括：

通过无线设备管理工具iw虚拟化出至少一个iw虚拟接口；

在上述目标网络数据包是基于无线传输的情况下，通过上述iw虚拟接口接收所述目标网络数据包；

上述获取目标网络数据包来源信息，包括：

获取目标网络数据包来源的iw虚拟接口信息。

可以理解的是，iw是管理无线设备的工具。通过虚拟化多个无线接口，可以模拟出多个独立的无线网络设备。这样做可以让单一物理无线硬件表现得就像是多个独立的无线设备，每个设备可以有自己的网络设置和策略。能够实现虚拟化出多个无线接口的功能，这些虚拟接口可以被配置成不同的模式，如管理模式(AP模式)、客户端模式(station模式)、监控模式等。

在一种实施例中，上述基于目标网络数据包的来源信息对网络数据包进行分类标记，可以包括：

使用ebtables桥接工具基于目标网络数据包的来源信息对网络数据包进行分类标记。

需要说明的是，ebtables是用于Linux上桥接的工具，可以对桥接的数据包进行过滤和修改。在这里，它可以被用来对不同的实体端口或虚拟接口的流量打上特定的标记，以便于后续可以根据这些标记对数据流进行区分和特定的处理。

在一些示例中，可以使用DSA和iw技术，配合ebtables,将不同实体端口或虚拟接口的流量打上不同的标记,以下有三个实体端口,分别为lan1、lan2和lan3,两个iw虚拟接口,分别为wlan0和wlan0-1：

4:lan1@eth0:mtu 1500qdisc noqueuemaster br-lan state UP qlen 1000

link/ether d4:da:21:71:61:47brd ff:ff:ff:ff:ff:ff

5:lan2@eth0:mtu 1500qdisc noqueuemaster br-lan state UP qlen 1000

link/ether d4:da:21:71:61:47brd ff:ff:ff:ff:ff:ff

6:lan3@eth0:mtu1500qdisc noqueuemaster br-lan state LOWERLAYERDOWN qlen 1000

link/ether d4:da:21:71:61:47brd ff:ff:ff:ff:ff:ff

16:wlan0:mtu 1500qdisc noqueuestate DOWN qlen 1000

link/ether d4:da:21:71:61:48brd ff:ff:ff:ff:ff:ff

17:wlan0-1:mtu 1500qdisc noqueuestate DOWN qlen 1000

link/ether d6:da:21:71:61:48brd ff:ff:ff:ff:ff:ff

那么可以使用ebtables在Linux桥接过滤表中设置规则，例如，假设要将lan1lan2 wan0使用相同的代理,那么ebtabls配置如下

ebtables-t broute-A BROUTING-i lan1-j mark--set-mark 125；

ebtables-t broute-A BROUTING-i lan2-j mark--set-mark 125；

ebtables-t broute-A BROUTING-i wlan0-j mark--set-mark 125：

目的是捕获从不同实体端口和虚拟接口(lan1,lan2,wlan0)进入的流量，并将这些流量标记为特定的标记，在这个例子中是125。这种标记可以被后续的网络处理系统用来识别和特殊处理这些流量。

在一种实施例中，上述方法还可以包括：

通过iptables工具为基于来源信息分类后的目标网络数据包添加标识信息，以管理网络数据包的过滤规则。

可以理解的是，iptables是Linux中用于管理网络包过滤规则的工具。它可以被用来进一步处理那些已经被ebtables打上标记的网络数据包，例如，通过为它们添加额外的iptables标记来进一步细化流量管理策略，来实现对有线和无线网络流量的精细管理。

在一种实施例中，上述方法还包括：

在识别到上述目标网络数据包来源为DNS查询端口的情况下，使用nfqueue工具对上述目标网络数据包进行处理。

可以理解的是，特殊处理DNS请求可以实现智能域名解析，并且DNS查询容易受到攻击，如DNS污染、劫持或重放攻击等。在某些网络环境中，DNS请求可能会被第三方劫持或污染，导致用户被误导到错误或恶意的网站。使用nfqueue处理DNS端口流量能够允许系统对DNS请求进行更精细的控制，例如基于请求的类型、来源或目标对其进行特殊处理或路由。并且可以基于具体需要(如避免审查、提高解析质量等)定制DNS解析策略。例如，某些请求可以被重定向到更安全、速度更快的DNS服务器。以及可以对DNS请求进行监控和审计，有助于检测和防止恶意软件活动或网络钓鱼等。

在一种实施例中，上述在识别到所述目标网络数据包来源为DNS查询端口的情况下，使用nfqueue工具对上述目标网络数据包进行处理，可以包括：

在上述目标网络数据的来源信息为UDP53端口的情况下，使用nfqueue工具提取DNS消息，以基于DNS消息生成动态代理决策。

示例性的，可以创建IPSet，例如创建一个名为proxy_set的IPSet，用来存储需要特殊处理(如通过代理)的网络地址集合。然后建立新的链new_rule，这个新链可以用于定义具体的处理规则：例如对于目的地址为192.168.0.0/16(本地私有网络地址)的TCP和非53端口的UDP流量，规则使它们直接返回，不进行代理。对于目的地址为192.168.0.0/16，源或目的端口为53，且标记不为456的UDP流量，转发到nfqueue队列用于对DNS查询进行特殊处理。如果目的IP地址存在于proxy_set中，无论是TCP还是UDP，将流量标记为1250。可以使这些流量被标记为通过特定的代理处理。最后，将new_rule链挂载到prerouting，这个规则表示所有标记为125的进入流量都应该被转发到new_rule链进行处理。这个标记可以是之前ebtables规则中设置的，用于将特定接口的流量导入特定处理链。综上，这些规则创建了一个综合的网络处理逻辑，它不仅基于目的IP地址或IPSet内的条目来处理流量，而且能够对特定类型的流量(如DNS请求)做特殊处理。通过nfqueue的使用，可以将流量导入到某个用户空间程序进行更细致的处理，例如动态判断是否需要代理、DNS污染检测等。这种配置的主要优势在于它的灵活性和精确度。可以针对不同来源、目的地和端口的流量应用不同的处理规则，而不是简单地应用全局代理。

示例性的，可以使用nfqueue进行白名单域名的判断：

//代码解析IP数据包以提取UDP数据包

let ip_pkg＝pnet::packet::ipv4::Ipv4Packet::new(payload)；

let udp_pkg＝pnet::packet::udp::UdpPacket::new(ip_pkg.payload())；

//特别检查UDP数据包的目的端口和源端口是否为53(DNS查询的标准端口)

if udp_pkg.get_destination()！＝53&&udp_pkg.get_source()！＝53{

msg.set_verdict(nfq::Verdict::Accept)；

warn！("port is not domain")；

continue；

}

//解析一下域名

let mut decoder＝binary::BinDecoder::new(udp_pkg.payload())；

let dns_message＝op::Message::read(&mut decoder)；

let query_warp＝dns_message.queries().get(0)；

//目标地址是53,说明是DNS查询请求

if udp_pkg.get_destination()＝＝53{

//这里做一下判断是不是需要代理,

if！need_proxy{

//不需要代理的流量直接回收

msg.set_verdict(nfq::Verdict::Accept)；

}else{

//需要的流量打上标记,以便重入的时候不会再次匹配,而是进行后续的匹配

msg.set_nfmark(456)；

//将标记的流量重入

msg.set_verdict(nfq::Verdict::Repeat)；

}

//重入一下

queue.verdict(msg)；

}else if udp_pkg.get_source()＝＝53{

//这里做一下判断是不是需要代理,

if need_proxy{

//将其添加进ipset

process::exec("ipset add proxy_set{}",query_warp.ip)；

}

//不管怎么样都要给客户端

msg.set_verdict(nfq::Verdict::Accept)；

queue.verdict(msg)；

}

根据上述代码，可以理解的是在上述示例中根据UDP数据包的目的端口和源端口，代码区分处理DNS查询请求和响应：如果目的端口是53(即DNS查询请求)：检查是否需要通过代理。如果不需要代理，直接接受(Accept)此数据包。如果需要代理，将数据包标记为456并要求它重入队列(Repeat)，以便进行后续的处理(比如通过代理转发)。如果源端口是53(即DNS响应)：如果查询需要代理，则将对应的IP地址添加到proxy_set(之前在iptables中定义)。无论如何，都接受此数据包，让其返回客户端。这段代码允许根据实际的DNS查询动态决定是否将流量导入代理。这种方式相比静态IP规则更灵活，适应于那些根据域名而非固定IP地址选择代理方式的场景。使用nfqueue来处理和决策网络流量，可以非常精确地控制哪些请求需要代理，但也要注意代码的效率和安全性。不正确的逻辑可能导致性能瓶颈或安全隐患。

在一些示例中，上述方法还可以包括：

创建ipset集合，上述ipset集合用于存储需要通过代理处理的目标地址；

通过iptables工具为确认需要代理的目标网络数据包添加初步确认代理标记，以避免目标网络数据包再次被捕获并发送回nfqueue形成回环情况；将标记有初步确认代理标记的目标网络数据再发次送回iptables，以通过iptables添加最终确认代理标记；

在目标网络数据包的目标地址在ipset集合中的情况下，则为所述目标网络数据包添加最终确认代理标记；

在DNS响应返回到本地终端之前，将上述DNS响应转发到nfqueue进行检查，确定是否需要将解析出的IP地址添加到所述ipset集合。

示例性的，可以结合ebtables、iptables、nfqueue、ipset完成DNS流量的特殊处理，以实现灵活的代理决策，特别是针对域名解析请求。具体的，使用ebtables标记流量，特定端口如lan1,lan2,wlan0等的流量被ebtables标记为125。这一步可以在网络流量进入Linux主机时进行，用于标识需要进一步判断是否代理的流量。可以使用iptables捕获所有被ebtables标记为125的流量，并将它们重定向到nfqueue进行特殊处理。这里的处理可以包括检查数据包的内容，特别是对DNS查询(通常是UDP端口53)进行检测。在nfqueue程序中，流量被分析，尤其是DNS请求，以决定是否需要通过代理。这个决策基于域名、请求类型或其他规则。如果nfqueue程序判断某个流量(特别是某个DNS请求)需要通过代理，则它会被标记为456(相当于初步确认代理标记)并重新进入iptables流程，这次它将被iptables捕获并标记为1250(相当于最终确认代理标记)，意味着这部分流量需要通过代理处理。对于nfqueue程序判断不需要代理的流量，会直接被接受(ACCEPT)，并不会被进一步标记或重定向。标记为1250的流量(即需要通过代理的流量)随后可以被路由到本地的代理程序进行处理，例如进行DNS查询代理或转发到远程代理服务器。由此，提供了高度灵活的流量处理能力，特别是针对DNS流量的智能代理决策。通过结合不同的网络工具和技术，它允许对网络流量进行精细控制，同时还能根据实际内容动态决定是否以及如何进行代理。这种方法特别适用于复杂的网络环境，其中流量需要根据具体内容(如域名)而非仅仅是来源或目的IP地址来路由和处理。

以以下代码为例：

```shell

#创建一个ipset

ipset create proxy_set hash:net

#这里创建一个新的链

iptables-t mangle-N dns_rule_request

#本地的流量不处理,除非是dns请求的流量

iptables-t mangle-A dns_rule_request-d 192.168.0.0/16-p tcp-jRETURNiptables-t mangle-A dns_rule_request-d 192.168.0.0/16-p udp！--dport 53-j RETURN

#此处判断一下是不是在nfqueue内部的标记,如果不是,则转入程序进行判断是不是需要代理的域名

iptables-t mangle-A dns_rule_request-p udp--dport 53-m mark！--mark456-jnfqueue--queue-num 1

#这里是将dns请求打上标记,然后转发代理程序

iptables-t mangle-A dns_rule_request-m mark--mark 456-j MARK--set-mark 1250

#这里是将ipset里面的流量打上标记,然后发给代理程序,ipset在流量返回时被判断添加

iptables-t mangle-A dns_rule_request-m set--match-set proxy_set dst-jMARK--set-mark 1250

#将新的链挂载在PREROUTING下

iptables-t mangle-A PREROUTING-m mark--mark 125-jdns_rule_request

#将这个被打上标记的流量,也就是需要dns代理查询的流量打到tun上

ip route add local default table 125dev tun

ip rule add fwmark 1250table 125

```

可以理解的是，上述代码创建了一个名为proxy_set的ipset，用于存储那些需要通过代理处理的目标地址。创建iptables新链dns_rule_request：这个新链用于定义DNS请求的处理规则。本地流量直接返回，确保所有发往本地网络(192.168.0.0/16)的TCP流量和非DNS的UDP流量直接通过，不进行代理处理。而针对UDP的53端口(DNS请求)的流量，如果它没有被标记为456，则将其发送到nfqueue队列1进行进一步处理。如果流量已经被nfqueue处理并打上了456标记，那么接下来用iptables将其标记为1250。使用ipset过滤的步骤中如果目标地址在proxy_set集合中，那么这些流量也被标记为1250。将dns_rule_request链挂载到PREROUTING的作用是对于所有经由ebtables标记为125的流量，都会通过这个新链进行进一步的处理。通过ip route和ip rule的设置，所有被标记为1250的流量都被路由到tun设备。这通常意味着该流量将被发送到一个虚拟的网络接口(如VPN接口)通过结合nfqueue、ipset和iptables的标记功能，能够实现对DNS流量的细粒度控制，以及灵活地将需要代理的流量转发到虚拟网络接口。这种配置允许在复杂的网络环境中精确地控制流量的路由和处理，特别是在处理涉及域名解析的流量时。

需要注意的是，当流量，特别是DNS请求首次被iptables捕获并发送到nfqueue时，会检查这些请求并决定它们是否需要通过代理。如果确定某个请求需要代理，该请求会被标记为456。这个标记的主要作用是防止流量在经过进一步的iptables规则处理时再次被捕获并发送回nfqueue从而形成一个无限循环。简而言之，标记456告诉iptables“这个数据包已经被处理过了，不需要再次发送到nfqueue。”在流量被标记为456之后，它会被再次送回iptables。这时iptables规则会检测到456标记，并将流量标记为1250。标记1250用于指示该流量已被确认需要代理处理。路由规则会捕获所有标记为1250的流量并将其重定向到适当的代理服务或虚拟网络接口(如VPN)。这是实际的代理决策标记，指导流量如何被路由和处理。通过这种方式，标记456和1250协同工作，确保流量仅经过一次nfqueue处理，然后根据需要被送往代理服务。这种方法在复杂的网络环境中非常有用，尤其是当需要对特定类型的流量(如DNS请求)进行细粒度的检查和处理时。它避免了处理循环，同时确保流量根据您的配置策略正确路由。

在一些示例中，返回给本地终端前,先将dns流量转发到nfqueue,判断一下是不是需要代理的,如果是需要代理的流量,那么就将解析出来的ip添加进ipset内。设定wan口的设备为eth1,即流量返回的接口，以以下代码为例：

```shell

iptables-t mangle-N dns_rule_reply

#本地的流量不处理,除非是dns请求的流量

iptables-t mangle-A dns_rule_reply-s 192.168.0.0/16-p tcp-j RETURN

iptables-t mangle-A dns_rule_reply-s 192.168.0.0/16-p udp！--sport 53-jRETURN

#此处判断一下是不是在nfqueue内部的标记,如果不是,则转入程序进行判断是不是需要代理的域名

iptables-t mangle-A dns_rule_reply-p udp--sport 53-m mark！--mark 456-jnfqueue--queue-num 1

#将新的链挂载在PREROUTING下

iptables-t mangle-A PREROUTING-i eth1-j dns_rule_reply

```

可以理解的是，可以创建新的iptables链dns_rule_reply，这个新链用于定义处理DNS响应的规则。这些规则确保所有源自本地网络(192.168.0.0/16)的TCP流量和非DNS的UDP流量直接通过，不进行后续处理。这主要是为了防止非DNS流量或本地产生的流量进入dns_rule_reply链。对于源端口为53的UDP流量(DNS响应)，如果没有被标记为456，则将其发送到nfqueue队列1进行进一步处理。这里的假设是，如果流量没有标记456，它可能包含新的DNS响应，需要被检查以确定是否需要代理。并且所有通过eth1接口进入的流量都会被dns_rule_reply链处理。这些规则的目的是对DNS响应进行处理，特别是检查哪些DNS请求的响应需要被代理。这在处理像DNS污染或劫持这样的问题时特别有用，可以根据DNS响应动态决定哪些域名的解析结果需要走代理路径。在DNS响应返回到本地终端之前，将它们转发到nfqueue进行检查，从而确定是否需要将解析出的IP地址添加到用于代理决策的ipset中。这样的配置可以为基于DNS响应的智能代理决策提供支持。DNS污染是指在DNS请求过程中故意修改DNS响应，以返回错误的IP地址。通过检测DNS响应并动态决定是否使用代理，可以有效地绕过这种污染。如果检测到某个域名可能受到污染，可以将其解析结果(IP地址)加入到ipset中，以便后续的流量通过代理来访问原本的网站。DNS劫持涉及到更改DNS查询的响应，将用户重定向到不同的地址。通过在本地处理DNS响应并根据实际内容判断是否需要代理，可以防止用户被错误地重定向。

进一步的，作为对上述图1所示方法的实现，本发明实施例还提供了一种网络代理装置，用于对上述图1所示的方法进行实现。该装置实施例与前述方法实施例对应，为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。如图2所示，该装置包括：获取单元21、分类单元22和代理单元23，其中

获取单元21，用于获取目标网络数据包来源信息，其中，所述来源信息包括实体端口信息和虚拟接口信息；

分类单元22，用于基于目标网络数据包的来源信息对网络数据包进行分类标记；

代理单元23，用于根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。

借由上述技术方案，本发明提供的网络代理装置，通过获取目标网络数据包来源信息，其中，所述来源信息包括实体端口信息和虚拟接口信息。并基于目标网络数据包的来源信息对网络数据包进行分类标记。再根据目标网络数据包的分类标记及目标路由策略将目标网络数据包导入至相应的代理服务器或虚拟专用网络通道。由此，通过上述方案实现了一个相对统一的针对不同网络请求的网络代理处理框架，创建了一个统一的流量管理和处理框架，在这个框架内，流量可以被统一捕获、标记、过滤和路由，无论它们来自有线还是无线网络。并将流量管理规则，如哪些流量需要代理、哪些直连等，集中在一处进行判断和处理，简化了网络管理。不需要在每个代理服务器或虚拟专用网络程序中分别设置规则，代理程序或虚拟专用网络只需专注于它们的核心功能，而不必担心流量的选择和路由问题。这种分工明确的模式使得代理和虚拟专用网络更加高效且易于管理，提高了网络代理维护的效率和一致性。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来实现一种网络代理方法，能够解决目前基于物联网层面上缺少一种更好的协调设备开关方法的问题。

本发明实施例提供了一种计算机可读存储介质，上述计算机可读存储介质包括存储的程序，该程序被处理器执行时实现上述网络代理方法。

本发明实施例提供了一种处理器，上述处理器用于运行程序，其中，上述程序运行时执行上述网络代理方法。

本发明实施例提供了一种电子设备，上述电子设备包括至少一个处理器、以及与上述处理器连接的至少一个存储器；其中，上述处理器用于调用上述存储器中的程序指令，执行如上述的网络代理方法。

本发明实施例提供了一种电子设备30，如图3所示，电子设备包括至少一个处理器301、以及与处理器连接的至少一个存储器302、总线303；其中，处理器301、存储器302通过总线303完成相互间的通信；处理器301用于调用存储器中的程序指令，以执行上述的网络代理方法。

本文中的智能电子设备可以是PC、智能路由设备等。

本申请还提供了一种计算机程序产品，当在流程管理电子设备上执行时，适于执行初始化有如上述第一方面提供的网络代理方法步骤的程序。

本申请是参照根据本申请实施例的方法、电子设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程流程管理电子设备的处理器以产生一个机器，使得通过计算机或其他可编程流程管理电子设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

在一个典型的配置中，电子设备包括一个或多个处理器(CPU)、存储器和总线。电子设备还可以包括输入/输出接口、网络接口等。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的计算机可读存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储电子设备或任何其他非传输介质，可用于存储可以被计算电子设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者电子设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者电子设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者电子设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。