A distributed service testing method and device based on SSL VPN

Abstract

The application provides a distributed service test method and device based on SSLVPN, applied to the field of network security technology, wherein the distributed service test method based on SSLVPN comprises the following steps: controlling a plurality of clients to perform SV authentication by using at least one account, and obtaining a plurality of authentication results corresponding to the plurality of clients; wherein the clients comprise simulation clients, the at least one account comprises one SV account, a plurality of SV accounts or a plurality of SV accounts and one non-SV account; determining a first test result according to the plurality of authentication results; controlling the plurality of clients to access resources, and obtaining a plurality of access results corresponding to the plurality of clients; and determining a second test result according to the plurality of access results. In the above scheme, the simulation clients are controlled to perform authentication and resource access in an automatic manner through remote connection, so that a large number of access conditions can be tested.

Description

Technical Field

[0001] This application relates to the field of network security technology, and more specifically, to a distributed service testing method and apparatus based on SSLVPN. Background Technology

[0002] The distributed gateway employs multiple switching boards and multiple service boards to jointly provide data forwarding and processing functions. Upon arrival at the switching board, the switching board can distribute the packet to the designated service board for processing based on the source Internet Protocol Address (IP), destination IP, and a hash-based routing algorithm. The distributed adaptation scheme for Virtual Private Network (SSLVPN) technology, which establishes a remote secure access channel based on Security Socket Layer (SSL), primarily aims to achieve load balancing of SSLVPN services across multiple service boards in a distributed system.

[0003] The distributed service adaptation solution based on SSLVPN consists of two parts: the management plane and the data plane. The management plane includes SSLVPN configuration and user information synchronization, while the data plane includes packet forwarding and redirection table-related content. Currently, most testing methods for this type of distributed service based on SSLVPN are performed manually, which is insufficient for testing large volumes of access scenarios. Summary of the Invention

[0004] The purpose of this application is to provide a distributed service testing method and apparatus based on SSLVPN, so as to solve the technical problem that the prior art cannot meet the testing of a large number of access scenarios.

[0005] In a first aspect, embodiments of this application provide a distributed service testing method based on SSLVPN, comprising: controlling multiple clients to perform SV verification using at least one account, and obtaining multiple verification results corresponding to the multiple clients; wherein, the clients include simulated clients, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account; determining a first test result based on the multiple verification results; controlling the multiple clients to access resources, and obtaining multiple access results corresponding to the multiple clients; and determining a second test result based on the multiple access results.

[0006] In the above scheme, authentication and resource access are automated through remote connection, controlling simulated clients to perform tests on a large number of access scenarios. Furthermore, by statistically analyzing the results of the first and second tests, the effectiveness of the distributed service based on SSLVPN can be verified in real time.

[0007] In an optional implementation, controlling multiple clients to perform SV verification using at least one account includes: controlling a portion of the multiple clients to perform SV verification using different SV accounts, and controlling another portion of the multiple clients to perform SV verification using different non-SV accounts; wherein, when a client performing SV verification using the SV account passes verification and a client performing SV verification using the non-SV account fails verification, the first test result indicates that the test is passed; controlling the multiple clients to access resources includes: controlling clients performing SV verification using the SV account to access the same resource on the SV resource list, and controlling clients performing SV verification using the non-SV account to access the same resource on the non-SV resource list; wherein, when a client performing SV verification using the SV account successfully accesses the resource and a client performing SV verification using the non-SV account fails access, the second test result indicates that the test is passed. In the above scheme, the load balancing of SSLVPN services by the SSLVPN server can be tested when each client logs in to the SSLVPN client with a unique SV account to access resources; simultaneously, the scenarios of a large number of clients logging in to the SV account and accessing the same resource, and a large number of clients accessing the same resource without logging in to the SV account, can be tested to increase test coverage. Therefore, we can test the dimension of accessing server resources with matching conditions versus accessing server resources without matching conditions.

[0008] In an optional implementation, when multi-point login is not supported, controlling multiple clients to use at least one account for SV verification includes: controlling the multiple clients to use the same SV account for SV verification; wherein, when only one client among the multiple clients passes verification, the first test result indicates that the test is passed; controlling the multiple clients to access resources includes: controlling the multiple clients to access the same resource on the SV resource list; wherein, when only one client among the multiple clients successfully accesses the resource, the second test result indicates that the test is passed. In the above scheme, the load balancing handling of SSLVPN services and the correct handling of SSLVPN multi-point login by the SSLVPN server can be tested when a large number of clients use the same SV account to log in to SSLVPN clients and access resources. Therefore, the multi-point login switch dimension can be tested.

[0009] In an optional implementation, when multi-point login is supported, controlling multiple clients to perform SV verification using at least one account includes: controlling the multiple clients to perform SV verification using the same SV account; wherein, when all multiple clients pass verification, the first test result indicates that the test is passed; controlling the multiple clients to access resources includes: controlling the multiple clients to access the same resource on the SV resource list; wherein, when all multiple clients successfully access the resource, the second test result indicates that the test is passed. In the above scheme, the load balancing handling of SSLVPN services and the correct handling of SSLVPN multi-point login by the SSLVPN server can be tested when a large number of clients log in to SSLVPN clients using the same SV account to access resources. Therefore, the multi-point login switch dimension can be tested.

[0010] In an optional implementation, when multi-point login is supported, controlling multiple clients to perform SV verification using at least one account includes: controlling the multiple clients to perform SV verification using the same SV account; wherein, when all multiple clients pass verification, the first test result indicates that the test is successful; controlling the multiple clients to access resources includes: controlling the multiple clients to access the same resource on the SV resource list; wherein, when all multiple clients successfully access the resource, the second test result indicates that the test is successful. In the above scheme, the load balancing of SSLVPN services by the SSLVPN server can be tested when each client logs in to the SSLVPN client using a unique SV account to access resources. Therefore, the dimension of testing a large number of simulated clients logging in to the same account and a large number of simulated clients logging in to different accounts can be tested.

[0011] In an optional implementation, controlling multiple clients to perform SV verification using at least one account includes: controlling the multiple clients to perform SV verification using different SV accounts; controlling the multiple clients to access resources includes: controlling the multiple clients to sequentially access HTTP protocol resources, HTTPS protocol resources, and FTP protocol resources on the SV resource list, and downloading and uploading a file respectively; wherein, when all multiple clients successfully access, download, and upload, the second test result indicates that the test has passed. In the above scheme, the correctness of SSL VPN load balancing and forwarding for services using multiple protocols can be tested, such as the upload and download status of HTTP, HTTPS, and FTP protocols. Therefore, the upload and download dimension of different protocol traffic can be tested.

