Message processing method, message processing device and access device

Abstract

The application provides a message processing method, a message processing device and an access device, and belongs to the technical field of communication. The message processing method comprises the following steps: an access device receives a message from a first terminal through a controlled port of which a Portal authentication function is started; a category of the message of the first terminal is marked according to a marking rule stored in a hardware list; and the message is processed according to the category of the message and a control rule stored in the hardware list, wherein the control rule is a rule for controlling a message flow direction, and the control rule comprises a category rule defined based on the category. The message processing method can improve the machine capacity of the access device.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a message processing method, a message processing apparatus, and an access device. Background Technology

[0002] With the continuous development of network technology, information security issues have become increasingly prominent. If the legitimacy of terminals accessing the network is not checked, any terminal that can connect to the switch can freely access any resource on the network, offering absolutely no security. To improve network security, portal websites are typically used to check the legitimacy of accessing terminals. Portal authentication, also known as Web (browser) authentication, is a method of network access authentication using a browser based on the Portal protocol.

[0003] Some access devices, such as routers, can implement packet blocking or allowing during Portal authentication using pure software. Other access devices, such as switches, require hardware implementation because most packets do not enter the software layer. For access devices using hardware to implement Portal authentication, this is generally based on Access Control Lists (ACLs) or Policy Control Lists (PCLs) (hereinafter referred to as hardware lists). Specifically, the access device uses ACL entries or PCL entries (hereinafter referred to as list entries) to block or allow terminals. When the access device enables Portal authentication, it consumes a large number of list entries. It should be understood that for most access devices, the number of hardware list entries is limited, making it difficult to meet the requirements of large-scale device support.

[0004] Therefore, for access devices with a limited number of list entries, how to increase their capacity is a pressing technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a message processing method, message processing apparatus, and access device, which can increase the number of devices that can be connected to a switch with a limited list of entries.

[0006] In a first aspect, embodiments of this application provide a message processing method, comprising: an access device receiving messages from a first terminal through a controlled port with Portal authentication enabled; classifying the messages of the first terminal according to marking rules stored in a hardware list; processing the messages according to the message categories and control rules stored in the hardware list; the control rules are rules for controlling the flow of messages, and the control rules include category rules based on category definitions.

[0007] As can be seen, in this embodiment, the category rules in the hardware list are configured on a category-by-category basis, meaning one category corresponds to a set of rules defined based on that category. In related technologies, the hardware list of access devices is configured with rules based on MAC addresses, meaning one MAC address packet corresponds to a set of rules defined based on that MAC address. It should be understood that a packet of a category can originate from terminals with MAC address one, MAC address two, MAC address three, etc. Clearly, this embodiment configures fewer rules on a category-by-category basis. Furthermore, as the number of terminals increases, the difference in the number of rules required by the two methods will become increasingly significant. Therefore, this embodiment uses fewer entries in the hardware list. This allows for increased device capacity even with a limited number of switch entries.

[0008] Secondly, embodiments of this application provide a message processing apparatus, including: a receiving module, configured to receive messages sent by a first terminal through a controlled port with Portal authentication enabled; an access device configured with a hardware list, the hardware list being used to store rules; a marking module, configured to mark the message of the first terminal with a category according to the marking rules stored in the hardware list; and a processing module, configured to process the message according to the category of the message and the control rules stored in the hardware list, the control rules being rules for controlling the flow of messages, the control rules including category rules based on category definitions.

[0009] Thirdly, embodiments of this application provide an access device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any of the first aspects.

[0010] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0011] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1This is a diagram illustrating the architecture of a Portal authentication system provided in an embodiment of this application.

[0014] Figure 2 This is an interactive flowchart of a Portal authentication method provided in an embodiment of this application;

[0015] Figure 3 This is the flow chart of the message processing method provided in the embodiments of this application. Figure 1 ;

[0016] Figure 4 This is the flow chart of the message processing method provided in the embodiments of this application. Figure 2 ;

[0017] Figure 5 This is the flow chart of the message processing method provided in the embodiments of this application. Figure 3 ;

[0018] Figure 6 This is the flow chart of the message processing method provided in the embodiments of this application. Figure 4 ;

[0019] Figure 7 This is the flow chart of the message processing method provided in the embodiments of this application. Figure 5 ;

[0020] Figure 8 This is an interactive flowchart of a message processing method provided in an embodiment of this application;

[0021] Figure 9 This is a schematic diagram illustrating the process of an access device processing a message from terminal X when the TTI (Time Interval) is not yet complete, as provided in an embodiment of this application.

[0022] Figure 10 This is a schematic diagram illustrating the process of the access device, as provided in this application embodiment, processing the message of terminal X when the TTI is full;

[0023] Figure 11 This is a schematic diagram of the structure of a message processing device provided in an embodiment of this application. Detailed Implementation

[0024] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0025] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0026] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner. The embodiments of this application involve the following technical terms:

[0027] (I) An ACL (Access Control List) is a chip logic within a switch used to specify the forwarding behavior of packets based on matching conditions. It is relatively expensive and has a limited number of entries (currently popular switch chips have several thousand ACL entries). An ACL consists of a series of rules. Each rule is a statement that allows, denies, or performs other actions, declaring the matching conditions and behavior (such as dropping or allowing) for a packet. Conditions can include the packet's source address, destination address, port number, etc. The switch matches packets based on these rules, controlling the incoming and outgoing packets at its ports.

[0028] An ACL consists of three parts: the Tunnel Termination Interface (TTI), the Ingress Policy Control List (IPCL), and the Egress Policy Control List (EPCL). In addition, the switch also has a Forwarding Database (FDB). The packet flow within the switch is: TTI → IPCL → FDB → EPCL. For example, the ACL connects to the FDB through the Bridge Engine to direct packets to the FDB.

[0029] Among them, TTI and FDB have the function of adding tags to packets with specific source MAC addresses, such as adding IDs. IPCL and EPCL have the function of forwarding and dropping packets, with the forwarding function also known as the allow function. In addition, IPCL also has the functions of copying (that is, sending packets to the CPU and forwarding them) and trapping (that is, sending packets to the CPU without forwarding them).

[0030] (ii) FDB, also known as the MAC address forwarding table, is a chip logic within the switching chip used to quickly locate the packet forwarding port. It is relatively inexpensive and has a large number of entries (currently popular chips have more than 100,000 FDB entries). Each entry consists of the terminal's MAC address, the switch port connected to the terminal, and the VLAN ID of that port. When the switch receives a data packet, it matches the packet's destination MAC address with the MAC address forwarding table entries stored in the switch and forwards the packet to the port specified in the matching entry.

[0031] (iii) Portal Protocol: An access authentication protocol used for exchanging authentication information between the Portal server and access devices (such as switches).

[0032] (iv) Portal Authentication: This method uses a browser for network access authentication according to the Portal protocol. When a terminal connects to a WLAN access device using Portal authentication, a Portal page automatically pops up on the terminal, prompting the user to enter their account, password, and other user information. The terminal then sends authentication information containing this user information to the Radius server, which authenticates the terminal based on this information. Portal authentication can be completed using a browser, eliminating the need for a separate client on the terminal; therefore, it is considered a method of internet access authentication.

[0033] (v) Certified and Uncertified Terminals

[0034] Terminals that pass the Portal authentication process are considered authenticated terminals, while terminals that fail the Portal authentication process or have not yet initiated a Portal authentication request (such as newly connected terminals or terminals that have already connected but have not yet initiated an authentication request) are considered unauthenticated terminals.

[0035] Please refer to Figure 1 , Figure 1 This is a diagram illustrating the architecture of a Portal authentication system provided in an embodiment of this application.

[0036] Figure 1 The system architecture shown is also known as a browser / server (B / S) architecture, used for portal authentication of accessing terminals to ensure that authorized resources on the network can only be accessed by authorized terminals. This architecture includes one or more terminals, access devices, a portal server, and a RADIUS server.

[0037] In this context, the terminal is a device with a browser running the HTTP protocol installed. The terminal uses the browser to initiate access requests (i.e., HTTP messages to access the network) to access network resources.

[0038] When a terminal is unauthenticated, its access request to the network via a browser will trigger Portal authentication on the access device. It's important to note that although the destination address of this access request (e.g., the destination IP pointing to the network) is specified, the access device will block the request because the terminal is unauthenticated. In this case, the unauthenticated terminal will be unable to access the network.

