WO2019052058A1 - 一种域名重定向方法和*** - Google Patents
一种域名重定向方法和*** Download PDFInfo
- Publication number
- WO2019052058A1 WO2019052058A1 PCT/CN2017/116429 CN2017116429W WO2019052058A1 WO 2019052058 A1 WO2019052058 A1 WO 2019052058A1 CN 2017116429 W CN2017116429 W CN 2017116429W WO 2019052058 A1 WO2019052058 A1 WO 2019052058A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- domain name
- data packet
- packet
- dns
- redirection
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
Definitions
- the present invention relates to the field of Internet, and in particular, to a domain name redirection method and system.
- DNS Domain Name System
- IP address Internet Protocol Address
- IP Address also known as an Internet Protocol Address
- a distributed database that provides domain name to IP address translation, which makes it easier for users to access the Internet without having to remember the IP number string that can be directly read by the machine.
- URL we input is a domain name.
- domain name resolution or host name resolution.
- DNS is a system for domain name resolution.
- the DNS protocol runs on top of the UDP protocol and uses port number 53.
- DNS redirection is used in the Internet to facilitate the selection of cache servers based on DNS resolution mechanisms. These technologies are widely used by various CDN companies.
- the method only points out that the DNS server obtains and sends the domain name when responding to the user domain name request, and does not indicate where to intercept.
- the location of the interception directly affects the success of the interception, and the acquisition process of the corresponding IP address. , did not propose a more practical approach.
- the method includes the method of obtaining the domain name, the determination of the correct domain name error domain name, and the analysis and processing method of the incorrect domain name.
- the domain name input to the user
- the content is analyzed, and according to the content of the domain name, the information most needed by the user is returned, and the helplessness of the user to open the blank page is avoided, and the service can be provided to the customer more intelligently.
- the general implementation scheme after induction is roughly as follows: First, the domain name is modified by adding the binary combination of the domain name and the IP address in the application layer by modifying the /etc/hosts file. Hijacking; add the form as follows 192.168.1.103www.sohu.com, where 192.168.1.103 is the local server IP, www.sohu.com is the domain name to be hijacked.
- the second is to intercept the DNS packets through the IP layer of the network protocol stack, and re-group a DNS return packet to send to the specified IP address.
- the technical problem to be solved by the present invention is to address the shortcomings of the above prior art, and provide a domain name redirection capable of intercepting and redirecting a DNS request packet that does not go through the IP layer but only at the link layer to the corresponding IP address.
- a domain name redirection method comprising the following steps:
- step S20 includes:
- step S30 includes:
- S31 Construct a domain name return packet, and redirect the domain name return packet to the internet protocol address.
- step S10 includes:
- step S10 and the step S20 include: determining whether the internet protocol address is successfully obtained. If successful, performing step S20. If not, step S20 is not performed.
- step S20 includes: establishing a hook function, and hooking all link layer data packets to the hook function.
- the hook function execution step includes:
- a domain name redirection system comprising:
- An internet protocol address module for obtaining an internet protocol address
- Parsing an interception module for parsing data packets in the link layer and intercepting the specified domain name request
- a redirection module configured to redirect the specified domain name request to the internet protocol address.
- parsing intercepting module includes:
- a first determining unit configured to determine whether the data packet is a domain name packet data packet, after the data packet in the link layer is parsed;
- An obtaining unit configured to acquire a domain name when continuing to parse the domain name message data packet if the first determining unit determines that the domain name message data packet is
- the second determining unit is configured to determine whether the domain name obtained by the acquiring unit is a specified domain name.
- the redirection module includes:
- a construction unit that constructs a domain name return package.
- the above implementation scheme adopts a way of directly accessing the network by remembering the domain name, which is easier for the user to remember and more friendly; the same for the service provider, some network devices that cannot be managed by accessing a fixed IP address.
- the above scheme can be used to manage the network device by setting a fixed domain name by using a fixed domain name; in addition, the above technical solution expands the interception range of the DNS request packet, and can perform the same for the DNS request without the IP layer. Interception and redirection ensure data integrity and ensure the comprehensiveness of device management.
- FIG. 1 is a flowchart of a domain name redirection method according to Embodiment 1 of the present invention
- FIG. 2 is a flowchart of a domain name redirection method according to Embodiment 2 of the present invention.
- FIG. 3 is a flowchart of a domain name redirection method according to Embodiment 3 of the present invention.
- FIG. 4 is a structural diagram of a domain name redirection system according to Embodiment 4 of the present invention.
- WIFI also known as the WIFI network
- WIFI devices have emerged in an endless stream, and WIFI devices have a variety of ways to establish network connections. Different WIFI devices under different connection modes perform their respective functions due to different needs.
- DNS Domain Name System
- DNS Domain Name System
- the present invention provides a solution for conveniently accessing and managing some network devices such as a repeater or a WIFI expander connected to a main router through a wireless bridge, or a user accessing these devices through a domain name.
- some network devices such as a repeater or a WIFI expander connected to a main router through a wireless bridge, or a user accessing these devices through a domain name.
- the DNS request sent by the terminal does not actively go to the IP layer of these devices, the DNS request interception is performed somewhere in the link layer in advance, and is redirected to the IP of these devices.
- the scheme implements a hook structure by establishing a kernel module, intercepts the DNS request in the link layer, and constructs a corresponding return packet to redirect the DNS request to the device IP.
- a kernel module intercepts the DNS request in the link layer, and constructs a corresponding return packet to redirect the DNS request to the device IP.
- this embodiment provides a domain name redirection method, where the method includes the following steps:
- IP address an internet protocol address
- the router or Repeater first finds the IP address used by the device to connect to the network, and saves the IP address information field, such as 192.168.18.25. Then trigger the next step to start the packet parsing of the link layer. Since the existing IP address is mostly a dynamic IP address allocated by the server, instead of a fixed IP address, the IP address is first obtained in this step, and then the process of parsing the data packet in the link layer is started, which can reduce unnecessary data parsing and save network resources. , purify the network connection process.
- the router or the Repeater actively triggers the process of parsing the data packet in the link layer, parses all the data packets in the link layer, and intercepts the DNS request specified by the service provider. After the interception is completed, the next step is performed. If the specified DNS request is set to e.to, the DNS request of e.to will be found in this step and intercepted for use; all DNS requests include DNS requests that do not go through the IP layer. Can be intercepted, so that more clients get more convenient and smooth access or online experience, and also provide convenience for service providers through a better domain name, a wider range of management routers or Repeater network devices;
- the DNS request is redirected to the previously obtained IP address, that is, after obtaining 192.168.18.25 and e.to successively, e.to Specifies that the DNS request is redirected to the IP address 192.168.18.25.
- the function of accessing the router or the Repeater through the DNS is realized, which is convenient for the user to memorize and smoothly establish the network connection, and also facilitates the service provider to manage the network device such as the router or the Repeater by accessing the fixed DNS.
- the domain name redirection method provided in this embodiment implements accessing and managing some network devices that do not actively send DNS requests to their own IP layers through DNS. These network devices may be WIFI expanders, Repeaters, and the like.
- the difference between this embodiment and the previous embodiment is that the present embodiment provides a more detailed domain name redirection method, and the step S20 specifically includes:
- the router or the Repeater first parses all the data packets received in the link layer one by one, finds the DNS packet data packet, and determines whether the DNS packet is a monitoring packet. Whether it is from port 53 of the UPD protocol.
- the packet data packet is continuously parsed to obtain the DNS in the packet.
- the DNS obtained is matched with the DNS set by the service provider, for example, a hypothetical service. If the specified DNS is e.to, it is determined whether the obtained DNS is e.to. If the judgment result is yes, the router or Repeater will redirect the e.to DNS request to the previously obtained IP address, and finally It realizes the function that can be accessed through DNS.
- the device can be accurate. Get DNS and complete DNS access.
- step S30 includes:
- S31 Construct a DNS return packet and redirect the DNS return packet to the IP address.
- the router or the Repeater and other devices confirm that the DNS request sent by the client is indeed the specified e.to, which is recognized by itself, and then constructs an e.to according to the packet encoding type identifiable by the device.
- the packet data packet (referred to as the DNS return packet), for example, e.to is www.***.com, which is constructed according to the packet encoding type identifiable by the device, and is 3www5***3com.
- the DNS return packet is returned. Redirecting to the IP address, the IP address is an IP address obtained before the device parses the data packet in the link layer.
- step S10 includes:
- Repeater devices generally connect to the primary router through wireless bridging.
- the IP address of the primary router is a dynamic IP address, which arrives with the lease term.
- the IP address may be changed, with uncertainty, and the way to save a unique IP address obviously does not satisfy the access requirements.
- the udhcpc process is obtained by using the udhcpc process.
- the udhcpc process obtains the IP address from the DHCP server of the primary router through the DHCP protocol.
- the IP address is obtained according to the IP address allocation principle. The obtained IP address is more realistic and more accurate. accurate.
- step S10 and the step S20 include: determining whether the IP address is successfully obtained. If successful, performing step S20. If not, step S20 is not performed. That is to say, only when the process of obtaining an IP address successfully obtains an IP address that meets the access requirement, the packet in the link layer is parsed and the specified DNS request process is intercepted. Reduce unnecessary parsing interception process, purify the network, and save resources.
- the domain name redirection method provided in this embodiment helps the network device adopting the method to be more intelligent. Complete the DNS access process and more accurately guarantee DNS access.
- the difference between this embodiment and the embodiment 2 is that the embodiment provides a detailed method for realizing domain name redirection in the Linux kernel, and the Repeater is taken as an example.
- the Repeater if only the Repeater obtains the current After the IP address of the network connection, the Repeater loads the DNS interception process through the Insmod tool, that is, the corresponding processes of steps S20 and S30 are started to implement DNS redirection.
- steps S20 and S30 are written to the same dns_redirect.ko kernel module. If and only after the Repeater obtains the IP address (redirect_ip) under the current network connection, the Insmod tool will be dns_redirect.
- the ko kernel module is loaded into the Linux kernel, and finally the specified DNS redirection is implemented. It is not difficult to understand that DNS and redirect_ip are two parameters when loading the dns_redirect.ko kernel module.
- the step S20 includes:
- a hook function is created to hook all link layer packets to the hook function.
- a hook function is a program segment that processes a message and hooks it into the system through a system call. Whenever a specific message is sent, the hook program first captures the message before it reaches the destination window, that is, the hook function first obtains control, providing conditions for subsequent processing of the message. In this step, a hook function is established, which can hang all link layer data packets into the same processing segment of the message, perform the same processing process, and complete DNS interception and redirection without any problem, thereby establishing a method to A bridge for specific program implementation.
- the hook function execution step includes:
- the execution procedure of the hook function is the same as the specific implementation process of step S20 in Embodiment 2, and will not be described again.
- the general idea is to first implement a packet_type kernel structure, parse the data packet of type ETH_P_ALL, and execute the hook function ip_skb_recv.
- Insmod dns_redirect.ko hooks the all_packet_type instance to the path that the packet must pass through a dev_add_pack function.
- the hook function of ip_skb_recv is established, and all link layer data packets are implemented by the ip_skb_recv function to implement the hook process.
- This embodiment provides a practical program design, hooking all link layer data packets to the hook function, and can easily and quickly obtain all link layer data packets, and can process all according to a unified parsing interception method.
- the DNS request provides conditions for redirecting all specified DNS.
- users and service providers can access and manage only network devices that do not actively send DNS requests to their own IP layer through domain names.
- the IP address module 100 is configured to obtain an IP address.
- the parsing intercepting module 200 is configured to parse the data packet in the link layer and intercept the specified DNS request;
- the redirecting module 300 is configured to redirect the specified DNS request to the IP address.
- parsing intercepting module 200 includes:
- the first determining unit 210 is configured to: after parsing the data packet in the link layer, determine whether the data packet is a DNS packet data packet;
- the obtaining unit 220 is configured to: if the first determining unit 210 determines that it is a DNS packet data packet, Obtaining DNS when resolving the DNS packet data packet;
- the second determining unit 230 is configured to determine whether the DNS acquired by the obtaining unit 220 is a designated DNS.
- the redirection module 300 includes:
- the construction unit 310 is configured to construct a DNS return packet.
- the IP address module 100 of the router obtains a dynamic IP address backup from the DHCP server, such as 192.168.15.28. Then, the parsing interception module 200 of the router parses the data packet in the link layer, and the first determining unit 210 determines whether the data packet is a DNS packet data packet, and if the result is not, the process ends, and if the result is yes, the process starts.
- the obtaining unit 220 intercepts the acquisition of the DNS when the DNS packet data packet is continuously parsed; the second determining unit 230 determines whether the DNS acquired by the obtaining unit 220 is a designated DNS, such as e.to. If not, the process is terminated. If so, the construction unit 310 starts to start constructing the e.to return packet, and the redirection module 300 of the router redirects the e.to return packet to the IP address 192.168.15.28.
- the domain name redirection system provided in this implementation expands the interception range of DNS request packets, and can perform the same interception and redirection for some DNS requests that do not pass through the IP layer, thereby ensuring data integrity and ensuring comprehensiveness of device management. .
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种域名重定向方法和***,所述方法包括以下步骤:S10:获取网际协议地址;S20:解析链路层中的数据包,并拦截指定域名请求;S30:重定向所述指定域名请求至所述网际协议地址。本发明使得使用者只需记住域名,通过域名就能直接访问网络,方法更友好;另外本发明扩大了DNS请求数据包的拦截范围,能对不经过IP层的DNS请求进行同样的拦截和重定向,保证了数据的完整性,保障了设备管理的全面性,对于服务商来说,一些不能通过访问固定IP地址方式管理的网络设备,可以运用上述方法实现访问固定DNS的方式管理,使得网络管理更加方便更加规范。
Description
本发明涉及互联网领域,特别涉及一种域名重定向方法和***。
DNS(Domain Name System,域名***),是把访问域名地址转换成对应IP地址(Internet Protocol Address,互联网协议地址,又称网际协议地址)的一种***,它在因特网上作为域名和IP地址相互映射的一个分布式数据库,提供域名到IP地址的转换,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串,通常我们输入的网址就是一个域名。通过主机名,最终得到该主机名对应的IP地址的过程叫做域名解析(或主机名解析),DNS就是专门完成域名解析的***。DNS协议运行在UDP协议之上,使用端口号53。
目前,对DNS请求进行域名解析过程中,多数网络设备出于种种目的,如为了实现特定域名的管理或为项目开发和内测提供数据支持等,均需要将特定的DNS请求进行重定向操作。DNS重定向在因特网中用于促进基于DNS解析机制的缓存服务器的选择。各种CDN公司广泛地使用这些技术。
如公开号为CN102014173B的专利文献公开了“一种域名重定向控制方法、模块及***”,方法指出域名重定向控制模块接收DNS服务器在应答用户域名请求时,从用户请求中获取并发送的域名信息;根据保存的重定向域名信息确定接收到的域名信息是否可用于重定向,如果确定所述用户请求的域名可用于重定向,则将用户所访问的域名重定向到对应的IP地址。所述重定向域名信息保存在重定向域名列表中,该重定向域名列表中记录不可用于重定向的域名。但方法中仅指出在DNS服务器应答用户域名请求时获取并发送域名,并未指出在哪个地方进行拦截,拦截的位置不同会直接影响到拦截的成功与否,另外对于对应的IP地址的获取过程,未提出更符合实际运用的方法。
又如公开号为CN101505323B的专利文献公开了“海量数据下基于内容分
析的域名解析重定向方法”,方法包括获取域名的方法,正确域名错误域名的判定以及错误域名的分析处理方法。当用户输入错误域名时,不是直接返回空白页面,而是对用户输入的域名内容进行分析,根据域名内容,返回给用户最需要的信息,避免用户打开空白页面的无奈,能更加智能的为客户提供服务。
关于特定DNS请求重定向方法,归纳后一般的实现方案大致有如下两种:一是通过在应用层,修改/etc/hosts文件,通过在其中添加域名跟IP地址的二元组合,来进行域名劫持;添加形式如下192.168.1.103www.sohu.com,其中192.168.1.103为本地服务器IP,www.sohu.com为要劫持的域名。二是通过在网络协议栈的IP层,对DNS数据包进行拦截,并重新组一个DNS返回包发送到指定IP地址。对于较简单的应用,通过在应用层/etc/hosts文件添加域名跟IP地址的二元组合即可实现简单针对某个或某些域名,重定向到指定的IP的功能;但对于相对比较复杂的应用需求来说,基本都会选择在IP层对DNS请求包进行拦截来实现。
然而市面上有一部分网络设备接收客户端发出的DNS请求后,并不会主动发送DNS请求前往网络设备网络协议栈的IP层,使用以上两种实现方案也均无法做到对不经过IP层的DNS请求数据包进行拦截,使得网络设备的管理出现了盲区。
可见,合乎需要的是提供解决方案避免上述问题和缺陷十分必要。
发明内容
本发明要解决的技术问题是针对上述现有技术的不足,提供一种能够对不经过IP层而是只在链路层游走的DNS请求包进行拦截并重定向到相应IP地址的域名重定向方法和***。
为了实现上述目的,本发明采用的技术方案为:
一种域名重定向方法,所述方法包括以下步骤:
S10:获取网际协议地址;
S20:解析链路层中的数据包,并拦截指定域名请求;
S30:重定向所述指定域名请求至所述网际协议地址。
进一步地,所述步骤S20中包括:
S21:解析链路层中的数据包,判断所述数据包是否为域名报文数据包;
S22:若是域名报文数据包,则继续解析所述域名报文数据包获取域名;
S23:判断所述域名是否为指定域名,若是则执行步骤S30。
进一步地,所述步骤S30中包括:
S31:构造域名返回包,并将所述域名返回包重定向至所述网际协议地址。
进一步地,所述步骤S10中包括:
S11:根据动态主机配置协议从相应的服务器中获取网际协议地址。
进一步地,所述步骤S10与所述步骤S20之间包括:判断网际协议地址是否获取成功,若成功,则执行步骤S20,若不成功,则不执行步骤S20。
进一步地,所述步骤S20中包括:建立钩子函数,将所有的链路层数据包挂钩至所述钩子函数处。
进一步地,所述钩子函数执行步骤包括:
S21:解析数据包,判断所述数据包是否为域名报文数据包;
S22:若是域名报文数据包,则继续解析所述域名报文数据包获取域名;
S23:判断所述域名是否为指定域名,若是则执行步骤S30。
一种域名重定向***,所述***包括:
网际协议地址模块,用于获取网际协议地址;
解析拦截模块,用于解析链路层中的数据包,并拦截指定域名请求;
重定向模块,用于重定向所述指定域名请求至所述网际协议地址。
进一步地,所述解析拦截模块包括:
第一判断单元,用于解析链路层中的数据包后,判断所述数据包是否为域名报文数据包;
获取单元,用于若第一判断单元判断是域名报文数据包,则在继续解析所述域名报文数据包时获取域名;
第二判断单元,用于判断获取单元获取的所述域名是否为指定域名。
进一步地,所述重定向模块包括:
构造单元,用于构造域名返回包。
采用上述技术方案后,本发明的有益效果是:
(1)由于网际协议地址大多是由服务器动态分配的,具有不确定性,通
过先在设备中获取相应的网际协议地址后,再解析拦截指定的域名请求,使得解析的过程在尽量不做无用功,不浪费网络资源;
(2)通过解析链路层中的数据包,并拦截指定域名请求,使得所有的DNS请求包括不经过IP层的DNS请求都能被拦截,从而使更多的客户端得到更方便流畅的上网体验,同时也为服务商通过域名更好的、范围更广的管理网络服务设备提供便捷;
(3)通过先判断所述链路层数据包是否为域名报文数据包,再获取域名,而不是先获取所述链路层数据包中的关键字段后再获取域名类的关键字段,方便域名准确获取的同时还能减少链路层数据包解析任务总量;
(4)通过建立钩子函数,将所有的链路层数据包挂钩至所述钩子函数处,能够简单快速的获取到所有链路层数据包,并能按照统一的解析拦截方法处理所有的DNS请求,为无纰漏的重定向所有指定域名提供条件。
总体上上述实现方案,采用通过记住域名就能直接访问网络的方式对使用者来说更容易记住更友好;同样的对于服务商来说,一些不能通过访问固定IP地址方式管理的网络设备,可以采用上述方案通过设定好指定域名后,采用固定域名的方式即可管理网络设备;另外上述技术方案扩大了DNS请求数据包的拦截范围,能对不经过IP层的DNS请求进行同样的拦截和重定向,保证了数据的完整性,保障了设备管理的全面性。
为了更清楚地说明本发明实施例或现有技术的技术方案,附图如下:
图1为本发明实施例1提供的一种域名重定向方法流程图;
图2为本发明实施例2提供的一种域名重定向方法流程图;
图3为本发明实施例3提供的一种域名重定向方法流程图;
图4为本发明实施例4提供的一种域名重定向***结构图。
以下是本发明的具体实施例并结合附图,对本发明的技术方案作进一步的描述,但本发明并不限于这些实施例。
无线网络高速发展的今天,我们随时随地都能体验到WLAN(也就是我们常说的WIFI网络)给我们的生活带来的高效和便捷。近几年,WIFI设备层出不穷,WIFI设备建立网络连接的方式也多种多样,不同连接方式下的不同WIFI设备,由于不同需要执行着各自的职能。
DNS(Domain Name System,域名***)就是其中的一种建立网络连接的方式,DNS请求执行过程中,为了实现特定域名的管理或为项目开发和内测提供数据支持等,均需要将特定的DNS请求进行重定向操作。而现有的大多数的重定向操作中都是在IP层的某些地方拦截DNS请求,无法对不经过IP层的请求数据包进行拦截,也不能满足采用访问固定域名的方式管理一些网络设备的需求。因此有必要在链路层的某个地方进行数据包拦截。
本发明为解决上述问题,提出一种方案能够方便通过域名访问和管理一些通过无线桥接与主路由器连接的中继器(Repeater)或WIFI扩展器等网络设备,也可在接入这些设备的用户端发出的DNS请求不主动前往这些设备的IP层时,提前在链路层的某个地方进行DNS请求拦截,并重定向到这些设备IP上。
本方案通过建立一个内核模块,实现钩子结构,对链路层中DNS请求进行拦截,并构造相应返回包,将DNS请求重定向到设备IP上。其中,内核模块何时启动,重定向又如何适时的执行都是本方案设计时需要考虑的问题。
实施例1
如图1所示,本实施例提供一种域名重定向方法,所述方法包括以下步骤:
S10:获取网际协议地址(IP地址);
本步骤中,路由器或者Repeater等首先找到本设备连接网络所用到的IP地址,并保存下这个IP地址信息字段,如192.168.18.25。然后触发启动下一步骤,开始链路层的数据包解析。由于现有IP地址多数为服务器分配的动态IP,而不是固定IP,所以本步骤中首先获取IP地址,再启动解析链路层中的数据包过程,能够减少不必要的数据解析,节约网络资源,净化网络连接过程。
S20:解析链路层中的数据包,并拦截指定域名(DNS)请求;
本步骤中,路由器或者Repeater等获取IP地址后,主动触发开启链路层中的数据包的解析过程,将链路层中的所有数据包一一解析,并拦截下服务商指定的DNS请求,拦截完毕执行下一步骤,如指定DNS请求设为e.to,本步骤中将查找到e.to这个DNS请求并将其拦截下来备用;使得所有的DNS请求包括不经过IP层的DNS请求都能被拦截,从而使更多的客户端得到更方便流畅的访问或上网体验,同时也为服务商通过域名更好的、范围更广的管理路由器或者Repeater这些网络设备提供便捷;
S30:重定向所述指定域名(DNS)请求至所述网际协议地址(IP地址)。
本步骤中,路由器或者Repeater等拦截到服务商指定的DNS请求后,将这个DNS请求重定向到之前获得的IP地址,即,在先后获得192.168.18.25和e.to后,将e.to这个指定DNS请求重定向到192.168.18.25这个IP地址处。这样,就实现了通过DNS访问路由器或者Repeater等的功能,方便用户记忆和顺畅的建立网络连接,同时也方便服务商采用访问固定DNS的方式管理路由器或者Repeater等网络设备。
本实施例提供的域名重定向方法实现了通过DNS访问和管理某些不主动将DNS请求发往自身IP层的网络设备,这些网络设备可能会是WIFI扩展器,Repeater等。
实施例2
如图2所示,本实施例与之前实施例的区别在于,本实施例提供一种更加详细的域名重定向方法,所述步骤S20中具体包括:
S21:解析链路层中的数据包,判断所述数据包是否为DNS报文数据包;
本步骤中,路由器或者Repeater等在获取IP地址后,首先一一解析链路层中接收到的所有数据包,找出DNS报文数据包,判断是否为DNS报文的方法通常采用监听数据包是否来自UPD协议的53号端口。
S22:若是DNS报文数据包,则继续解析所述DNS报文数据包获取DNS;
本步骤中,如果判断该数据包确实来自UPD协议的53号端口,那么就继续解析这个报文数据包,获取报文中的DNS。
S23:判断所述DNS是否为指定DNS,若是则执行步骤S30。
本步骤中,将获取到得DNS与服务商设定的DNS匹配,例如,假设服务
商指定DNS为e.to,则判断该获取的DNS是否为e.to,如果判断结果为是,那么路由器或者Repeater等会将e.to这个DNS请求重定向到之前获取到的IP地址,最终实现了通过DNS即可访问的功能。
综上可知,通过先判断所述数据包是否为DNS报文数据包,后获取DNS,最后确认是否为指定DNS的解析拦截顺序,可减少链路层数据包解析任务总量,方便设备能够准确获取DNS,完成DNS访问。
可选地,所述步骤S30中包括:
S31:构造DNS返回包,并将所述DNS返回包重定向至所述IP地址。
本步骤中,路由器或者Repeater等设备确认由用户端发来的DNS请求的确是被指定的、其自身认可的e.to,就会按照本设备可识别的报文编码类型构造一个e.to的报文数据包(称DNS返回包),例如e.to为www.***.com,它按照本设备可识别的报文编码类型构造后为3www5***3com,DNS返回包构造完成后,将这个DNS返回包重定向至所述IP地址,所述IP地址就是设备解析链路层中的数据包之前获取到的IP地址。
可选地,所述步骤S10中包括:
S11:根据DHCP协议从相应的服务器中获取IP地址。
Repeater类设备一般会通过无线桥接的方式连接主路由器,当Repeater通过WIFI桥接主路由器成功后,Repeater就和主路由器并用网络,主路由器的IP地址是一个动态的IP地址,随着租约期限的到达,IP地址可能存在变化,具有不确定性,保存唯一不变的IP地址的方式,显然不能满足访问需求。本步骤中,获取IP地址方式利用udhcpc进程,udhcpc进程通过DHCP协议从主路由器的DHCP服务器中获取到IP地址,采用上述方法获取IP地址符合IP地址分配原则,获取的IP地址更符合实际、更准确。
需要特别指出的是,所述步骤S10与所述步骤S20之间包括:判断IP地址是否获取成功,若成功,则执行步骤S20,若不成功,则不执行步骤S20。也就是说只有获取IP地址过程成功获取到一个符合访问需求的IP地址,才会启动解析链路层中的数据包,并拦截指定DNS请求过程。减少了不必要的解析拦截进程,净化网络,节约资源。
本实施例提供的域名重定向方法帮助采用该方法的网络设备更加智能的
完成DNS访问过程,也更精确的保障DNS访问。
实施例3
如图3所示,本实施例与实施例2的区别在于,本实施例提供一种在Linux内核实现域名重定向详细方法,以Repeater为例,本实施例中当且仅当Repeater获取到当前网络连接下的IP地址后,Repeater通过Insmod工具加载DNS拦截进程,也就是开启步骤S20和S30的相应进程,实现DNS重定向。
程序编写过程中,将步骤S20和S30的提到的相应进程写入同一dns_redirect.ko内核模块,当且仅当Repeater获取到当前网络连接下的IP地址(redirect_ip)后,通过Insmod工具将dns_redirect.ko内核模块加载到Linux kernel中,最终实现指定DNS的重定向。不难理解的,DNS和redirect_ip就是加载dns_redirect.ko内核模块时的两个参数。
具体地,所述步骤S20中包括:
建立钩子函数,将所有的链路层数据包挂钩至所述钩子函数处。
钩子函数是一个处理消息的程序段,通过***调用,把它挂入***。每当特定的消息发出,在没有到达目的窗口前,钩子程序就先捕获该消息,亦即钩子函数先得到控制权,为后面加工处理消息提供条件。本步骤中,建立钩子函数,可将所有的链路层数据包挂入同一个处理消息的程序段中,执行相同的处理过程,能够无纰漏的完成DNS拦截以及重定向,从而建立起方法到具体程序实现的桥梁。
具体地,所述钩子函数执行步骤包括:
S21:解析数据包,判断所述数据包是否为DNS报文数据包;
S22:若是DNS报文数据包,则继续解析所述DNS报文数据包获取DNS;
S23:判断所述DNS是否为指定DNS,若是则执行步骤S30。
此处的钩子函数执行步骤与实施例2中步骤S20具体实现过程相同,便不再此赘述。
另外,部分程序实现的定义如下:
static struct packet_type all_packet_type__read_mostly={
.type=cpu_to_be16(ETH_P_ALL),
.func=ip_skb_recv,/*ip receive method*/
};
其中,大意就是首先实现一个packet_type内核结构,对类型为ETH_P_ALL的数据包进行解析,并执行ip_skb_recv这个钩子函数。
static int__init dns_redirect_init(void)
{
if(dns){
d_len=strlen(dns);
}
dev_add_pack(&all_packet_type);
return 0;
}
Insmod dns_redirect.ko时,通过一个dev_add_pack函数将all_packet_type实例挂钩到数据包必经的路径上。这样ip_skb_recv这个钩子函数建立完成,所有的链路层数据包都会经过ip_skb_recv函数实现钩子进程。
本实施例提供了切实可行的程序设计,将所有的链路层数据包挂钩至所述钩子函数处,能够简单快速的获取到所有链路层数据包,并能按照统一的解析拦截方法处理所有的DNS请求,为无纰漏的重定向所有指定DNS提供条件。整体上,用户和服务商仅通过域名即可访问和管理一些不主动将DNS请求发往自身IP层的网络设备。
实施例4
如图4所示,本实施例提供一种域名重定向***,所述***包括:
IP地址模块100,用于获取IP地址;
解析拦截模块200,用于解析链路层中的数据包,并拦截指定DNS请求;
重定向模块300,用于重定向所述指定DNS请求至所述IP地址。
进一步地,所述解析拦截模块200包括:
第一判断单元210,用于解析链路层中的数据包后,判断所述数据包是否为DNS报文数据包;
获取单元220,用于若第一判断单元210判断是DNS报文数据包,则在继
续解析所述DNS报文数据包时获取DNS;
第二判断单元230,用于判断获取单元220获取的所述DNS是否为指定DNS。
进一步地,所述重定向模块300包括:
构造单元310,用于构造DNS返回包。
以路由器为例,***工作原理如下:路由器的IP地址模块100从DHCP服务器中获取到动态IP地址备用,如192.168.15.28。然后路由器的解析拦截模块200解析链路层中的数据包,当中的第一判断单元210判断所述数据包是否为DNS报文数据包,若结果为不是则结束进程,若结果为是则启动获取单元220在继续解析所述DNS报文数据包时拦截获取DNS;第二判断单元230判断获取单元220获取的所述DNS是否为指定DNS,如e.to。若不是则结束进程,若是则构造单元310启动开始构造e.to返回包,构造完毕由路由器的重定向模块300重定向所述e.to返回包至所述IP地址192.168.15.28上。
本实施提供的域名重定向***扩大了DNS请求数据包的拦截范围,能对有些不经过IP层的DNS请求进行同样的拦截和重定向,保证了数据的完整性,保障了设备管理的全面性。
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代,但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。
Claims (10)
- 一种域名重定向方法,其特征在于,所述方法包括以下步骤:S10:获取网际协议地址;S20:解析链路层中的数据包,并拦截指定域名请求;S30:重定向所述指定域名请求至所述网际协议地址。
- 根据权利要求1所述的一种域名重定向方法,其特征在于,所述步骤S20中包括:S21:解析链路层中的数据包,判断所述数据包是否为域名报文数据包;S22:若是域名报文数据包,则继续解析所述域名报文数据包获取域名;S23:判断所述域名是否为指定域名,若是则执行步骤S30。
- 根据权利要求1或2所述的一种域名重定向方法,其特征在于,所述步骤S30中包括:S31:构造域名返回包,并将所述域名返回包重定向至所述网际协议地址。
- 根据权利要求1所述的一种域名重定向方法,其特征在于,所述步骤S10中包括:S11:根据动态主机配置协议从相应的服务器中获取网际协议地址。
- 根据权利要求1所述的一种域名重定向方法,其特征在于,所述步骤S10与所述步骤S20之间包括:判断网际协议地址是否获取成功,若成功,则执行步骤S20,若不成功,则不执行步骤S20。
- 根据权利要求1所述的一种域名重定向方法,其特征在于,所述步骤S20中包括:建立钩子函数,将所有的链路层数据包挂钩至所述钩子函数处。
- 根据权利要求6所述的一种域名重定向方法,其特征在于,所述钩子函数执行步骤包括:S21:解析数据包,判断所述数据包是否为域名报文数据包;S22:若是域名报文数据包,则继续解析所述域名报文数据包获取域名;S23:判断所述域名是否为指定域名,若是则执行步骤S30。
- 一种域名重定向***,其特征在于,所述***包括:网际协议地址模块,用于获取网际协议地址;解析拦截模块,用于解析链路层中的数据包,并拦截指定域名请求;重定向模块,用于重定向所述指定域名请求至所述网际协议地址。
- 根据权利要求8所述的一种域名重定向***,其特征在于,所述解析拦截模块包括:第一判断单元,用于解析链路层中的数据包后,判断所述数据包是否为域名报文数据包;获取单元,用于若第一判断单元判断是域名报文数据包,则在继续解析所述域名报文数据包时获取域名;第二判断单元,用于判断获取单元获取的所述域名是否为指定域名。
- 根据权利要求8所述的一种域名重定向***,其特征在于,所述重定向模块包括:构造单元,用于构造域名返回包。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710828089.4A CN107613037B (zh) | 2017-09-14 | 2017-09-14 | 一种域名重定向方法和*** |
CN201710828089.4 | 2017-09-14 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019052058A1 true WO2019052058A1 (zh) | 2019-03-21 |
Family
ID=61063514
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2017/116429 WO2019052058A1 (zh) | 2017-09-14 | 2017-12-15 | 一种域名重定向方法和*** |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN107613037B (zh) |
WO (1) | WO2019052058A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112040027A (zh) * | 2020-09-14 | 2020-12-04 | 网易(杭州)网络有限公司 | 一种数据处理的方法及装置、电子设备、存储介质 |
CN112230927A (zh) * | 2020-09-17 | 2021-01-15 | 贝壳技术有限公司 | 一种文件重定向方法、代码加载控制方法及装置 |
CN116170409A (zh) * | 2023-02-21 | 2023-05-26 | 江苏云涌电子科技股份有限公司 | 一种基于虚拟域名的sd-wan网络地址规划*** |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108769287A (zh) * | 2018-05-31 | 2018-11-06 | 四川斐讯全智信息技术有限公司 | 一种路由器域名访问方法、***、计算机设备和存储介质 |
CN109981347A (zh) * | 2019-02-22 | 2019-07-05 | 深圳市吉祥腾达科技有限公司 | 一种自动弹出桥接器管理页面的方法 |
CN110557753B (zh) * | 2019-08-13 | 2023-05-09 | 成都电科慧安科技有限公司 | 一种用于公安网通的基于中继接入的dns重定向方法 |
CN110933129A (zh) * | 2019-10-18 | 2020-03-27 | 网宿科技股份有限公司 | 一种数据调度方法、插件及装置和调度服务器 |
CN112202675B (zh) * | 2020-10-10 | 2022-04-15 | 四川天邑康和通信股份有限公司 | 一种基于linux内核解析DNS实现使用域名访问路由器的方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101505323A (zh) * | 2009-02-24 | 2009-08-12 | 南京联创科技股份有限公司 | 海量数据下基于内容分析的域名解析重定向方法 |
CN102014173A (zh) * | 2010-11-01 | 2011-04-13 | 蓝汛网络科技(北京)有限公司 | 一种域名重定向控制方法、模块及*** |
CN104243627A (zh) * | 2014-08-29 | 2014-12-24 | 华为技术有限公司 | 一种域名解析方法、装置及*** |
CN104468865A (zh) * | 2014-12-25 | 2015-03-25 | 北京奇虎科技有限公司 | 域名解析控制、响应方法及相应的装置 |
CN104917838A (zh) * | 2015-06-12 | 2015-09-16 | 南京创维信息技术研究院有限公司 | 一种路由重定向的实现方法及*** |
WO2016062077A1 (zh) * | 2014-10-24 | 2016-04-28 | 中兴通讯股份有限公司 | 重定向到Web页面的方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103812770B (zh) * | 2012-11-12 | 2017-04-12 | 华为技术有限公司 | 云业务报文重定向的方法、***和云网关 |
CN106330948A (zh) * | 2016-09-09 | 2017-01-11 | 杭州华三通信技术有限公司 | 一种报文控制方法及装置 |
-
2017
- 2017-09-14 CN CN201710828089.4A patent/CN107613037B/zh active Active
- 2017-12-15 WO PCT/CN2017/116429 patent/WO2019052058A1/zh active Application Filing
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101505323A (zh) * | 2009-02-24 | 2009-08-12 | 南京联创科技股份有限公司 | 海量数据下基于内容分析的域名解析重定向方法 |
CN102014173A (zh) * | 2010-11-01 | 2011-04-13 | 蓝汛网络科技(北京)有限公司 | 一种域名重定向控制方法、模块及*** |
CN104243627A (zh) * | 2014-08-29 | 2014-12-24 | 华为技术有限公司 | 一种域名解析方法、装置及*** |
WO2016062077A1 (zh) * | 2014-10-24 | 2016-04-28 | 中兴通讯股份有限公司 | 重定向到Web页面的方法及装置 |
CN104468865A (zh) * | 2014-12-25 | 2015-03-25 | 北京奇虎科技有限公司 | 域名解析控制、响应方法及相应的装置 |
CN104917838A (zh) * | 2015-06-12 | 2015-09-16 | 南京创维信息技术研究院有限公司 | 一种路由重定向的实现方法及*** |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112040027A (zh) * | 2020-09-14 | 2020-12-04 | 网易(杭州)网络有限公司 | 一种数据处理的方法及装置、电子设备、存储介质 |
CN112230927A (zh) * | 2020-09-17 | 2021-01-15 | 贝壳技术有限公司 | 一种文件重定向方法、代码加载控制方法及装置 |
CN116170409A (zh) * | 2023-02-21 | 2023-05-26 | 江苏云涌电子科技股份有限公司 | 一种基于虚拟域名的sd-wan网络地址规划*** |
CN116170409B (zh) * | 2023-02-21 | 2023-07-11 | 江苏云涌电子科技股份有限公司 | 一种基于虚拟域名的sd-wan网络地址规划*** |
Also Published As
Publication number | Publication date |
---|---|
CN107613037A (zh) | 2018-01-19 |
CN107613037B (zh) | 2021-11-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2019052058A1 (zh) | 一种域名重定向方法和*** | |
US10212124B2 (en) | Facilitating content accessibility via different communication formats | |
US11461402B2 (en) | Routing based request correlation | |
US9800539B2 (en) | Request routing management based on network components | |
US9160703B2 (en) | Request routing management based on network components | |
US9294391B1 (en) | Managing network computing components utilizing request routing | |
US10263950B2 (en) | Directing clients based on communication format | |
CN106790758B (zh) | 一种访问nat网络内部的网络对象的方法及装置 | |
US11057298B2 (en) | Providing differentiated service to traffic flows obscured by content distribution systems | |
US20120191769A1 (en) | Site-aware distributed file system access from outside enterprise network | |
WO2017161965A1 (zh) | 一种动态域名***dns重定向方法、装置及*** | |
US20190394088A1 (en) | Network device configuration versioning | |
CN113194099B (zh) | 一种数据代理方法及代理服务器 | |
GB2555108A (en) | Improvements in and relating to network communications | |
US11102105B2 (en) | Service integrated domain name server | |
US10958580B2 (en) | System and method of performing load balancing over an overlay network | |
CN116471255A (zh) | 一种基于云服务器的内网穿透方法及架构*** | |
CN103825941A (zh) | 对等网络中业务数据的转发控制方法及装置 | |
Kimmatkar et al. | Applications sharing using binding server for distributed environment | |
CN116545980A (zh) | 一种基于dns代理解析分流方法和*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17925014 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 17925014 Country of ref document: EP Kind code of ref document: A1 |