[0012] In an optional implementation, when multi-point login is supported, before controlling multiple clients to perform SV authentication using at least one account, the method further includes: configuring the DHCP protocol; after controlling multiple clients to perform SV authentication using at least one account, the method further includes: repeatedly checking the number of DHCP-assigned addresses and determining a third test result based on the checking results. In the above scheme, it is possible to test whether SSL VPN services, such as DHCP addresses, can be handled correctly. Therefore, the address renewal dimension of the SV distributed DHCP protocol can be tested.

[0013] Secondly, embodiments of this application provide a distributed service testing device based on SSLVPN, comprising: a first control module, configured to control multiple clients to perform SV verification using at least one account, and obtain multiple verification results corresponding to the multiple clients; wherein, the clients include simulated clients, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account; a first determining module, configured to determine a first test result based on the multiple verification results; a second control module, configured to control the multiple clients to access resources, and obtain multiple access results corresponding to the multiple clients; and a second determining module, configured to determine a second test result based on the multiple access results.

[0014] In the above scheme, authentication and resource access are automated through remote connection, controlling simulated clients to perform tests on a large number of access scenarios. Furthermore, by statistically analyzing the results of the first and second tests, the effectiveness of the distributed service based on SSLVPN can be verified in real time.

[0015] In an optional implementation, the first control module is specifically used to: control a portion of the multiple clients to perform SV verification using different SV accounts, and control another portion of the multiple clients to perform SV verification using different non-SV accounts; wherein, when the client performing SV verification using the SV account passes verification and the client performing SV verification using the non-SV account fails verification, the first test result indicates that the test is passed; the second control module is specifically used to: control the client performing SV verification using the SV account to access the same resource on the SV resource list, and control the client performing SV verification using the non-SV account to access the same resource on the non-SV resource list; wherein, when the client performing SV verification using the SV account successfully accesses the resource and the client performing SV verification using the non-SV account fails access, the second test result indicates that the test is passed. In the above scheme, the load balancing processing of SSLVPN services by the SSLVPN server can be tested when each client logs in to the SSLVPN client with a unique SV account to access resources; at the same time, the test can be conducted on the cases where a large number of clients log in to the SV account and access the same resource, and a large number of clients do not log in to the SV account and access the same resource, to increase the test coverage. Therefore, we can test the dimension of accessing server resources with matching conditions versus accessing server resources without matching conditions.

[0016] In an optional implementation, where multi-point login is not supported, the first control module is specifically used to: control the multiple clients to perform SV authentication using the same SV account; wherein, when only one client among the multiple clients passes authentication, the first test result indicates that the test is passed; the second control module is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when only one client among the multiple clients successfully accesses the resource, the second test result indicates that the test is passed. In the above scheme, the load balancing handling of SSLVPN services and the correct handling of SSLVPN multi-point login by the SSLVPN server can be tested when a large number of clients log in to the SSLVPN client using the same SV account to access resources. Therefore, the multi-point login switch dimension can be tested.

[0017] In an optional implementation, when multi-point login is supported, the first control module is specifically used to: control the multiple clients to perform SV authentication using the same SV account; wherein, when all the multiple clients successfully authenticate, the first test result indicates that the test is passed; the second control module is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test is passed. In the above scheme, the load balancing handling of SSLVPN services and the correct handling of SSLVPN multi-point login by the SSLVPN server can be tested when a large number of clients log in to the SSLVPN client using the same SV account to access resources. Therefore, the multi-point login switch dimension can be tested.

[0018] In an optional implementation, when multi-point login is supported, the first control module is specifically used to: control the multiple clients to perform SV verification using the same SV account; wherein, when all the multiple clients pass verification, the first test result indicates that the test is passed; the second control module is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test is passed. In the above scheme, the load balancing of the SSLVPN service by the SSLVPN server can be tested when each client logs in to the SSLVPN client using a unique SV account to access resources. Therefore, the dimension of testing a large number of simulated clients logging in to the same account and a large number of simulated clients logging in to different accounts can be tested.

[0019] In an optional implementation, the first control module is specifically used to: control the multiple clients to perform SV verification using different SV accounts; the second control module is specifically used to: control the multiple clients to sequentially access HTTP protocol resources, HTTPS protocol resources, and FTP protocol resources on the SV resource list, and download and upload a file respectively; wherein, when all the multiple clients successfully access, download, and upload, the second test result indicates that the test has passed. In the above scheme, the correctness of SSL VPN load balancing and forwarding for services using multiple protocols can be tested, such as the upload and download status of HTTP, HTTPS, and FTP protocols. Therefore, the upload and download dimensions of different protocol traffic can be tested.

[0020] In an optional implementation, when multi-point login is supported, the SSLVPN-based distributed service testing device further includes: a configuration module for configuring the DHCP protocol; and a viewing module for repeatedly viewing the number of DHCP-assigned addresses and determining a third test result based on the viewing results. In the above scheme, it is possible to test whether SSLVPN services, such as DHCP addresses, can be handled correctly. Therefore, the address renewal dimension of the SV distributed DHCP protocol can be tested.

[0021] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus; the processor and the memory communicate with each other through the bus; the memory stores computer program instructions that can be executed by the processor, and the processor can execute the distributed service testing method based on SSLVPN as described in the first aspect by calling the computer program instructions.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a computer, cause the computer to perform the distributed service testing method based on SSLVPN as described in the first aspect.

[0023] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, embodiments of this application are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A schematic diagram of a distributed service testing system based on SSLVPN provided in an embodiment of this application;

[0026] Figure 2 A general flowchart of the testing process provided for embodiments of this application;

[0027] Figure 3 A flowchart illustrating a distributed service testing method based on SSLVPN provided in this application embodiment;

[0028] Figure 4A structural block diagram of a distributed service testing device based on SSLVPN provided in this application embodiment;

[0029] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0031] Please refer to Figure 1 , Figure 1 This diagram illustrates a distributed service testing system based on SSL VPN, as provided in an embodiment of this application. The system includes a management client (Personal Computer, PC), a cluster of physical client machines, an SSL VPN server (the network device under test), and a server cluster. The management client can communicate with both the physical client machine cluster and the SSL VPN server to remotely manage and issue relevant commands. The physical client machine cluster is connected to and can communicate with the SSL VPN server, and the SSL VPN server is connected to and can communicate with the server cluster.