[0039] After intercepting the terminal's access request, the access device redirects the terminal's access request to the Portal server to achieve Portal authentication; and connects the authenticated terminal to the network to fulfill the terminal's access to network resources in the network.

[0040] The Portal server receives access requests from terminals during the Portal authentication process and provides an authentication interface to obtain authentication information such as usernames and passwords entered by the terminal user. It also interacts with access devices to exchange the obtained authentication information. Based on this, the access device forwards the authentication information obtained by the Portal server to the Radius server to achieve Portal authentication.

[0041] The RADIUS server is used to perform Portal authentication on the terminal based on the authentication information during the Portal authentication process.

[0042] For example, the terminal can be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, etc., that can run a browser with the HTTP protocol. This application embodiment does not impose special limitations on the specific form of the device. The access device can be a switch, router, etc., a WLAN device that can run the Portal protocol and implement Portal authentication based on hardware. This application embodiment does not impose special limitations on the specific form of the device.

[0043] It should be noted that, Figure 1The Portal authentication system shown is merely an illustration. In other system architectures, the Portal server and / or Radius server can be built into the access device.

[0044] The following is combined Figure 2 The specific process of Portal authentication is described exemplarily.

[0045] Please refer to Figure 2 , Figure 2 This is an interactive flowchart illustrating a Portal authentication method provided in an embodiment of this application. It should be understood that this Portal authentication method can be applied to... Figure 1 The system architecture shown is used to implement Portal authentication for authentication terminals. Figure 2 The Portal authentication method shown may include the following steps:

[0046] S201, Enable the Portal authentication function of the controlled port on the access device and configure basic rules.

[0047] Here, basic rules refer to rules that apply to all terminals accessing the device. Conversely, rules defined for a specific terminal and applicable only to that terminal are called specific rules. For example, the basic rules mentioned above include, but are not limited to, ACL1 to ACL4 in Table 1, and the specific rules mentioned above include, but are not limited to, ACL5 to ACL10.

[0048] S202, the terminal initiates an ARP message or connects for the first time.

[0049] S203, the access device determines that the terminal is a new access terminal and adds the terminal's rules.

[0050] In this context, "terminal rules" refers to specific rules defined for a terminal. Examples include ACLs 5 to ACL 6 and ACLs 8 to ACL 9 in Table 1.

[0051] S204, the terminal sends an HTTP message to the access device to access the network, and the access device receives the HTTP message sent by the terminal to access the network through the controlled port.

[0052] It should be understood that an HTTP message that accesses the network refers to an HTTP message whose destination address points to the network. For example, the destination IP of an HTTP message that accesses the network points to the network, that is, the destination IP is the network IP.

[0053] S205, the access device sends a redirection message to the terminal, and the terminal receives the redirection message from the access device accordingly.

[0054] The redirect message is used to notify the terminal to redirect HTTP messages to the Portal server.

[0055] After receiving an HTTP message requesting network access, the access device intercepts the message by spoofing the destination address the terminal intends to access and then sends a redirection message to the terminal. It should be noted that step S205 is executed by the access device's CPU; therefore, the access device sends the received HTTP message to the CPU for processing.

[0056] S206, the terminal provides authentication information to the Portal server.

[0057] Specifically, based on the received redirection message, the terminal initiates an HTTP message with a destination IP address pointing to the Portal server to access the authentication interface provided by the Portal server to the terminal's browser. This authentication interface is used to obtain the authentication information entered by the user. After obtaining the authentication information, the terminal sends it to the Portal server, thereby realizing the exchange of authentication information.

[0058] S207, the Portal server sends the received authentication information to the access device.

[0059] S208, the access device forwards the authentication information to the Radius server.

[0060] S209, the Radius server performs Portal authentication on the terminal based on the authentication information and obtains the authentication result.

[0061] S210, the Radius server sends the authentication result back to the access device. S211, if the authentication result shows that the terminal has passed the Portal authentication, the access device updates the terminal's rules.

[0062] It should be understood that once a terminal is authenticated through the Portal, it is considered an authenticated terminal. To ensure its free access to network resources, the updated rules include allowing the terminal's packets, such as ACL7 and ACL10 in Table 1.

[0063] S212, the access device sends the authentication result to the Portal server.

[0064] S213, the Portal server returns the authentication result to the terminal.

[0065] It should be noted that, Figure 2 The interactive flow of the Portal authentication method shown is as follows: Figure 1 The architecture shown is described using an example. Figure 1 When the architecture shown changes, the Portal authentication method described above can be adapted accordingly, which will not be elaborated here.

[0066] It should be noted that, in order to ensure that unauthenticated terminals (taking terminals M and N as examples) can be authenticated normally, the above access devices need to be configured with at least the ACL rules shown in Table 1 below.

[0067] Table 1

[0068]

[0069] The following description uses terminal M as an example to illustrate each ACL rule in Table 1 above. Rules involving terminal N can be understood by referring to this explanation.

[0070] As can be seen from the above, the access device initiates Portal authentication upon receiving an HTTP message from terminal M. In other words, the HTTP message is the entry point for the access device to start Portal authentication; the access device is triggered to begin Portal authentication by the HTTP message. DHCP, DNS, and ARP messages are messages that the terminal must send before initiating the HTTP message. Therefore, to ensure that terminal M can successfully initiate an HTTP message to trigger Portal authentication, Table 1 contains rules that allow DHCP messages (ACL1), DNS messages (ACL2), and ARP messages (ACL3).

[0071] In addition, ACL5 is configured in Table 1 above. Taking ACL5 as an example, the HTTP packet of terminal M (with a destination IP pointing to the network) is matched to ACL5 by the access device and sent to the CPU of the access device for Portal authentication. It should be noted that the HTTP packet of terminal M also goes through the following process before it is sent to the CPU of the access device: TTI→IPCL→FDB→EPCL. Therefore, to ensure that the HTTP packet of terminal M can be allowed to pass to the CPU of the access device when it reaches EPCL, ACL6 is also configured in Table 1 above. Similarly, ACL8 and ACL10 are configured for terminal N in Table 1.

[0072] In addition, ACL4 is also configured in Table 1 above. HTTP messages from terminal M need to be redirected to the Portal server via the access device to prompt the user that Portal authentication is required before accessing the network. In this case, terminal M needs to redirect HTTP messages originating from the Portal server to the Portal server's authentication interface. This message is matched to ACL4 when passing through the access device and is thus allowed, ensuring the continued progress of Portal authentication.

[0073] After terminal M is successfully authenticated, in order to ensure that the authenticated terminal M can freely access the network, the rules for terminal M need to be updated. As shown in Table 1, the updated ACL rule for the terminal is ACL7 as shown in Table 1, so as to ensure that packets from the authenticated terminal M can match ACL7 when passing through the access device and thus be allowed.

[0074] As shown in Table 1, in the prior art, packet control is achieved by defining ACL rules using MAC addresses. It should be understood that different terminals have different MAC addresses. Therefore, the aforementioned prior art method of defining ACL rules using MAC addresses is insufficient for rules involving source MAC addresses (such as...). Figure 1 In this example, ACLs 5 through ACL 10 are rules related to the source MAC address. Each source MAC address requires a specific set of rules. Taking Table 1 as an example, since there are two terminals, two sets of specific rules need to be defined for each source MAC address: ACLs 5 through ACL 7 for terminal M and ACLs 8 through ACL 10 for terminal N. This method of defining ACL rules consumes a large number of list entries, reducing the number of connected devices.

[0075] Based on this, embodiments of this application provide a message processing method. In this method, messages from different types of terminals are labeled with different categories, wherein messages from all terminals of the same type are labeled with the same category. Different rules are used to control messages of different categories. That is, this message processing method configures rules on a category-by-category basis, with each category corresponding to a set of rules defined for that category.

[0076] It should be understood that a packet of a certain category can originate from terminals such as MAC address one, MAC address two, and MAC address three. In this embodiment, for packets of the same category, only one set of rules is needed for packets from multiple terminals, while related technologies require a separate set of rules for each terminal's packets. Clearly, this embodiment configures fewer rules per terminal category, thus requiring fewer entries in the hardware list. Therefore, it is possible to increase the number of connected devices with a limited number of switch entries.

[0077] The following is combined Figures 3 to 10 The message processing method provided in the embodiments of this application will be described in detail.

[0078] Please refer to Figure 3 , Figure 3 The flowchart of the message processing method provided in the embodiments of this application Figure 1 This message processing method is applied to access devices that implement Portal authentication based on hardware, such as... Figure 1The access device shown is an example. For instance, this access device can be a switch; subsequent embodiments will use a switch as an example for illustration. Figure 3 The message processing method shown includes the following steps S301 to S303.

[0079] S301, the access device receives messages from the first terminal through the controlled port with the Portal authentication function enabled.

[0080] For example, the first terminal can send messages to the access device.

[0081] The aforementioned controlled port can be a port or interface of the access device. Here, "port" refers to the physical port of the access device; "interface" refers to the VLAN interface of the access device. Enabling the Portal authentication function means enabling the Portal authentication function on the controlled port.

[0082] Access devices have hardware lists, such as TTI, IPCL, and EPCL under ACLs, as well as FDBs, used to store rules. The rules stored in the hardware lists will be described in detail later; they will not be covered here.

[0083] It should be understood that the aforementioned first terminal may be an unauthenticated terminal or an authenticated terminal. Based on this, the messages it sends include, but are not limited to, HTTP messages. For example, the messages may also be DNS messages, DHCP messages, ARP messages, and interaction messages between the authenticated terminal and the server during the Portal authentication process.

[0084] S302, according to the marking rules stored in the hardware list, marks the message category of the first terminal.

[0085] The tagging rules for hardware list storage will be described in detail later, and will not be elaborated here. This application involves three categories: a first category, a second category, and a third category. These categories are used to identify messages from different types of terminals. Specifically, the first category identifies messages sent by unauthenticated terminals that do not require blocking; the second category identifies messages sent by authenticated terminals; and the third category identifies messages sent by unauthenticated terminals that require blocking. It should be understood that messages from different types of terminals have different identifiers. Based on these different identifiers, different operations can be performed on messages from different terminals to control their different flow directions. This will be described in detail later through embodiments; here, the focus is on illustrating the content of each category.

[0086] For example, the first category can be ID B, the second category can be ID C, and the third category can be ID A. Subsequent embodiments will be described using this example. In other embodiments, the labels used for these three categories can be interchanged; for example, the first category can be ID A, the second category can be ID B, and the third category can be ID C. Of course, the first category can also be labeled in other forms, such as ID* or ID!, as long as the identification function can be achieved.

[0087] S303 processes the message according to the type of the message from the first terminal and the control rules stored in the hardware list.

[0088] Control rules are rules that control the flow of packets (such as dropping, allowing, or redirecting to the CPU). Control rules include category rules based on category definitions. In addition to category rules, control rules can also include some rules that are not based on category definitions, such as the rules related to ACL1 to ACL4 in Table 1.

[0089] As can be seen, in this embodiment, different categories are used to identify packets from different terminals. This allows packets to be processed based on their tagged category, rather than their address. It should be noted that the category rules in the hardware list are configured on a category-by-category basis; that is, one category corresponds to one set of rules defined based on that category. In contrast, in existing technologies, the hardware list of access devices is configured using MAC addresses; that is, a packet with one MAC address corresponds to one set of rules defined based on that MAC address. It should be understood that a packet in a category can originate from terminals with MAC address one, MAC address two, MAC address three, etc. In this embodiment, only one set of rules is needed for packets from multiple terminals within the same category, while existing technologies require a separate set of rules for each terminal's packet. Clearly, this embodiment, by configuring rules on a category-by-category basis, requires fewer rules. Furthermore, as the number of terminals increases, the difference in the number of rules required by the two methods will become increasingly significant. Therefore, this embodiment uses fewer entries in the hardware list. This allows for increased throughput even with a limited number of switch entries.

[0090] The aforementioned first terminal can be either an unauthenticated terminal or an authenticated terminal. Unauthenticated terminals fall into two categories:

[0091] In the first scenario, the first terminal can be a new terminal that is accessing the network for the first time. Naturally, it has not yet been authenticated. In this embodiment of the application, the unauthenticated terminal that is accessing the network for the first time is referred to as the new access terminal.

[0092] In the second scenario, the first terminal can be a terminal that has previously accessed the network (i.e., has already sent packets) but has not yet been authenticated or has not successfully authenticated. It should be noted that when a new terminal accesses the network or receives its ARP packets, the access device has the function of learning its MAC address. Learning a MAC address refers to the process by which the access device obtains the MAC address of the new terminal from the packets sent by the new terminal and stores it in the MAC address forwarding table; this process can also be called the sensing process. The MAC address forwarding table records one or more terminals (including unauthenticated terminals and authenticated terminals) that the access device has sensed. Therefore, for the first terminal in the second scenario described above, this embodiment refers to it as an unauthenticated terminal sensed by the access device.

[0093] Figure 3 The message processing method shown varies depending on the first terminal. The following describes how... Figures 4 to 7 The embodiments are described separately.

[0094] Please refer to Figure 4 , Figure 4 The flowchart of the message processing method provided in the embodiments of this application Figure 2 .

[0095] When the first terminal is a new access terminal that is not fully occupied in the first list (e.g., TTI), since the first list is not full, it indicates that there are not many terminals waiting to be authenticated or currently being authenticated in the first list, and the access device has the capacity to control the new access terminal to perform Portal authentication. Therefore, when the first terminal is a new access terminal that is not fully occupied in the first list, the message it sends is a non-blocking message. In this case, the above S302 can be implemented by the following S302a, and the above S303 can be implemented by the following S303a, so that the message of the first terminal is marked as the first category, thereby matching the second rule and controlling it to perform Portal authentication.

[0096] It should be noted that the first list is a sublist of the hardware list. The first list is used to store the marking rules for marking messages of the first category, such as the first marking rule for marking messages of the first terminal of the first category. For example, the first list is TTI.

[0097] S302a, according to the first marking rule stored in the first list, the message of the first terminal is marked with the first category.

[0098] The aforementioned first marking rule may include: adding a first category to the packets of the first terminal. For example, taking the MAC address of the first terminal as the first MAC address, the first marking rule may be: marking the packets with the source MAC address as the first MAC address as the first category.

[0099] S303a processes messages of the first category according to the second rule stored in the hardware list.

[0100] The second rule is used to control messages to implement Portal authentication. It should be understood that the second rule is part of the control rules. The second rule includes rules based on the first category definition, and may also include rules not based on a category definition.

[0101] For example, the second rule may include: allowing ARP packets (Rule 1), allowing DNS packets (Rule 2), allowing DHCP packets (Rule 3), allowing packets whose destination IP points to the Portal server (Rule 4), allowing at least some packets marked as Category 1 (Rule 5); and redirecting at least some packets marked as Category 1 to the CPU of the access device (Rule 6). It is evident that this second rule is a basic rule that can be configured when enabling the Portal authentication function of the controlled port. It should be understood that Rules 5 and 6 are both Category 1 rules, while Rules 1 to 4 are rules not defined based on categories. As can be seen from the specific content of each rule in the above second rule, this second rule is a basic rule that can be configured when enabling the Portal authentication function of the controlled port.

[0102] It should be noted that HTTP messages are the condition that triggers the access device to perform Portal authentication. To achieve Portal authentication, at least some of the aforementioned messages must include HTTP messages. It should be understood that at least some messages marked as Category 1 can be all messages marked as Category 1 (naturally including HTTP messages), or a subset of messages marked as Category 1 that includes HTTP messages, or only HTTP messages marked as Category 1. When at least some messages can be only HTTP messages, it means that the access device only redirects HTTP messages marked as Category 1 to the CPU. Messages marked as Category 1 but unrelated to Portal authentication will be discarded after processing by the second rule. This avoids sending a large number of other messages unrelated to Portal authentication to the CPU, thereby reducing CPU load and improving access device performance.

[0103] It should be understood that when at least some of the messages marked as Category 1 are HTTP messages marked as Category 1, or are some messages marked as Category 1 that include HTTP messages, if there are no rules to control other messages marked as Category 1, it is easy for messages to be missed. Based on this, the above-mentioned second rule may also include: discarding other messages marked as Category 1 (Rule 7).