[0032] It should be noted that the distributed service testing method based on SSLVPN provided in the subsequent embodiments of this application is applied to the above-mentioned management client. It verifies the load balancing processing results of distributed services based on SSLVPN in an automated manner, and verifies the situation where a large number of clients access resources through SSLVPN, so as to solve the problems of time consumption, incomplete coverage and single dimension in the existing technology for distributed service testing based on SSLVPN.

[0033] Please refer to Figure 2 , Figure 2 The overall test flowchart provided in this application embodiment may include:

[0034] Step S201: Design test cases for distributed services based on SSLVPN, and write corresponding test scripts.

[0035] Step S202: Initialize the automated testing system.

[0036] Step S203: Execute the test script.

[0037] Step S204: Generate a test report.

[0038] Based on the above Figure 1Taking the distributed business testing system based on SSLVPN as an example, before executing the above testing steps, the following preparations can be made: The client needs to have a built-in Docker system, and the system needs to enable File Transfer Protocol (FTP), Trivial File Transfer Protocol (TFTP), Telnet clients and be compatible with TLS 1.2. Servers 1, 2, and 3 should have FTP, TFTP, Hypertext Transfer Protocol (HTTP), and Hypertext Transfer Protocol Secure (HTTPS) servers installed respectively, and SSLVPN should be configured to allow downloading controls via links.

[0039] The following initialization can then be performed:

[0040] Step 1) Initialize the automated testing system and remove any interfering configurations.

[0041] Step 2) Configure the Docker system and SSLVPN server on the physical machine respectively, so that the built-in system of the physical machine can communicate with the SSLVPN server, and the SSLVPN server can communicate with the server cluster.

[0042] For example: Configure the IPs of the Docker systems on three physical machines as 192.168.10.2 / 16, 192.169.10.2 / 16, and 192.170.10.2 / 16. Set the SSLVPN server's connection interfaces on the three physical machines to 192.168.10.1 / 16, 192.169.10.1 / 16, and 192.170.10.1 / 16. Set the server's connection interface IP to 192.171.30.1 / 24. Set the server IPs to 192.71.30.100 / 24, 192.171.30.101 / 24, and 192.171.30.102 / 24.

[0043] Step 3) Read the global parameters, where the number of clients to be simulated is set to M. First, operate the existing Docker system to open the port authentication page, download and install the control, copy the Docker system M times to simulate M clients, and configure a unique IP address for each client's Internet card. Configure M SSLVPN accounts on the SSLVPN server.

[0044] For example: M=600, configure unique IP addresses for each client's internet card starting from 192.168.10.3 / 16 to 192.168.10.201 / 16, 192.169.10.3 / 16 to 192.169.10.201 / 16, and 192.170.10.3 / 16 to 192.170.10.201 / 16 respectively; configure 600 SSLVPN accounts on the SSLVPN server under test, namely user1-user600.

[0045] Step 4) Configure the SSLVPN module for testing on the SSLVPN server. Services on Server 1 and Server 2 are added to the resource list on the SSLVPN configuration, while services on Server 3 are not added to the resource access list. Roles are configured to reference all users and associate all resources. The user group of the SV user is associated with the Dynamic Host Configuration Protocol (DHCP) address pool. Configure two access control policies: the first policy allows access for users whose roles match, and the second policy completely blocks access.

[0046] Please refer to Figure 3 , Figure 3 The flowchart illustrates a distributed service testing method based on SSLVPN provided in this application embodiment. This SSLVPN-based distributed service testing method may include the following steps:

[0047] Step S301: Control multiple clients to perform SV verification using at least one account, and obtain multiple verification results corresponding to the multiple clients; wherein, the client includes a simulated client, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account.

[0048] Step S302: Determine the first test result based on multiple verification results.

[0049] Step S303: Control multiple clients to access resources and obtain multiple access results corresponding to the multiple clients.

[0050] Step S304: Determine the second test result based on multiple access results.

[0051] Specifically, the distributed service testing method based on SSLVPN provided in this application can test the effectiveness of distributed services based on SSLVPN through different testing dimensions, making the testing more comprehensive. For example, testing dimension 1: accessing server resources with matching conditions and accessing server resources without matching conditions; testing dimension 2: multi-signal login switch, which does not support multi-signal login by default; testing dimension 3: a large number of simulated clients logging into the same account and a large number of simulated clients logging into different accounts; testing dimension 4: uploading and downloading traffic using different protocols; testing dimension 5: address renewal using the SV distributed DHCP protocol.

[0052] In step S301 above, multiple simulated clients can be controlled to use at least one account to perform SV verification, thereby obtaining multiple verification results corresponding to multiple clients.

[0053] In step S302 above, a first test result can be determined based on the multiple verification results obtained in step S301 above. As one implementation method, the multiple verification results can be compared with the predicted results. If they match, the first test result indicates that the test passed; if they do not match, the first test result indicates that the test failed.

[0054] In step S303 above, multiple simulated clients can be controlled to access resources, thereby obtaining multiple access results corresponding to multiple clients.

[0055] In step S304 above, a second test result can be determined based on the multiple access results obtained in step S303 above. As one implementation, the multiple access results can be compared with the predicted result; if they match, the second test result indicates that the test passed; if they do not match, the second test result indicates that the test failed.

[0056] In the above scheme, authentication and resource access are automated through remote connection, controlling simulated clients to perform tests on a large number of access scenarios. Furthermore, by statistically analyzing the results of the first and second tests, the effectiveness of the distributed service based on SSLVPN can be verified in real time.

[0057] Furthermore, based on the above embodiments, step S301 may include:

[0058] The test involves controlling a portion of the clients to perform SV verification using different SV accounts, and controlling another portion of the clients to perform SV verification using different non-SV accounts. The first test result indicates that the test is passed when the client performing SV verification using an SV account passes the verification while the client performing SV verification using a non-SV account fails the verification.

[0059] Step S303 above may include:

[0060] The test controls access to the same resource on the SV resource list by clients using SV accounts for SV authentication, and controls access to the same resource on a non-SV resource list by clients using non-SV accounts for SV authentication; wherein, the second test result indicates that the test is passed when the client using the SV account for SV authentication successfully accesses the resource and the client using the non-SV account for SV authentication fails to access the resource.

[0061] Specifically, in this application embodiment, testing can be performed on test dimension 1: accessing server resources under matching conditions and accessing server resources under non-matching conditions. It is understood that this test dimension can include a micro-level perspective (a small number of clients) and a macro-level perspective (a large number of clients).