[0104] Figure 4In the message processing method shown, if the first terminal is a newly accessed terminal when the first list is not full, the message is labeled with the first category based on the first labeling rule. As can be seen from the explanations of each rule in Table 1 above, based on... Figure 4 The second rule configured in the illustrated embodiment processes messages marked as the first category, thereby enabling the Portal authentication function of the first terminal.

[0105] visible, Figure 4 In this embodiment, to achieve Portal authentication for the first terminal, the configuration of a first marking rule and a second rule is involved. The first marking rule is a specific rule for the first terminal, and the second rule is a basic rule. It should be understood that since a specific rule is defined for a particular terminal, one specific rule needs to be defined for each terminal, and the number of specific rules increases with the number of unauthenticated terminals; while the number of basic rules is fixed because they are not defined for any particular terminal.

[0106] Figure 4 In the message processing method shown, an unauthenticated terminal involves only one specific rule, such as the first terminal involving only the first marking rule. If the existing MAC address method is used, although it is not necessary to configure the rule corresponding to the first marking rule, it is necessary to configure the rules corresponding to the first category rules (rules five and six) in the second rule (such as ACL5 and ACL6 in Table 1). Therefore, an unauthenticated terminal needs to configure two specific rules, that is, one MAC address needs to configure two specific rules. Clearly, as the number of unauthenticated terminals on the access device increases, the number of specific rules required to configure using the MAC address method is greater than that required using the MAC address method. Figure 4 A categorized approach requires a greater number of specific rules to configure, thus consuming more entries in the hardware list. Therefore, Figure 4 The illustrated embodiment uses fewer entries in the hardware list. Therefore, the number of devices that can be connected can be increased even with a limited number of entries in the switch's list. Specifically, the maximum authentication rate and the number of simultaneous authentications of access devices can be increased.

[0107] It should be noted that, Figure 4In the message processing method shown, for the case where the first terminal is a newly accessed terminal when the first list is not full, the messages sent by it are labeled with the first category according to the first labeling rule. However, as can be seen from the specific content of the first labeling rule, the condition of the first labeling rule is that the messages are from the first terminal. This means that as long as the message is from the first terminal, it can match the first labeling rule and be labeled with the first category. For example, messages from the newly accessed first terminal when the first list is full or not can match the first labeling rule and be labeled with the first category. Obviously, relying solely on the first labeling rule is insufficient to label messages from the newly accessed first terminal when the first list is not full with the first category.

[0108] To ensure that the access device labels the messages sent by the first terminal that newly accesses the network when the first list is not full with the first category, please continue to refer to... Figure 4 Prior to S302a, Figure 4 The message processing method shown also includes:

[0109] S401, the first terminal is identified as a newly accessed terminal.

[0110] Optionally, the access device is configured with an authentication list, which is a software list maintained by the access device to record the MAC addresses of one or more terminals that the access device has detected. These detected terminals include unauthenticated terminals and / or authenticated terminals. In this list, the MAC addresses of unauthenticated terminals and authenticated terminals have different markers to distinguish whether their corresponding terminals are unauthenticated or authenticated. This marking can be done by the FDB (Functional Database). The access device receives a packet carrying the MAC address of the first terminal. By obtaining the MAC address of the first terminal carried in the packet and determining whether the MAC address belongs to an unauthenticated terminal recorded in the authentication list, or whether it belongs to a terminal recorded in the authentication list, the access device can determine whether the first terminal is a new access terminal. If the MAC address of the first terminal does not belong to an unauthenticated terminal recorded in the authentication list, or does not belong to a terminal recorded in the authentication list, then the first terminal is determined to be a new access terminal.

[0111] It should be understood that in other embodiments, the access device may not execute the above-described S401, but instead other devices may execute it to determine whether the first terminal is a new access terminal, and when the first terminal is determined to be a new access terminal, send an instruction to the access device so that the access device executes the following S402 when the first terminal is a new access terminal.

[0112] S402, Add the first tag rule to the first list.

[0113] It should be understood that adding the first marker rule to the first list in S402 will only be successful if the first list is not full. Therefore, Figure 4 In the packet processing method shown, the first marking rule is successfully added to the first list only when the first terminal is a newly accessed terminal and the first list is not full. It should be understood that only when the first marking rule is successfully added to the first list will the first list contain first marking rules that can be matched by the packets of the first terminal, allowing the access device to mark the packets of the first terminal with the first category based on the first marking rule. Therefore, packets sent by newly accessed first terminals when the first list is not full are marked with the first category because there is a matching first marking rule in the first list. Conversely, packets sent by newly accessed first terminals when the first list is full are not marked with the first category because there is no matching first marking rule in the first list.

[0114] It is evident that although the first marking rule alone cannot label the packets of a newly connected first terminal with the first category when the first list is not full, the timing of adding the first marking rule ensures that packets sent by a newly connected first terminal when the first list is not full will be labeled with the first category. Therefore, through the implementation of S401 and S402 above, the access device achieves the ability to label packets sent by a newly connected first terminal with the first category when the first list is not full.

[0115] Furthermore, in this embodiment, the access device adds a first tagging rule to the first list when the first terminal first accesses the network. Thus, before the first terminal is authenticated, all packets sent by the first terminal, whether initially or subsequently, can be tagged with the first category based on the first tagging rule. In other words, all packets sent by the first terminal before authentication will be tagged with the first category, ensuring they match a rule in the second set of rules and are controlled, preventing packets from being missed and thus reducing network security. When the packet is an HTTP packet, it will match rule six in the second set of rules, thereby enabling Portal authentication.

[0116] It should be understood that if the first list is full, adding the first marker rule to the first list in S402 may fail. To maximize the success rate of adding the first marker rule, the following aging mechanism can be used to improve the success rate in case of failure:

[0117] In some embodiments, the first list stores multiple fourth marking rules and the addition time of the fourth marking rules. The fourth marking rule includes: marking a first category for messages sent by the second terminal; the second terminal is one of the unauthenticated terminals detected by the access device. It should be understood that at the same time, the multiple fourth marking rules stored in the first list are the respective fourth marking rules corresponding to the multiple unauthenticated terminals (i.e., multiple second terminals) detected by the access device, with each fourth marking rule corresponding to one second terminal. The principle of adding the fourth marking rules for these second terminals is similar to that of the first marking rules. This embodiment frees up usable list entries by deleting the outdated fourth marking rules from these fourth marking rules, as detailed below:

[0118] Optionally, S402 includes: adding a first tag rule to the first list; if adding the first tag rule to the first list fails, deleting the fourth tag rule that meets the preset conditions from among the multiple fourth tag rules; wherein the preset conditions include: the difference between the current time and the addition time (referred to as the addition duration) is greater than a preset time threshold; and adding the first tag rule to the fourth list again.

[0119] It should be understood that for fourth-marking rules whose addition time exceeds a preset time threshold, they occupy a considerable amount of time in the first list, but their corresponding second terminals (referred to as deleted terminals) have not yet initiated HTTP messages to trigger Portal authentication. This indicates that the deleted terminals may no longer have network access needs and therefore no longer require Portal authentication. In other words, fourth-marking rules that meet the preset conditions are considered outdated. Therefore, in this embodiment, when adding a first-marking rule fails, those outdated fourth-marking rules are deleted to free up list entries for newly accessed first terminals that are more likely to have network access needs.

[0120] The preset time threshold can be set according to the specifications of different models and chips. For example, the preset time threshold can be 3 minutes.

[0121] In other embodiments, if adding a first tagging rule to the first list fails, any one of the multiple fourth tagging rules can be directly deleted, or the fourth tagging rule with the earliest addition time can be deleted. This application does not specifically limit this.

[0122] It should be understood that in the above embodiments, if there are no expired fourth tag rules, then there will be no fourth tag rules that can be deleted, and thus, no list entry will be released. In this case, the steps of deleting the fourth tag rules that meet the preset conditions from among multiple fourth tag rules can be repeated until the first tag rule is successfully added to the first list again.

[0123] Optionally, in some possible implementations, after deleting the fourth-marking rules that satisfy the preset conditions from among multiple fourth-marking rules, Figure 4 The message processing method shown may also include:

[0124] Send an ARP request message to the deleted terminal. The deleted terminal is the second terminal corresponding to the deleted fourth marking rule.

[0125] For example, an ARP request message is used to request an ARP reply message from the deleted terminal.

[0126] It should be noted that after deleting the fourth tagging rule that meets the preset conditions, the released list entries are occupied by the first tagging rule. At this time, the first list may be full again, with no available list entries. Therefore, optionally, when the time for deleting the fourth tagging rule that meets the preset conditions (hereinafter referred to as the deletion time) reaches the preset time, the step of sending an ARP request message to the second terminal corresponding to the deleted fourth tagging rule can be executed.

[0127] The preset duration can be set according to the specifications of different models and chips. For example, the preset duration can be 1 minute.

[0128] Specifically, a timer can be started simultaneously with deleting the fourth tagging rule that meets the preset conditions to time the deletion. Once the preset deletion time has elapsed, an interrupt signal is output, and in response to this interrupt signal, the step of sending an ARP request packet is executed. Of course, after deleting the fourth tagging rule that meets the preset conditions, there may be cases where other terminals authenticate successfully and release the list entry. In this case, it is still feasible to execute the step of sending an ARP request packet immediately after deleting the fourth tagging rule that meets the preset conditions.

[0129] In this implementation, although the deleted fourth labeling rule has been stored for a long time, the deleted terminal may still have network access needs, although its network access needs are not as urgent as those of the first terminal. Therefore, after ensuring that the first labeling rule has available list entries, an ARP request packet is proactively sent to the deleted terminal to obtain its ARP response packet, thereby detecting the deleted terminal's access and adding the fourth labeling rule to it, thus preparing for enabling Portal authentication.

[0130] Based on this, in some embodiments, after sending an ARP request message to the deleted terminal, Figure 4 The message processing method shown may also include: receiving ARP reply messages sent by the deleted terminal; adding the fourth tagging rule corresponding to the deleted terminal to the first list, thereby preparing for enabling Portal authentication.

[0131] Please refer to Figure 5 , Figure 5 The flowchart of the message processing method provided in the embodiments of this application Figure 3 .

[0132] If the first terminal is an unauthenticated terminal already detected by the access device, it indicates that the first terminal is a previously accessed unauthenticated terminal and not a newly accessed terminal. According to... Figure 4 As shown in the embodiment, the first marking rule is added when the first terminal first accesses the network. Therefore, if the first terminal is an unauthenticated terminal already detected by the access device, the first marking rule is already stored in the first list. The access device can directly mark it as a first category based on the first marking rule without having to occupy the first list to add a first marking rule for the first terminal. Therefore, there is no need to consider the situation where the first terminal's packets cannot be processed due to the first list being full.

[0133] Therefore, in the case where the first terminal is an unauthenticated terminal already detected by the access device, the messages it sends are non-blocking messages. In this situation, the aforementioned S302 can... Figure 5 As shown in S302a, the above-mentioned S303 can be implemented by... Figure 5 The S303a implementation shown is designed to mark the messages of the first terminal as a first category so that they can be matched with a second rule to control its Portal authentication.

[0134] It should be noted that, Figure 5 S302a and S303a shown are respectively with Figure 4 S302a and S303a are the same as shown, and will not be described again here.

[0135] In practice, the access device can determine whether the first terminal is an unauthenticated terminal detected by the access device by checking whether its MAC address belongs to the MAC address of an unauthenticated terminal recorded in the authentication list. If the MAC address of the first terminal belongs to the MAC address of an unauthenticated terminal stored in the authentication list, it indicates that the first terminal is an unauthenticated terminal detected by the access device.

[0136] It can be seen that, compared to Figure 4 In the embodiments shown, Figure 5In the illustrated embodiment, for the case where the first terminal is an unauthenticated terminal detected by the access device, since the first list already stores the first marking rules, the message can be directly marked with the first category based on the first marking rules. It should be understood that messages sent by the unauthenticated first terminal will be marked with the first category when passing through the access device, thus matching a rule in the second set of rules and being controlled, preventing message leakage and reducing network security. Simultaneously, when the message is an HTTP message, it will match rule six in the second set of rules, thereby enabling Portal authentication.

[0137] Please continue to refer to Figure 5 In some embodiments, after S303a, Figure 5 The message processing method shown may also include:

[0138] If the first terminal's Portal authentication is successful (hereinafter referred to as successful authentication), a second marking rule is added to the hardware list. This second marking rule includes marking the first terminal's messages with a second category.

[0139] Specifically, the second marking rule can be: marking the message whose source MAC address is the first MAC address with ID C.

[0140] In this embodiment, after the first terminal is authenticated, in order to ensure that the authenticated first terminal can freely access the network without restriction, a second marking rule is added to the hardware list to ensure that subsequent packets sent by the first terminal can be marked with a second category different from the first category, and thus match the rule defined for the packets marked as the second category (i.e., the second category rule mentioned later) and be allowed to pass.

[0141] Optionally, if the first terminal authentication is successful, the first marking rule is deleted. It should be understood that the purpose of configuring the first marking rule is to jointly block packets from unauthenticated terminals with the second rule, thereby preventing packets from being passed through unauthenticated terminals. Therefore, the first marking rule only functions during the Portal authentication phase and becomes useless after the first terminal authentication is successful. Based on this, in this embodiment, deleting the useless first marking rule after the first terminal authentication is successful frees up the list entries occupied by the first marking rule in the hardware list, thereby increasing the number of devices that can be connected.

[0142] Optionally, the first marking rule may not be deleted. That is, the second marking rule may still exist after the first marking rule is added, and this will not release any more list entries. In this case, the second marking rule needs to be set to have a higher priority than the first marking rule. This ensures that packets sent by the first terminal after successful authentication are marked with the second category instead of the first category. This avoids re-initiating Portal authentication after successful authentication, thus preventing the waste of access device CPU resources and preventing the phenomenon of successful authentication but denied access caused by the blocked authenticated terminal.

[0143] The following is combined Figure 6 , Figure 6 The flowchart of the message processing method provided in the embodiments of this application Figure 4 .

[0144] If the first terminal is an authenticated terminal, the messages it sends are non-blocking messages. According to... Figure 5 As can be seen from the embodiments, the access device adds a second marking rule to the first terminal when it passes authentication. Therefore, when the first terminal is an authenticated terminal, it indicates that the first terminal has passed authentication and the second marking rule is stored in the hardware list. In this case, the first terminal's message matches the second marking rule, and the access device executes... Figure 6 S302b and S303b are shown.

[0145] S302b, according to the second marking rule stored in the hardware list, marks the messages of the first terminal with a second category.

[0146] S303b processes second-category messages according to the second-category rules stored in the hardware list.

[0147] For example, the second category of rules includes allowing all packets marked as second category to pass. For instance, the hardware list stores second category rules. As can be seen from the specific content of the second category rules, they are basic rules shared by all terminals, rather than specific rules for a single terminal, and can be configured when enabling the Portal authentication function of the controlled port.

[0148] In this embodiment, when the first terminal is an authenticated terminal, its packets are labeled with a second category based on the second labeling rule. Packets labeled with the second category that match the second category rule are allowed to pass. Therefore, when packets sent by the authenticated first terminal pass through the access device, they match the second labeling rule and are labeled with the second category. Packets labeled with the second category that match the second category rule are allowed to pass. This ensures that the authenticated first terminal can access network resources normally.

[0149] It should be noted that, for Figure 6In the illustrated embodiment, during implementation, the access device can determine whether the first terminal is an authenticated terminal by judging whether its MAC address belongs to the MAC addresses of authenticated terminals stored in the authentication list. If the MAC address of the first terminal belongs to the MAC addresses of authenticated terminals stored in the authentication list, then the first terminal is an authenticated terminal.

[0150] It should be noted that, Figure 4 The illustrated embodiment focuses on the case where the first terminal is a newly accessed terminal when the first list is not yet full. The following description, in conjunction with... Figure 7 This section explains the case where the first terminal is a newly accessed terminal when the first list is full.

[0151] Please refer to Figure 7 , Figure 7 The flowchart of the message processing method provided in the embodiments of this application Figure 5 .

[0152] In the case where the first terminal is a new access terminal when the first list is full, since the first list is full, it indicates that there are many terminals waiting to be authenticated or currently being authenticated. The access device cannot process the packets of the new access terminal to control the new access terminal to perform Portal authentication. Therefore, in the case where the first terminal is a new access terminal when the first list is full, the packets it sends are packets that need to be blocked. In this case, the above-mentioned S302 can be implemented by the following S302c, and the above-mentioned S303 can be implemented by the following S303c, so as to achieve the blocking of the first terminal's packets.