[0062] First, let's look at the microscopic perspective:

[0063] Step 1) Control the 5 consecutive IP clients to perform SV authentication using 4 SV accounts and 1 non-SV account.

[0064]

[0065] When the authentication message arrives at the SSLVPN server, the SSLVPN server will perform authentication on the SV user list. If authentication is successful, an authentication confirmation will be returned to the client, and the SSLVPN server will maintain the client's SV session; if authentication fails, an error message will be displayed, and no session will be established on the SSLVPN server.

[0066]

[0067]

[0068] You can remotely view the four SV sessions on the SSLVPN server.

[0069]

[0070] Step 2) Control the five clients to access the same resource on the SV resource list and to access the same resource not on the resource list. Specifically, for accessing resources on the resource list: it is expected that pc1-pc4 can access successfully, while pc5 fails to access. If this meets the expectation, the test passes; otherwise, the test fails. For accessing resources not on the resource list: it is expected that all accesses will fail. If this meets the expectation, the test passes; otherwise, the test fails.

[0071]

[0072] Furthermore, the distributed service testing method based on SSLVPN provided in this application embodiment may also include the following steps:

[0073] Step 3) Remotely access the SSLVPN server to modify the ACL management, blocking access to resources in the original resource list, such as blocking access to http: / / 92.171.30.100; control a client's access to the blocked resources and unblock access.

[0074]

[0075] Step 4) Remotely access the SSLVPN server to delete the role associated with a resource and re-add the deleted role associated with the resource.

[0076]

[0077] Step 5) Control the four clients to log out of SV login and remotely view the four SV sessions on the SSLVPN server.

[0078] No session exists Pass, otherwise fail.

[0079] Step 6) Control the four clients to access the same resource on the SV resource list and to access the same resource not on the resource list. Specifically, for accessing resources on the resource list: access is not expected to succeed; if the expectation is met, the test passes; otherwise, the test fails. For accessing resources not on the resource list: access is not expected to succeed; if the expectation is met, the test passes; otherwise, the test fails.

[0080]

[0081] Next, let's look at the macro perspective:

[0082] Step 1) Control 600 clients to perform SV authentication using their own independent SV accounts.

[0083]

[0084] When the authentication message arrives at the SSLVPN server, the server verifies the information from the SV user list. Upon successful authentication, a confirmation message is sent to the client, and the SSLVPN server maintains the client's SV session.

[0085]

[0086] You can remotely check the SSLVPN server to see if the M SV sessions are the expected and correct sessions.

[0087] Non-600 SV sessions Not approved

[0088] Step 2) Control M clients to access the same resource on the SV resource list and to access the same resource not on the resource list. Specifically, for accessing resources on the resource list: if access is expected to be successful, the test passes; otherwise, the test fails. For accessing resources not on the resource list: if access is expected to be unsuccessful, the test passes; otherwise, the test fails.

[0089]

[0090] Furthermore, the distributed service testing method based on SSLVPN provided in this application embodiment may also include the following steps:

[0091] Step 3) Control M clients to log out of SV login, remotely check the SSLVPN server to see if the 600 SV sessions no longer exist. If this is as expected, the test passes; otherwise, the test fails.

[0092] The number of SV sessions is 0. Pass, otherwise fail.

[0093] Step 4) Control M clients to access the same resource on the SV resource list and to access the same resource not on the resource list. Specifically, for accessing resources on the resource list: access is expected to fail; if the expectation is met, the test passes; otherwise, the test fails. For accessing resources not on the resource list: access is expected to fail; if the expectation is met, the test passes; otherwise, the test fails.

[0094]

[0095] The above approach allows testing the load balancing of SSLVPN services by the SSLVPN server when each client logs in to the SSLVPN client using a unique SV account to access resources. It also allows testing scenarios where a large number of clients log in to the SV and access the same resource, and where a large number of clients do not log in to the SV and access the same resource, thus increasing test coverage. Therefore, it enables testing of both matching and non-matching conditions for accessing server resources.

[0096] Furthermore, based on the above embodiments, in the absence of multi-point login support, step S301 may include:

[0097] Control multiple clients to use the same SV account for SV verification; where the first test result indicates that the test is passed when only one of the multiple clients passes verification.

[0098] Step S303 above may include:

[0099] Control multiple clients to access the same resource on the SV resource list; the second test result indicates that the test is passed when only one of the multiple clients successfully accesses the resource.

[0100] When multi-point login is supported, step S301 above may include:

[0101] Control multiple clients to use the same SV account for SV verification; when multiple clients all pass verification, the first test result indicates that the test is successful.

[0102] Step S303 above may include:

[0103] Control multiple clients to access the same resource on the SV resource list; the second test result indicates that the test is passed when all multiple clients successfully access the resource.

[0104] Specifically, in this application embodiment, testing can be conducted on test dimension 2: multi-signal login switch, where multi-signal login is not supported by default. It is understood that this test dimension can include a micro-level perspective (a smaller number of clients).

[0105] The following section introduces the microscopic perspective:

[0106] Step 1) Control the two clients to use the same SV account for SV authentication.

[0107] Multi-point login is not supported. 192.168.10.2-3 all use user1 for SV authentication.

[0108] When the first client's authentication message arrives at the SSLVPN server, the SSLVPN server will verify the client's identity in the SV user list. Upon successful authentication, the server will send an authentication confirmation to the client and maintain the client's SV session on the SSLVPN server.

[0109] When the second client message arrives at the SSLVPN server, the SSLVPN server checks the SV user list for authentication. If it finds that the user is already logged in, it blocks the client from logging in and returns a message to the client indicating that the user is already logged in on another device.

[0110]

[0111] You can remotely check the SSLVPN server to see if it is the expected correct SV session. There is only one SV session, which is the session of the first client. If it matches the expectation, the test passes; otherwise, the test fails.

[0112]

[0113] Step 2) Control two clients to access the same resource on the SV resource list. Specifically, for pc1 accessing the resource list: access is expected to be successful, and if it meets expectations, the test passes; otherwise, the test fails. For pc2 accessing the resource list: access is expected to fail, and if it meets expectations, the test passes; otherwise, the test fails.

[0114]

[0115] Furthermore, the distributed service testing method based on SSLVPN provided in this application embodiment may also include the following steps:

[0116] Step 3) Remotely modify the authentication server configuration on the SSLVPN server to allow multiple logins. The number of allowed multiple logins is 2. It is expected that each board has been issued with the configuration to support multiple logins and the issued configuration is correct. If it meets the expectations, the test will pass. Otherwise, the test will fail.

[0117] Step 4) Repeat steps 1)-2). In step 1), you can control the three clients to use the same SV account for SV authentication. In this case, pc1 and pc2 can authenticate successfully, while pc3 will fail. In step 2), you can control the three clients to access the same resource on the SV resource list. The expected result is that there are two SV sessions on the SSLVPN server, and pc1 and pc2 can access the resource successfully, while pc3 cannot access it.

[0118]

[0119]

[0120] The above approach allows testing how the SSLVPN server handles load balancing and correctly processes multi-signal logins when a large number of clients use the same SV account to log in to the SSLVPN client and access resources. Therefore, the multi-signal switching aspect can be tested.

[0121] Furthermore, based on the above embodiments, when multi-point login is supported, step S301 may include:

[0122] Control multiple clients to use the same SV account for SV verification; when multiple clients all pass verification, the first test result indicates that the test is successful.

[0123] Step S303 above may include:

[0124] Control multiple clients to access the same resource on the SV resource list; the second test result indicates that the test is passed when all multiple clients successfully access the resource.

[0125] Specifically, in this application's embodiments, test dimension 3 can be: a large number of simulated clients logging into the same account and a large number of simulated clients logging into different accounts. It is understood that this test dimension can include a macro-level perspective (a larger number of clients).

[0126] The following section introduces the macro perspective:

[0127] Step 1), with multipoint authentication enabled, control 600 clients to use the same sSV account for SV authentication.

[0128]

[0129] When the first client's authentication message arrives at the SSLVPN server, the SSLVPN server will verify the client's identity in the SV user list. Upon successful authentication, a confirmation message will be sent back to the client, and the SSLVPN server will maintain the client's SV session.

[0130] After the second client message arrives at the SSLVPN server, the SSLVPN server checks if multi-signal login is supported and performs authentication from the SV user list. Upon successful authentication, an authentication confirmation is sent back to the client, and the remaining client authentication process follows the same logic.

[0131]

[0132]

[0133] You can remotely check the SSLVPN server to see if it contains the expected SV sessions. If there are 600 SV sessions, all under the same account, and it meets expectations, the test passes. Otherwise, the test fails.

[0134]

[0135] Step 2) Control 600 clients to access the same resource on the SV resource list. Specifically, for sessions accessing the resource list from pc1 to pc600: if access is expected to be successful, the test passes; otherwise, the test fails.

[0136]

[0137] Step 3), repeat steps 1)-2). In step 1), each of the 600 clients can be controlled to use a unique SV account for authentication. Therefore, when remotely checking the SSLVPN server, there should be 600 correct SV sessions and 600 accounts. In step 2), the 600 clients can be controlled to access the same resource on the SV resource list. The expected result is that all clients can access the resource successfully.

[0138]

[0139]

[0140]

[0141]

[0142]

[0143] The above approach allows testing how the SSLVPN server handles load balancing when each client uses a unique SV account to log in to the SSLVPN client and access resources. Therefore, it's possible to test the impact of a large number of simulated clients logging into the same account versus a large number of simulated clients logging into different accounts.

[0144] Furthermore, based on the above embodiments, step S301 may include:

[0145] Control multiple clients to use different SV accounts for SV verification.

[0146] Step S303 above may include:

[0147] Multiple clients are controlled to sequentially access HTTP, HTTPS, and FTP resources on the SV resource list, and each client downloads and uploads a file. The second test result indicates that the test is passed when all clients successfully access, download, and upload the file.

[0148] Specifically, in this application's embodiments, testing dimension 4 can be the uploading and downloading of traffic using different protocols. It is understood that this testing dimension can include both a micro-level perspective (a smaller number of clients) and a macro-level perspective (clients handling larger amounts of data).

[0149] First, let's introduce the microscopic perspective.

[0150] Step 1) Control the four clients to use different accounts for SV authentication.

[0151]

[0152] When the first client's authentication message arrives at the SSLVPN server, the SSLVPN server will verify the client's identity in the SV user list. Upon successful authentication, the server will send an authentication confirmation to the client and maintain the client's SV session on the SSLVPN server.

[0153] After the second client message arrives at the SSLVPN server, the SSLVPN server checks if multi-point login is supported, performs authentication from the SV user list, and returns an authentication confirmation to the client after successful authentication. The remaining client authentication process is then repeated in the same manner.

[0154]

[0155] You can remotely check the SSLVPN server to see if there are four SV sessions as expected. If the account information is correct and meets expectations, the test passes. Otherwise, the test fails.

[0156]

[0157] Step 2) Control four clients to download and upload a file respectively via HTTP access to resources on the SV resource list. Specifically, download and upload should be performed for pc1-pc4 respectively: if successful, the test passes; otherwise, the test fails.

[0158]

[0159]

[0160] Step 3) Control four clients to download and upload a file respectively by accessing HTTPS resources on the SV resource list. Specifically, download and upload should be performed for pc1-pc4 respectively: if successful, the test passes; otherwise, the test fails.

[0161]

[0162] Step 4) Control four clients to download and upload a file respectively via FTP access to the SV resource list. Specifically, download and upload should be performed on pc1-pc4 respectively: if successful, the test passes; otherwise, the test fails.

[0163]

[0164] Next, let's look at the macro perspective:

[0165] Step 1) Control 600 clients to perform SV authentication using different accounts.

[0166]

[0167] When the first client's authentication message arrives at the SSLVPN server, the SSLVPN server will verify the client's identity in the SV user list. Upon successful authentication, the server will send an authentication confirmation to the client and maintain the client's SV session on the SSLVPN server.

[0168] After the second client message arrives at the SSLVPN server, the SSLVPN server checks if multi-point login is supported, performs authentication from the SV user list, and returns an authentication confirmation to the client after successful authentication. The remaining client authentication process is then repeated in the same manner.

[0169]

[0170]

[0171] You can remotely check the SSLVPN server to see if it contains the expected SV sessions. If there are 600 SV sessions and the account information is correct, as expected, the test passes. Otherwise, the test fails.

[0172]

[0173] Step 2) Control 600 clients to download and upload a file respectively by accessing resources on the SV resource list via HTTP protocol. Specifically, download and upload are performed separately for pc1-pc600: if successful, the test passes; otherwise, the test fails.

[0174]