[0153] S302c, according to the third marking rules stored in the hardware list, marks the messages of the first terminal as the third category.

[0154] Optionally, the third labeling rule includes: labeling messages originating from the controlled port with a third category.

[0155] As can be seen from the specific content of the third marking rule, the condition for the third marking rule is that the packet originates from the controlled port. This means that any packet originating from the controlled port can match the third marking rule. For example, a packet from an authenticated terminal originating from the controlled port can match the third marking rule and be marked as the third category. Similarly, packets from all unauthenticated terminals originating from the controlled port can match the third marking rule and be marked as the third category. Clearly, the third marking rule cannot only mark the packets of the first terminal newly connected when the first list is full as the third category, thus it cannot block packets from the first terminal newly connected when the first list is full.

[0156] To ensure that the access device only labels packets from newly accessed first terminals when the first list is full with the third category, thereby blocking such packets, in some embodiments, the priority of the third labeling rule can be set lower than the priority of the first and second labeling rules. This means that packets from the first terminal are labeled with the third category if the first terminal is a newly accessed terminal when the first list is full, and with the first or second category if the first terminal is not a newly accessed terminal when the first list is full. It should be noted that "the case where the first terminal is not a newly accessed terminal when the first list is full" refers to... Figures 4 to 6 The message processing method shown is as follows, in which... Figure 4 and Figure 5 In the case shown, it is marked as the first category, in Figure 6 The cases shown are labeled as the second category.

[0157] As can be seen, although the third marking rule alone cannot mark the packets of the newly accessed first terminal when the first list is full as a third category, in this embodiment, by setting the priority of the third marking rule to be lower than the priority of the first marking rule and the priority of the second marking rule, the packets of the first terminal can be marked as the third category instead of the first or second category when the first terminal is a newly accessed terminal when the first list is full. This enables the access device to mark the packets sent by the newly accessed first terminal when the first list is full as a third category.

[0158] For example, the priority of the third labeling rule is lower than the priority of the first labeling rule and the second labeling rule, so that when the access device's message is labeled as the first category or the second category, it is not labeled as the third category, thereby matching the second rule and being controlled for Portal authentication, or matching the second category rule and being allowed; when the first terminal's message is not labeled as the first category or the second category, it is labeled as the third category, thereby matching the third category rule and being discarded.

[0159] In other embodiments, to block packets from newly accessed first terminals when the first list is full, the content of a third marking rule can also be set to block packets from newly accessed first terminals after the first list is full. For example, the third marking rule can be: to mark packets from newly accessed terminals received by the controlled port after the first list is full as a third category. Packets marked as the third category can indicate that the packet was initiated by a newly accessed terminal after the first list was full. Such packets need to be blocked and are discarded by matching the third category rule. Compared with the previous embodiment, this embodiment needs to determine the following two conditions: whether the packet was received after the first list was full, and whether the packet was initiated by a newly accessed terminal, which is more complex to implement.

[0160] The S303c processes Category 3 messages according to the Category 3 rules stored in the hardware list.

[0161] For example, the third category rule includes: discarding all messages marked as third category.

[0162] It should be understood that the above-mentioned third marking rule and third category rule are basic rules shared by all terminals and can be configured when the Portal authentication function of the controlled port is enabled.

[0163] In this embodiment, the first list is full, indicating that there are a large number of terminals awaiting authentication. If a new terminal connects, this embodiment will mark its sent messages as belonging to the third category and discard them if they match the third category rule, thus blocking the connection. In this case, although the first terminal cannot complete authentication, there will be no situation where messages are missed.

[0164] In conclusion, Figures 4 to 7 In the illustrated embodiment, for the case where the first terminal is a newly accessed terminal when the first list is not full, and for the case where the first terminal is an unauthenticated terminal already detected by the access device, the initiated packets are packets that do not require blocking. In this case, the access device executes... Figure 4 and Figure 5 S302a and S303a enable the first terminal's message to be tagged with a first category, and finally matched with the second rule to achieve Portal authentication.

[0165] If the first terminal is an authenticated terminal, the messages it initiates are non-blocking. In this case, the access device executes... Figure 6 As shown in S302b and S303b, the messages of the first terminal are marked with the second category, thereby matching the second category rule to achieve free access to network resources.

[0166] When the first terminal is a new access terminal that is already in the first list, its initiated packets are packets that need to be blocked. In this case, the packets will not be marked as either category one or category two, and the access device will execute... Figure 7 S302c and S303c, as shown, cause the messages of the first terminal to be marked as the third category, thereby matching the third category rule and achieving message blocking.

[0167] The following describes the configuration details of each rule involved in the above embodiments in the hardware list.

[0168] Rule 6 in the second rule mentioned above involves sending packets to the CPU, i.e., the trap function. Currently, only IPCL has this trap function in ACL. Therefore, rule 6 can be configured in IPCL and executed in IPCL.

[0169] In addition, TTI and FDB have the function of marking, but since IPCL that supports the trap function is before FDB, and packets need to be marked with the first category before entering IPCL in order to match rule six defined in IPCL when they flow to IPCL and thus be redirected to the CPU, in this embodiment of the application, the above-mentioned first marking rule can be configured in TTI that is located before IPCL that supports the trap function, and the first marking rule is executed in TTI: marking the packet with source MAC address as the first MAC address as ID B.

[0170] Furthermore, since the third labeling rule is bound to the controlled port, the aforementioned third labeling rule can be configured in the TTI and executed in the TTI: labeling packets from the controlled port with a third category.

[0171] It should be noted that the MAC address forwarding table corresponds to the port, and each port is fixed, while each VLAN can exist on multiple ports.

[0172] Furthermore, both TTI and FDB have marking functions. However, considering that FDB has many entries while TTI has far fewer, the second marking rule involved in this application embodiment can optionally be configured in FDB and executed in FDB: marking packets with a source MAC address of the first MAC address as a second category. It should be understood that compared to storing the second marking rule in TTI, placing the second marking rule in FDB makes it less likely for TTI entries to be filled, thereby increasing the number of devices that can be connected.

[0173] In this embodiment, after the first terminal is authenticated, the second marking rule is stored in the FDB, and the first marking rule stored in the TTI is deleted. This means that after the first terminal is authenticated and becomes an authenticated terminal, besides configuring a few basic rules (which have been described in the above embodiments and will not be repeated here), for specific rules that occupy many hardware list entries, only one specific rule, the second marking rule, needs to be configured. The first marking rule is no longer needed. Therefore, in this embodiment, an authenticated terminal involves only one specific rule stored in the FDB (a category rule used to mark the second category). While the existing MAC address method does not require configuring the second marking rule, it does require configuring the rule corresponding to the second category rule (such as ACL7 in Table 1) to allow packets from the authenticated terminal. However, the rule corresponding to this second category rule is not a basic rule but a specific rule stored in the ACL.

[0174] It should be noted that since the number of entries in the FDB is far greater than the number of entries in the ACL, the number of connected devices is mainly determined by the ACL. In existing technologies, besides some basic rules occupying the ACL list, specific rules related to authenticated terminals (such as ACL7 in Table 1) are stored in the ACL affecting the number of connected devices, and each authenticated terminal needs to be configured with one of these specific rules. Therefore, the number of ACL entries gradually decreases as the number of authenticated terminals increases. In this embodiment, since a specific rule related to an authenticated terminal is stored in the FDB, there are no longer any specific rules occupying the ACL affecting the number of connected devices. Therefore, the number of ACL entries does not gradually decrease as the number of authenticated terminals increases. The ACL of the access device only contains some common basic rules, and the number of these basic rules is only a fixed few. Obviously, as the number of authenticated terminals increases, the number of connected devices of the access device using this embodiment is greatly increased. Thus, the number of connected devices can be increased even with a limited number of access device entries. Specifically, the number of terminals that access the Internet after Portal authentication can be increased.

[0175] Furthermore, since the EPCL has forward and drop functions, alternatively, the other rules in the second rule mentioned above, except for rule six, can be set in the EPCL. It should be understood that compared to the scheme where all rules in the second rule are placed in the IPCL, storing the rules separately makes it less likely that IPCL entries will be filled up, thereby increasing the switch's capacity. Of course, in other embodiments, other rules can also be placed in the IPCL, or some rules of other rules can be stored in the IPCL.