[0175] Step 3) Control 600 clients to download and upload a file respectively by accessing HTTPS resources on the SV resource list. Specifically, download and upload should be performed on pc1-pc600 respectively: if successful, the test passes; otherwise, the test fails.

[0176]

[0177]

[0178] Step 4) Control 600 clients to download and upload a file respectively via FTP protocol access to the SV resource list. Specifically, download and upload should be performed on pc1-pc600 respectively: if successful, the test passes; otherwise, the test fails.

[0179]

[0180] Step 5): Control 600 clients to access resources on the SV resource list. Specifically, 1 / M clients access resources on the SV resource list via HTTP to download files; 1 / M clients access resources on the SV resource list via HTTP to upload files; 1 / M clients access resources on the SV resource list via HTTPS to download files; 1 / M clients access resources on the SV resource list via HTTPS to upload files; 1 / M clients access resources on the SV resource list via FTP to download files; and 1 / M clients access resources on the SV resource list via FTP to upload files. For downloading and uploading from pc1 to pcM: success is expected; if it meets expectations, the test passes; otherwise, the test fails.

[0181]

[0182] The above approach allows testing the correctness of SSL VPN load balancing and forwarding for various protocols, such as HTTP, HTTPS, and FTP, for both upload and download. Therefore, it enables testing of the upload and download performance of different protocol traffic.

[0183] Furthermore, based on the above embodiments, when multi-point login is supported, the method further includes the following step before step S301:

[0184] Configure the DHCP protocol.

[0185] Following step S303 above, the method further includes:

[0186] Repeatedly check the number of addresses assigned by DHCP, and determine the third test result based on the results.

[0187] Specifically, in this application's embodiment, it could be address renewal for test dimension 5: the SV distributed DHCP protocol. It is understood that this test dimension can include both a micro-level perspective (a small number of clients) and a macro-level perspective (a large number of clients).

[0188] First, let's look at the microscopic perspective:

[0189] Step 1) Configure the DHCP protocol lease period to 2 minutes, support multi-point login, control 8 consecutive IP clients, and use the same account for SV authentication.

[0190]

[0191] When the first client's authentication message arrives at the SSLVPN server, the SSLVPN server will verify the client's identity in the SV user list. Upon successful authentication, the server will send an authentication confirmation to the client and maintain the client's SV session on the SSLVPN server.

[0192] After the second client message arrives at the SSLVPN server, the SSLVPN server checks if multi-point login is supported, performs authentication from the SV user list, and returns an authentication confirmation to the client after successful authentication. The remaining client authentication process is then repeated in the same manner.

[0193]

[0194]

[0195] You can remotely check the SSLVPN server to see if there are 8 SV sessions as expected, and if the account information is correct. If there are 8 DHCP-assigned addresses as expected, the test is successful. Otherwise, the test will fail.

[0196]

[0197] Step 2): After waiting for ten minutes, remotely check the SSLVPN server to see if there are 8 SV sessions as expected. The account information is correct, and the 8 DHCP-assigned addresses are as expected. If so, the test is successful. Otherwise, the test is unsuccessful.

[0198]

[0199] Step 2) can be repeated 6 times.

[0200] Step 3) Control 8 clients to download and upload a file respectively by accessing resources on the SV resource list via HTTP protocol. Specifically, download and upload are performed separately for pc1-pc8: if successful, the test passes; otherwise, the test fails.

[0201]

[0202] Step 4) Control 8 clients to download and upload a file respectively by accessing HTTPS resources on the SV resource list. Specifically, download and upload should be performed separately for pc1-pc8: if successful, the test passes; otherwise, the test fails.

[0203]

[0204] Step 5) Control 8 clients to download and upload a file respectively via FTP protocol access on the SV resource list. Specifically, download and upload should be performed for pc1-pc8 respectively: if successful, the test passes; otherwise, the test fails.

[0205]

[0206]

[0207] Next, let's look at the macro perspective:

[0208] Step 1) Configure the DHCP protocol lease period to 2 minutes, support multi-point login, control 8 consecutive IP clients, and use the same account for SV authentication for every 200 clients.

[0209]

[0210] When the first client's authentication message arrives at the SSLVPN server, the SSLVPN server will verify the client's identity in the SV user list. Upon successful authentication, the server will send an authentication confirmation to the client and maintain the client's SV session on the SSLVPN server.

[0211] After the second client message arrives at the SSLVPN server, the SSLVPN server checks if multi-point login is supported, performs authentication from the SV user list, and returns an authentication confirmation to the client after successful authentication. The remaining client authentication process is then repeated in the same manner.

[0212]

[0213] You can remotely check the SSLVPN server to see if there are 600 SV sessions as expected, and if the account information is correct. If you see that 600 addresses have been assigned by DHCP as expected, the test is successful. Otherwise, the test will fail.

[0214]

[0215]

[0216] Step 2): After waiting for ten minutes, remotely check the SSLVPN server to see if there are 600 SV sessions as expected, and if the account information is correct. Check that there are 600 DHCP-assigned addresses as expected, which meets the expectations. If so, the test passes. Otherwise, the test fails.

[0217]

[0218] Step 2) can be repeated 6 times.

[0219] Step 3) Control 600 clients to download and upload a file respectively by accessing resources on the SV resource list via HTTP protocol. Specifically, download and upload are performed separately for pc1-pc600: if successful, the test passes; otherwise, the test fails.

[0220]

[0221] Step 4) Control 600 clients to download and upload a file respectively by accessing HTTPS resources on the SV resource list. Specifically, download and upload should be performed on pc1-pc600 respectively: if successful, the test passes; otherwise, the test fails.

[0222]

[0223]

[0224] Step 5) Control 600 clients to download and upload a file respectively via FTP protocol resources on the SV resource list. Specifically, download and upload should be performed on pc1-pc600 respectively: if successful, the test passes; otherwise, the test fails.

[0225]

[0226] The above approach allows for testing of whether SSL VPN services, such as DHCP addresses, can be handled correctly. Therefore, it's possible to test the address renewal aspect of the SV distributed DHCP protocol.

[0227] Furthermore, the above embodiments are all for local authentication. If it is external authentication, an external authentication server needs to be deployed and M accounts need to be configured on the external authentication server.