[0176] Furthermore, Category 2 and Category 3 rules can also be configured in the EPCL. In this case, only rule six of the Category 2 rules is configured in the IPCL to redirect HTTP messages to the CPU. The speed of message redirection to the CPU improves the speed of Portal authentication.

[0177] As can be seen from the configuration details of the above rules, packets from unauthenticated terminals are marked with a category via TTI (Translation Time Interchange) rather than with a MAC address via the MAC address forwarding table, and are ultimately sent to the CPU for Portal authentication. Since the TTI's effectiveness is not coupled with the port / interface, this embodiment is applicable not only to port-based Portal authentication but also to interface-based Portal authentication. It should be understood that MAC address forwarding tables and ports are corresponding; a MAC address can only be learned by one port, meaning one MAC address can only correspond to one port. However, a VLAN interface can exist on multiple ports. Therefore, port-based Portal authentication is less flexible in topology setup than interface-based authentication. The packet processing method provided in this embodiment is applicable to both port-based and interface-based Portal authentication, offering good flexibility in topology setup.

[0178] To better understand the content of the above embodiments, the following will be combined with... Figure 8 The process of a first terminal accessing the network from its initial connection to its final access is described exemplarily. It should be noted that... Figure 8 The illustrated embodiment only shows a portion of the messages related to Portal authentication and does not demonstrate the complete message transmission, such as DNS messages. It should be understood that other messages may be transmitted during the process from initial access to final network access.

[0179] Please refer to Figure 8 , Figure 8 This is an interactive flowchart illustrating a message processing method provided in an embodiment of this application. It should be understood that this Portal authentication method can be applied to... Figure 1 The system architecture shown is used to implement Portal authentication for the first terminal. Figure 8 The Portal authentication method shown may include the following steps:

[0180] S801, enable the Portal authentication function of the controlled port on the access device and configure basic rules.

[0181] The basic rules can include the second rule (rules other than T1, E7, and E8 in Table 5), the second category rule (E8 in Table 5), the third labeling rule (T1 in Table 5), and the third category rule (E7 in Table 5), as shown in Table 5 below:

[0182] Table 5

[0183]

[0184]

[0185] S802, the first terminal initiates an ARP message or connects for the first time.

[0186] The access device marks the ARP packet or the packet initiated during the first access based on the T1 rule as ID A.

[0187] S803, the access device determines that the first terminal is a new access terminal by querying the authentication list, and the first list is not full, and adds the first marking rule.

[0188] It should be understood that the first marking rule is T2 in Table 6 below.

[0189] Table 6

[0190]

[0191] It should be noted that after S803, for access devices receiving messages sent by the first terminal again through the controlled port, including but not limited to HTTP messages for accessing the network, the following only describes the processing of HTTP messages for accessing the network; the processing of other messages will be explained later. Figure 9 and Figure 10 Please provide an explanation.

[0192] S804: The first terminal initiates an HTTP message to access the network through a browser, and the access device receives the HTTP message to access the network initiated by the first terminal through the controlled port.

[0193] When an HTTP message accessing the network matches both T2 and T1 rules, in some embodiments, the T2 rule is given higher priority than the T1 rule so that the access device labels the HTTP message accessing the network with ID B based solely on the T2 rule. It should be noted that in other embodiments, the T2 rule has higher priority than the T1 rule, so that after labeling the HTTP message accessing the network with ID A based on the T1 rule, the access device can label the HTTP message accessing the network with ID B based on the T2 rule. In this case, ID B overrides ID A.

[0194] The HTTP message of the network accessing device marked with ID B matches the I1 rule and is sent to the CPU of the access device for redirection. After receiving the HTTP message of the network accessing device marked with ID B, the CPU executes S805 to start Portal authentication.

[0195] S805, the access device sends a redirection message to the first terminal.

[0196] The redirect message is used to notify the first terminal to redirect the HTTP message to the Portal server, that is, to initiate an HTTP message whose destination IP is the Portal server.

[0197] S806, the first terminal provides authentication information to the Portal server.

[0198] Specifically, based on the received redirection message, the first terminal initiates an HTTP message with a destination IP address pointing to the Portal server to access the Portal server's authentication interface. It should be understood that the access device marks the HTTP message with destination IP address pointing to the Portal server initiated by the first terminal as ID B. The HTTP message with destination IP address marked as ID B matches the E4 rule and is allowed, thus enabling access to the Portal server's authentication interface. This authentication interface is used to obtain authentication information input by the first terminal. After obtaining the authentication information, the first terminal sends it to the Portal server, thereby realizing the exchange of authentication information.

[0199] S807, the Portal server sends the received authentication information to the access device.

[0200] S808: The access device obtains the authentication result based on the authentication information.

[0201] For specific implementation details, please refer to... Figure 2 The contents of S208 to S210 and their variations.

[0202] S809: If the authentication result is that the first terminal passes the authentication, the access device deletes the first tag rule and adds the second tag rule.

[0203] The second marking rule is F1 as shown in Table 7 below.

[0204] Table 7

[0205]

[0206]

[0207] S810: The access device sends the authentication result to the Portal server.

[0208] S811, the Portal server returns the authentication result to the first terminal.

[0209] S812, the first terminal initiates an HTTP message to access the network.

[0210] Assuming the first terminal is successfully authenticated, when the authenticated first terminal initiates another HTTP message to access the network, the access device marks the HTTP message to access the network with ID A based on the T1 rule, and then marks it with ID C based on the F1 rule. In this case, ID C overrides ID A. The HTTP message to access the network marked with ID C matches the E8 rule, and the following S813 is executed.

[0211] S813, Access devices allow HTTP packets to access the network.

[0212] It should be understood that once an HTTP message for accessing the network is allowed, the first terminal can access network resources on the network.

[0213] It should be noted that Tables 5 to 7 only describe the second marking rule and the first marking rule for the first terminal. In actual implementation, there will be rules for other certified terminals and other uncertified terminals.

[0214] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0215] To better understand the content of the above embodiments, the following will be combined with... Figure 8 Tables 5 to 7 in the illustrated embodiments describe the processing of a message from terminal X within the access device. Message X is the message sent when terminal X fails authentication; message X' is the message sent after terminal X successfully authenticates.

[0216] Please refer to Figure 9 , Figure 9 This is a schematic diagram illustrating the process of the access device, as provided in this embodiment, processing the message of terminal X when the TTI is not full.

[0217] like Figure 9 (a) in the middle, Figure 9 (a) in the diagram illustrates the process by which the access device processes message X.

[0218] Assuming that a T2 rule has been added in the TTI, when a message X received through the controlled port enters the TTI, there are both matching T1 and T2 rules. Since the priority of the T1 rule is lower than that of the T2 rule, the TTI marks the message X with an IDB based on the T2 rule and outputs the message X marked with IDB.

[0219] Next, message X, marked with ID B, flows into IPCL. If message X, marked with ID B, is an HTTP message, it matches the I1 rule and is sent to the CPU in IPCL for redirection to authenticate terminal X. After successful authentication, terminal X becomes an authenticated terminal and sends message X'. If message X, marked with ID B, is another type of message, it flows through FDB to EPCL and matches one of the E1 to E6 rules, thus being allowed or discarded by EPCL.

[0220] like Figure 9 (b) in the middle Figure 9 (b) illustrates the process by which the access device processes message X'.

[0221] First, since the T2 rule was deleted after terminal X's authentication, the packet X' received through the controlled port only matches the T1 rule when it enters the TTI. The TTI assigns packet X' ID A based on the T1 rule. When packet X', marked with ID A, flows through the IPCL to the FDB, it matches the F1 rule and is marked with ID C in the FDB. At this point, ID A is overwritten by ID C. Therefore, after processing by the FDB, packet X' is marked with ID C; that is, the output of the FDB is packet X' marked with ID C.

[0222] Next, when the message X' marked as IDC flows to EPCL, it matches the E8 rule and is allowed by EPCL, thus enabling the authenticated terminal X to access the network normally.

[0223] Please refer to Figure 10 , Figure 10 This is a schematic diagram illustrating the processing of messages from terminal B by the access device provided in this embodiment of the application when the TTI is fully occupied.