[0228] In this embodiment, firstly, the effectiveness of SSLVPN-based distributed services is tested through different testing dimensions, making the testing more comprehensive. Secondly, it can be extended to different protocol types, such as from IPv4 to IPv6, from local authentication to external authentication, and from the root system to the virtual system. Thirdly, through automated methods, session information and resource access results of the SSLVPN server are statistically analyzed and compared with expected results in real time, verifying the effectiveness of SSLVPN-based distributed services in real time. Fourthly, testing observations are conducted from both micro and macro perspectives, enhancing the purposefulness and accuracy of the tests. Fifthly, through automation, the use of a Docker system to simulate clients greatly saves test client resources and enables a large number of SSLVPN distributed service processing tests that are impossible to achieve manually, making the testing more comprehensive. Finally, through automated methods, global parameters are set to control the number of simulated clients, demonstrating the flexibility of the testing.

[0229] Please refer to Figure 4 , Figure 4 This application provides a structural block diagram of a distributed service testing device based on SSLVPN. The SSLVPN-based distributed service testing device 400 includes: a first control module 401, used to control multiple clients to perform SV verification using at least one account, obtaining multiple verification results corresponding to the multiple clients; wherein, the clients include simulated clients, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account; a first determination module 402, used to determine a first test result based on the multiple verification results; a second control module 403, used to control the multiple clients to access resources, obtaining multiple access results corresponding to the multiple clients; and a second determination module 404, used to determine a second test result based on the multiple access results.

[0230] In the above scheme, authentication and resource access are automated through remote connection, controlling simulated clients to perform tests on a large number of access scenarios. Furthermore, by statistically analyzing the results of the first and second tests, the effectiveness of the distributed service based on SSLVPN can be verified in real time.

[0231] Furthermore, based on the above embodiments, the first control module 401 is specifically used to: control a portion of the multiple clients to perform SV verification using different SV accounts, and control another portion of the multiple clients to perform SV verification using different non-SV accounts; wherein, when the client performing SV verification using the SV account passes verification and the client performing SV verification using the non-SV account fails verification, the first test result indicates that the test is passed; the second control module 403 is specifically used to: control the client performing SV verification using the SV account to access the same resource on the SV resource list, and control the client performing SV verification using the non-SV account to access the same resource on the non-SV resource list; wherein, when the client performing SV verification using the SV account successfully accesses the resource and the client performing SV verification using the non-SV account fails access, the second test result indicates that the test is passed.

[0232] The above approach allows testing the load balancing of SSLVPN services by the SSLVPN server when each client logs in to the SSLVPN client with a unique SV account to access resources. It also allows testing scenarios where a large number of clients log in to the SV and access the same resource, and where a large number of clients do not log in to the SV and access the same resource, thus increasing test coverage. Therefore, it enables testing of both matching and non-matching conditions for accessing server resources.

[0233] Furthermore, based on the above embodiments, in the absence of multi-point login support, the first control module 401 is specifically used to: control the multiple clients to use the same SV account for SV verification; wherein, when only one of the multiple clients passes verification, the first test result indicates that the test is passed; the second control module 403 is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when only one of the multiple clients successfully accesses the resource, the second test result indicates that the test is passed.

[0234] The above approach allows testing how the SSLVPN server handles load balancing and correctly processes multi-signal logins when a large number of clients use the same SV account to log in to the SSLVPN client and access resources. Therefore, the multi-signal switching aspect can be tested.

[0235] Furthermore, based on the above embodiments, when multi-point login is supported, the first control module 401 is specifically used to: control the multiple clients to perform SV verification using the same SV account; wherein, when all the multiple clients pass verification, the first test result indicates that the test is passed; the second control module 403 is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test is passed.

[0236] The above approach allows testing how the SSLVPN server handles load balancing and correctly processes multi-signal logins when a large number of clients use the same SV account to log in to the SSLVPN client and access resources. Therefore, the multi-signal switching aspect can be tested.

[0237] Furthermore, based on the above embodiments, when multi-point login is supported, the first control module 401 is specifically used to: control the multiple clients to perform SV verification using the same SV account; wherein, when all the multiple clients pass verification, the first test result indicates that the test is passed; the second control module 403 is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test is passed.

[0238] The above approach allows testing how the SSLVPN server handles load balancing when each client uses a unique SV account to log in to the SSLVPN client and access resources. Therefore, it's possible to test the impact of a large number of simulated clients logging into the same account versus a large number of simulated clients logging into different accounts.

[0239] Furthermore, based on the above embodiments, the first control module 401 is specifically used to: control the multiple clients to perform SV verification using different SV accounts; the second control module 403 is specifically used to: control the multiple clients to sequentially access HTTP protocol resources, HTTPS protocol resources and FTP protocol resources on the SV resource list, and download and upload a file respectively; wherein, when all the multiple clients successfully access, download and upload, the second test result indicates that the test has passed.

[0240] The above approach allows testing the correctness of SSL VPN load balancing and forwarding for various protocols, such as HTTP, HTTPS, and FTP, for both upload and download. Therefore, it enables testing of the upload and download performance of different protocol traffic.

[0241] Furthermore, based on the above embodiments, when supporting multi-point login, the SSLVPN-based distributed service testing device 400 further includes: a configuration module for configuring the DHCP protocol; the SSLVPN-based distributed service testing device 400 further includes: a viewing module for repeatedly viewing the number of DHCP-assigned addresses and determining a third test result based on the viewing results.

[0242] The above approach allows for testing of whether SSL VPN services, such as DHCP addresses, can be handled correctly. Therefore, it's possible to test the address renewal aspect of the SV distributed DHCP protocol.

[0243] Please refer to Figure 5 , Figure 5 This application provides a structural block diagram of an electronic device 500, which includes at least one processor 501, at least one communication interface 502, at least one memory 503, and at least one communication bus 504. The communication bus 504 enables direct communication between these components, the communication interface 502 facilitates signaling or data communication with other node devices, and the memory 503 stores machine-readable instructions executable by the processor 501. When the electronic device 500 is running, the processor 501 communicates with the memory 503 via the communication bus 504. When the machine-readable instructions are invoked by the processor 501, the aforementioned distributed service testing method based on SSLVPN is executed.

[0244] For example, the processor 501 in this embodiment of the application can read a computer program from the memory 503 via the communication bus 504 and execute the computer program to implement the following method: Step S301: Control multiple clients to perform SV verification using at least one account, and obtain multiple verification results corresponding to the multiple clients; wherein, the client includes a simulated client, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account. Step S302: Determine a first test result based on the multiple verification results. Step S303: Control multiple clients to access resources, and obtain multiple access results corresponding to the multiple clients. Step S304: Determine a second test result based on the multiple access results.

[0245] The processor 501 comprises one or more, and can be an integrated circuit chip with signal processing capabilities. The processor 501 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a special-purpose processor, including a Neural-network Processing Unit (NPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors 501, some can be general-purpose processors, and others can be special-purpose processors.

[0246] The memory 503 includes one or more, which may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0247] Understandable. Figure 5 The structure shown is for illustrative purposes only; the electronic device 500 may also include components that are more advanced than those shown. Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown. Figure 5The components shown can be implemented using hardware, software, or a combination thereof. In the embodiments of this application, electronic device 500 can be, but is not limited to, physical devices such as desktop computers, laptops, smartphones, smart wearable devices, and in-vehicle devices, or virtual devices such as virtual machines. Furthermore, electronic device 500 is not necessarily a single device; it can be a combination of multiple devices, such as a server cluster, etc.

[0248] This application also provides a computer-readable storage medium that stores computer program instructions. When the computer program instructions are executed by a computer, the computer performs the distributed service testing method based on SSLVPN as described in the foregoing method embodiments.

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

[0250] Furthermore, 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.

[0251] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0252] It should be noted that if the function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0253] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0254] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A distributed service testing method based on SSLVPN, characterized in that, include: Multiple clients are controlled to perform SV verification using at least one account, resulting in multiple verification results corresponding to the multiple clients; wherein, the clients include simulated clients, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account; The first test result is determined based on the multiple verification results; Control the multiple clients to access resources and obtain multiple access results corresponding to the multiple clients; The second test result is determined based on the multiple access results; The control of multiple clients to perform SV verification using at least one account includes: The system controls a portion of the multiple clients to perform SV verification using different SV accounts, and controls another portion of the multiple clients to perform SV verification using different non-SV accounts; wherein, when the client performing SV verification using the SV account passes verification and the client performing SV verification using the non-SV account fails verification, the first test result indicates that the test is passed; The control of the multiple clients accessing resources includes: The system controls clients using the SV account for SV verification to access the same resource on the SV resource list, and controls clients using the non-SV account for SV verification to access the same resource on a non-SV resource list; wherein, when a client using the SV account for SV verification successfully accesses the resource and a client using the non-SV account for SV verification fails to access the resource, the second test result indicates that the test is passed. Alternatively, in cases where multi-signal login is not supported, controlling multiple clients to use at least one account for SV authentication includes: The multiple clients are controlled to use the same SV account for SV verification; wherein, if only one of the multiple clients passes verification, the first test result indicates that the test is passed. The control of the multiple clients accessing resources includes: Control the multiple clients to access the same resource on the SV resource list; wherein, if only one of the multiple clients successfully accesses the resource, the second test result indicates that the test has passed; Alternatively, in cases where multi-point login is supported, controlling multiple clients to use at least one account for SV verification includes: The multiple clients are controlled to use the same SV account for SV verification; wherein, when all of the multiple clients pass verification, the first test result indicates that the test is passed; The control of the multiple clients accessing resources includes: Control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test has passed; Alternatively, controlling multiple clients to perform SV verification using at least one account includes: Control the multiple clients to use different SV accounts for SV verification; The control of the multiple clients accessing resources includes: The multiple clients are controlled to sequentially access HTTP, HTTPS, and FTP resources on the SV resource list, and download and upload a file respectively; wherein, when all the multiple clients successfully access, download, and upload, the second test result indicates that the test has passed.

2. The distributed service testing method based on SSLVPN according to claim 1, characterized in that, In the case of supporting multi-signal login, before controlling multiple clients to perform SV verification using at least one account, the method further includes: Configure DHCP protocol; After controlling multiple clients to perform SV verification using at least one account, the method further includes: Repeatedly check the number of addresses assigned by DHCP, and determine the third test result based on the results.

3. A distributed service testing device based on SSLVPN, characterized in that, include: The first control module is used to control multiple clients to perform SV verification using at least one account, and obtain multiple verification results corresponding to the multiple clients; wherein, the client includes a simulated client, and the at least one account includes one SV account, multiple SV accounts, or multiple SV accounts and one non-SV account; The first determining module is used to determine a first test result based on the multiple verification results; The second control module is used to control the multiple clients to access resources and obtain multiple access results corresponding to the multiple clients; The second determining module is used to determine the second test result based on the multiple access results; The first control module is specifically used to: control a portion of the multiple clients to perform SV verification using different SV accounts, and control another portion of the multiple clients to perform SV verification using different non-SV accounts; wherein, when the client performing SV verification using the SV account passes the verification and the client performing SV verification using the non-SV account fails the verification, the first test result indicates that the test is passed; The second control module is specifically used to: control clients using the SV account for SV verification to access the same resource on the SV resource list, and control clients using the non-SV account for SV verification to access the same resource on a non-SV resource list; wherein, when a client using the SV account for SV verification successfully accesses the resource and a client using the non-SV account for SV verification fails to access the resource, the second test result indicates that the test is passed; Alternatively, in the absence of multi-signal login support, the first control module is specifically used to: control the multiple clients to use the same SV account for SV verification; wherein, when only one of the multiple clients passes verification, the first test result indicates that the test is passed; The second control module is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when only one of the multiple clients successfully accesses the resource, the second test result indicates that the test has passed; Alternatively, in the case of supporting multi-point login, the first control module is specifically used to: control the multiple clients to use the same SV account for SV verification; wherein, when all the multiple clients pass the verification, the first test result indicates that the test is passed; The second control module is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test has passed; Alternatively, in the case of supporting multi-point login, the first control module is specifically used to: control the multiple clients to use the same SV account for SV verification; wherein, when all the multiple clients pass the verification, the first test result indicates that the test is passed; The second control module is specifically used to: control the multiple clients to access the same resource on the SV resource list; wherein, when all the multiple clients successfully access the resource, the second test result indicates that the test has passed; Alternatively, the first control module may be specifically used to: control the multiple clients to use different SV accounts for SV verification; The second control module is specifically used to: control the multiple clients to sequentially access HTTP protocol resources, HTTPS protocol resources, and FTP protocol resources on the SV resource list, and download and upload a file respectively; wherein, when all the multiple clients successfully access, download, and upload, the second test result indicates that the test has passed.

4. An electronic device, characterized in that, include: Processor, memory, and bus; The processor and the memory communicate with each other via the bus; The memory stores computer program instructions that can be executed by the processor, and the processor can execute the distributed service testing method based on SSLVPN as described in claim 1 or 2 by calling the computer program instructions.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a computer, cause the computer to perform the distributed service testing method based on SSLVPN as described in claim 1 or 2.

Images