[0224] like Figure 10 (a) in the middle, Figure 10 (a) in the diagram illustrates the process by which the access device processes message X.

[0225] If terminal X is a newly accessed terminal, since the TTI is full, the access device will not process the new terminal's packets and therefore will not add a T2 rule for it. Thus, when packet X received through the controlled port enters the TTI, it only matches a T1 rule. The TTI marks packet X with ID A based on the T1 rule and outputs packet X marked with ID A. Packet X marked with ID A flows sequentially through IPCL and FDB to EPCL, where it matches an E7 rule and is discarded by EPCL, thus achieving packet blocking.

[0226] If terminal X is an unauthenticated terminal already detected by the access device, since TTI added a T2 rule for terminal X when it first accessed the network, meaning that packet X has a matching T2 rule, packet X received through the controlled port will match both T1 and T2 rules when it enters TTI. Because the T2 rule has higher priority than the T1 rule, TTI marks packet X with ID B based on the T2 rule and outputs packet X marked with ID B. Then, packet X marked with ID B flows into IPCL. If packet X marked with ID B is an HTTP packet, it matches an I1 rule and is sent to the CPU in IPCL for redirection to authenticate terminal X.

[0227] like Figure 10 (b) in the middle Figure 10 (b) illustrates the process by which the access device processes message X'.

[0228] First, since the T2 rule has been deleted after the terminal X has been authenticated, the message X' received through the controlled port only matches the T1 rule when it enters the TTI. The TTI marks the message X' with ID A based on the T1 rule and outputs the message X' marked with ID A.

[0229] Next, when packet X', marked with ID A, flows through IPCL to FDB, it matches the F1 rule and is marked with IDC in FDB. At this point, ID A is overwritten by ID C. Therefore, after processing by FDB, packet X' is marked with ID C, meaning the output of FDB is packet X' marked with IDC. Then, when packet X' marked with ID C flows to EPCL, it matches the E8 rule and is allowed by EPCL, thus enabling the authenticated terminal X to access the network normally.

[0230] Corresponding to the message processing method in the above embodiments, Figure 11 A structural block diagram of the device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0231] Please refer to Figure 11 The message processing device includes:

[0232] The receiving module is used to receive messages sent by the first terminal through the controlled port with the Portal authentication function enabled. The hardware list is used to store rules.

[0233] The tagging module is used to tag the message category of the first terminal according to the tagging rules stored in the hardware list.

[0234] The processing module is used to process messages according to the message type of the first terminal and the control rules stored in the hardware list. The control rules are rules that control the message flow; the control rules include category rules based on category definitions.

[0235] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0236] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0237] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0238] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0239] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A message processing method, applied to an access device, characterized in that, The message processing method includes: The access device receives messages from the first terminal through a controlled port with Portal authentication enabled; the access device is configured with a hardware list, which is used to store rules, including tagging rules and control rules. According to the marking rules stored in the hardware list, the message category of the first terminal is marked; the hardware list includes a first list, which is used to store marking rules for marking the first category; marking the message category of the first terminal according to the marking rules stored in the hardware list includes: when the first terminal is a new access terminal when the first list is not full, or when the first terminal is an unauthenticated terminal detected by the access device, marking the message of the first terminal with the first category according to the first marking rules stored in the first list; before marking the message of the first terminal with the first category, the method further includes: adding the specified rules to the first list. The first marking rule is described; if adding the first marking rule to the first list fails, the fourth marking rule that meets the preset conditions among the multiple fourth marking rules stored in the first list is deleted; the fourth marking rule includes: marking the message sent by the second terminal with the first category; the second terminal is one of the unauthenticated terminals detected by the access device; wherein, the preset conditions include: the difference between the current time and the time when the fourth marking rule is added is greater than a preset time threshold; the first marking rule is added to the first list again; the first marking rule will only be successfully added to the first list when the first terminal is a new access terminal and the first list is not full; The message is processed according to its category and the control rules stored in the hardware list. The control rules are rules that control the flow of messages. The control rules include category rules defined based on the category.

2. The message processing method according to claim 1, characterized in that, After deleting the fourth tagging rules that satisfy the preset conditions among the multiple fourth tagging rules, the method further includes: Send an ARP request message to the deleted terminal, the ARP request message being used to request an ARP reply message from the deleted terminal, the deleted terminal being the second terminal corresponding to the deleted fourth marking rule.

3. The message processing method according to claim 2, characterized in that, After sending an ARP request message to the deleted terminal, the method further includes: Receive the ARP response message sent by the deleted terminal; In response to the ARP reply message, the fourth tagging rule corresponding to the deleted terminal is added to the first list.

4. The message processing method according to any one of claims 1 to 3, characterized in that, The step of processing the message according to the message type and the rules stored in the hardware list includes: The first category of messages is processed according to the second rule stored in the hardware list; wherein the second rule is used to control messages to achieve Portal authentication, and the second rule includes a first category rule defined based on the first category.

5. The message processing method according to claim 4, characterized in that, After processing the first category of messages according to the second rule stored in the hardware list, the method further includes: If the first terminal Portal authentication is successful, a second tagging rule is added to the hardware list. The second tagging rule includes: tagging the messages of the first terminal with a second category.

6. The message processing method according to claim 4, characterized in that, The method further includes: if the first terminal Portal authentication is successful, deleting the first tagging rule.

7. The message processing method according to any one of claims 1 to 3, characterized in that, The step of classifying the message categories of the first terminal according to the marking rules stored in the hardware list includes: When the first terminal is an authenticated terminal, the messages of the first terminal are labeled with a second category according to the second labeling rules stored in the hardware list.

8. The message processing method according to any one of claims 1 to 3, characterized in that, The process of processing the message according to the message type and the control rules stored in the hardware list includes: The second category of messages is processed according to the second category rules stored in the hardware list; the second category rules include: allowing the second category of messages to pass.

9. The message processing method according to any one of claims 1 to 3, characterized in that, The hardware list includes a first list, which stores the marking rules for marking a first category; The step of classifying the message categories of the first terminal according to the marking rules stored in the hardware list includes: When the first terminal is a new access terminal when the first list is full, the first terminal's message is labeled with a third category according to the third labeling rule stored in the hardware list.

10. The message processing method according to claim 9, characterized in that, The third labeling rule includes: labeling messages originating from the controlled port with the third category.

11. The message processing method according to claim 10, characterized in that, in, The third marking rule has a lower priority than the first and second marking rules, so that the messages of the first terminal are marked as the third category when the first terminal is a new access terminal when the first list is full.

12. The message processing method according to any one of claims 1 to 3, characterized in that, The process of processing the message according to the message type and the control rules stored in the hardware list includes: The third category of messages is processed according to the third category rules stored in the hardware list, and the third category rules include: discarding the third category of messages.

13. A message processing apparatus, characterized in that, The message processing device is configured in the access device, and the message processing device includes: The receiving module is used to receive messages sent by the first terminal through a controlled port with the Portal authentication function enabled; the access device is configured with a hardware list, which is used to store rules, including marking rules and control rules; A marking module is configured to mark the packets of the first terminal with a category according to marking rules stored in the hardware list; the hardware list includes a first list, which stores marking rules for marking a first category; marking the packets of the first terminal with a category according to the marking rules stored in the hardware list includes: when the first terminal is a new access terminal that is not full in the first list, or when the first terminal is an unauthenticated terminal that has been detected by the access device, marking the packets of the first terminal with a first category according to the first marking rules stored in the first list; before marking the packets of the first terminal with a first category, adding the specified rules to the first list. The first marking rule is described; if adding the first marking rule to the first list fails, the fourth marking rule that meets the preset conditions among the multiple fourth marking rules stored in the first list is deleted; the fourth marking rule includes: marking the message sent by the second terminal with the first category; the second terminal is one of the unauthenticated terminals detected by the access device; wherein, the preset conditions include: the difference between the current time and the time when the fourth marking rule is added is greater than a preset time threshold; the first marking rule is added to the first list again; the first marking rule will only be successfully added to the first list when the first terminal is a new access terminal and the first list is not full; The processing module is configured to process the message according to the message category and the control rules stored in the hardware list; wherein the control rules are rules for controlling the message flow; the control rules include category rules based on category definitions.

14. An access device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 12.

15. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 12.

Images