A post-quantum mobility loop detection method and system based on topology discovery and policy optimization

Abstract

The application discloses a kind of based on topology discovery and strategy optimization's post-quantum migration rate closed loop detection method and system, belong to the information security technical field of cryptographic device cluster.The method includes: periodically collecting node network connection information, forms connection snapshot;Through cross-validation, network communication topology graph is constructed;For each topological link, three kinds of encryption states are distinguished at link level, and two kinds of strategy coverage states are distinguished;The encryption state of link and strategy coverage state are crossed, generate consistency analysis result, identify core problem link;Candidate encryption strategy is automatically generated, and state transfer is carried out between four kinds of modes by strategy mode state machine;Based on consistency analysis result, calculate post-quantum migration rate, and execute new round strategy generation and issue when not convergent, form continuous closed loop.The application realizes dynamic monitoring and self-adaptive adjustment to post-quantum cryptographic migration process by combining topology discovery and strategy optimization;Effectively improve migration efficiency.

Description

Technical Field

[0001] This invention relates to the field of information security technology for cryptographic device clusters, and more specifically to a post-quantum mobility loop detection method and system based on topology discovery and policy optimization. Background Technology

[0002] Currently, with the development of quantum computing technology, existing traditional public-key cryptography algorithms such as RSA and ECDSA face the threat of being cracked by quantum computers. The publicly disclosed post-quantum cryptography (PQC) standard algorithms have moved from the research stage to the standardized deployment stage. Post-quantum migration is not a one-time replacement of a specific algorithm with a post-quantum algorithm; rather, it is a gradual process that requires evaluating the encryption state of each link, configuring encryption strategies for each link, and continuously verifying the migration effect. The core challenge for enterprises in this process is: how to accurately assess whether "post-quantum encryption truly covers all communication links that need protection," and how to automatically optimize encryption strategies based on the assessment results to continuously improve coverage.

[0003] Enterprise data centers typically host a large number of Transport Layer Security (TLS) endpoints, transparent encrypted tunnels, certificates, keys, and policy configurations simultaneously. The different protocol capabilities, topology locations, and policy coverage of these systems necessitate continuous migration assessments and policy optimizations.

[0004] The following general capabilities already exist in various technical fields:

[0005] (1) Network topology discovery: Traditional topology discovery tools, such as those based on SNMP, NetFlow, and Zeek, construct a communication relationship graph by collecting network traffic or device information, focusing on "who is communicating with whom". Encryption status detection is usually based on port or protocol characteristics to determine whether traffic is encrypted (two-state judgment). Some solutions identify encryption algorithms by parsing the cipher suite field in the TLS handshake message.

[0006] (2) Cryptographic asset inventory: The cryptographic asset discovery tool generates a list of cryptographic assets by scanning the certificates, keys and cryptographic library files on the host, which is used to assess the application-level cryptographic asset configuration.

[0007] (3) Policy Management and Distribution: In zero-trust and transparent encryption scenarios, the policy management system distributes encryption policies to each node for execution through a centralized architecture, supporting policy version management and rule hash verification. The policy execution modes are usually divided into observation (observation only), tolerance (the server accepts both encrypted and unencrypted connections), and strict (only encrypted connections are accepted), supporting incremental deployment. However, existing solutions lack a gray-scale incremental verification phase between observation and actual encryption, making it impossible to verify the feasibility of quantum encryption on a small scale before expanding coverage.

[0008] (4) Continuous monitoring and alarm: Traditional network monitoring systems can continuously monitor the network status and issue alarms when an anomaly is detected, but after the alarm is issued, the cause still needs to be analyzed manually and the strategy needs to be adjusted manually.

[0009] The above four capabilities already possess basic functions in their respective fields, but there are three gaps in their combinatorial integration: (1) As two independent subsystems, topology discovery and policy management lack a mechanism to cross-verify the link encryption state and policy coverage state, and cannot discover hidden problems such as "the traffic still follows traditional encryption even though the post-quantum policy is configured"; (2) The lack of a gray-scale incremental verification stage means that the strategy is either not executed or fully executed, making it impossible to verify the feasibility of quantum encryption on a small scale before gradually expanding it; (3) After monitoring and alarming, there is no automated closed loop from problem discovery to strategy generation, strategy upgrade and effect verification. It is still necessary to manually write strategies one by one and adjust them manually. Summary of the Invention

[0010] This invention aims to solve the technical problems in the post-quantum migration process of enterprises, such as "unclear encryption status of each link, configured encryption strategy but ineffective, inability to verify the feasibility of post-quantum encryption in a small area before expanding coverage, inability to automatically repair encrypted links, inability to automatically upgrade encryption strategies based on effects, and no improvement in coverage after multiple rounds of adjustments". It provides a post-quantum mobility closed-loop detection method and system based on topology discovery and strategy optimization, enabling the platform to automatically execute a continuous closed loop from detection to repair.

[0011] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, embodiments of the present invention provide a post-quantum mobility loop closure detection method based on topology discovery and strategy optimization, comprising: Node connection snapshot collection steps: The agent deployed on each node periodically collects the network connection information of the node, forms a connection snapshot and reports it to the management platform. The connection snapshot includes outbound connection records, inbound connection records, a list of listening ports and the encryption status classification results of each connection. Communication topology construction steps: The management platform constructs a network communication topology map based on the connection snapshots reported by each node, through cross-validation of outbound records, inbound records, and listening services, and labels each topology link with a confidence level; Link-level three-state encryption state determination steps: For each topology link, through two steps of path determination and encryption strength determination, the three encryption states of plaintext, traditional encryption and post-quantum encryption are distinguished at the link level; Policy coverage status matching steps: Obtain all currently effective encryption policies, perform policy matching on the target port of each topology link, and obtain the policy coverage status; Encryption-Policy Consistency Analysis Steps: Cross-reference the encryption state of the link with the policy coverage state to generate consistency analysis results and identify the core problematic links; Automatic strategy generation and pattern state machine processing steps: Candidate encryption strategies are automatically generated based on the problem link type, and the strategy pattern state machine is used to perform state transitions between four modes: observation, grayscale, tolerance, and strict. Coverage calculation and closed-loop iteration steps: Calculate the post-quantum mobility based on the consistency analysis results, and execute a new round of policy generation and distribution when convergence is not achieved, forming a continuous closed loop.

[0012] In one embodiment, in the communication topology construction step, the confidence level is divided into four levels based on the satisfaction of three conditions: L1 complete confirmation, L2 two-way confirmation, L3 one-way confirmation, and L4 single evidence; different processing methods and mobility calculation weights are used for problem links with different confidence levels.

[0013] In one embodiment, in the link-level three-state encryption state determination step: Path determination is used to determine whether a connection is redirected to a transparent encrypted tunnel by firewall rules, classifying connections into tunnel connections and non-tunnel connections. Encryption strength is determined by classifying the key exchange algorithm extracted from the TLS handshake result for tunneled connections, and by classifying the key exchange algorithm extracted from the TLS handshake message through passive detection for non-tunneled connections. Tunneled connections are necessarily encrypted using post-quantum encryption, while non-tunneled connections are distinguished between traditional encryption and post-quantum encryption through passive detection.

[0014] In one embodiment, the encryption-policy consistency analysis step includes three types of link encryption states: plaintext, traditional encryption, and post-quantum encryption; and two types of policy coverage states: no policy and post-quantum policy. A total of six combinations of 3×2 are generated through cross-generation. Among them, unprotected links, post-quantum migration links, and links where the policy is not effective are the core problem links. Unmanaged encrypted links do not trigger policy generation after being marked. The analysis results for the unprotected link are in plaintext and without a policy. The post-quantum migration link is the result of traditional encryption and no strategy analysis; The strategy was not effective for plaintext links or links that were traditionally encrypted but had post-quantum strategy analysis results.

[0015] In one embodiment, the policy failure analysis step is also included: the policy failure link is analyzed from six dimensions: rule consistency, firewall integrity, node online status, certificate validity, handshake success rate and gray-scale failure comparison, and corresponding repair actions are triggered based on the analysis results.

[0016] In one embodiment, in the automatic strategy generation and pattern state machine processing step, candidate encryption strategies are automatically generated according to the problem link type: an observation mode strategy is generated for an unprotected link, a gray mode strategy is generated for a post-quantum migration link, and no new strategy is generated for a link where the strategy has not taken effect, but cause analysis is triggered; the strategy pattern state machine manages the forward and reverse transitions of the strategy between the four modes of observation, gray, tolerance, and strictness. Forward transitions require multiple conditions to be met simultaneously, and reverse transitions are triggered and enter a cooling-off period when any abnormal condition is met.

[0017] In one embodiment, the observation mode passively collects the encrypted status information of the link to establish baseline data; all traffic remains on its original path, and the proxy does not access business traffic. The grayscale mode selects some connections to go through the post-quantum encryption tunnel by using a consistent hash based on the connection quintuple, while the remaining matching connections go straight through, which is used to verify the feasibility of post-quantum encryption on a small scale. The permissive mode forces matched traffic to go through a quantum-encrypted tunnel, while unmatched traffic is allowed to connect directly in plaintext or with traditional encryption. Strict mode forces matching traffic to go through a quantum-encrypted tunnel and discards all inbound connections that have not gone through the tunnel on the server side.

[0018] In one embodiment, in the coverage calculation and closed-loop iteration steps, the post-quantum mobility is the ratio of the number of post-quantum encrypted links to the total number of links, calculated by confidence weighting; the closed-loop iteration follows the monotonically increasing principle, including only adding and not deleting, no mode degradation, deduplication verification, and coverage rollback protection; for long-term unresolved problem links, in-depth cause investigation is performed and automatic repair is performed or manual intervention alarms are generated.

[0019] In one embodiment, the root cause investigation includes: 1) Peer capability detection: Check whether the remote node supports post-quantum cryptography suites; 2) Full policy verification: Check for firewall rule priority conflicts and traffic bypassing address translation rules; 3) Environment consistency check: Check the cryptographic component versions of the source and target nodes.

[0020] In a second aspect, embodiments of the present invention provide a post-quantum mobility loop closure detection system based on topology discovery and policy optimization, employing the post-quantum mobility loop closure detection method based on topology discovery and policy optimization as described in any one of the first aspects. The system includes: A node is a physical or virtual machine on which a node agent is deployed; the node agent is used to collect connection snapshots, classify tunnel handshake algorithms, passively identify the TLS encryption status of non-tunnel connections, execute policies issued by the management platform, and report tunnel handshake results. The management platform includes an observation and analysis system, an automatic policy upgrade engine, and a policy distribution module; The observation and analysis system includes: (1) a topology discovery module and a policy matching module, which independently observe the actual encryption status and policy coverage status of the link respectively; (2) a consistency analysis engine module, which performs 3×2 cross comparison, identifies the status of problematic links, and superimposes confidence weighting; (3) a cause analysis module, which performs multi-dimensional cause analysis on links where the policy has not taken effect and triggers repair actions. The automatic upgrade engine automatically generates strategies based on the type of problematic links, determines priorities by topology sorting, controls mode transitions through a state machine, and performs coverage calculations and improvement judgments. The strategy distribution module pushes the final strategy to the node agent for execution, forming a closed loop.

[0021] As can be seen from the above technical solution, compared with the prior art, the present invention has the following technical advantages: 1. Link-level three-state encryption status determination: Existing topology tools can only perform two-state determinations at the endpoint level: encrypted / unencrypted. This invention distinguishes between plaintext, traditional encryption, and post-quantum encryption at the link level through two steps: path determination and encryption strength determination. This can uncover the hidden problem of "endpoints supporting PQC but the link not using PQC".

[0022] 2. Multi-source data cross-validation: Topology construction and policy matching, through 3×2 encryption-policy consistency analysis, reveal problems that cannot be found by a single data source, especially policy-ineffective links where "quantum policy has been configured but traffic still uses traditional encryption", and graded processing according to the reliability of evidence to avoid false alarms.

[0023] 3. Problem-driven automatic policy generation: Automatically matches corresponding policy actions and encryption modes based on the problem link type, replacing manual policy writing, and is suitable for large-scale network scenarios.

[0024] 4. Gradual Automatic Upgrade Strategy: The strategy automatically switches between four modes—observation, gray-scale, lenient, and strict—based on actual operational data. The gray-scale mode verifies the feasibility of quantum encryption by selecting a portion of the traffic proportionally, filling the gap between observation and full encryption. Upgrades require multiple consecutive rounds of stable compliance before triggering; if an anomaly is detected, the process immediately reverts and pauses for a cooldown period, ensuring the upgrade process does not repeat itself.

[0025] 5. Transparent encryption is non-intrusive to applications: A post-quantum encryption tunnel is established between the source and target proxies, which is completely transparent to the application and requires no modification to the application code or adjustment of the application configuration.

[0026] 6. Steady Improvement Guarantee: During normal iterations, adhere to the monotonically increasing principle (adding only, not deleting); upgrade patterns only, not downgrading; implement deduplication verification and coverage rollback protection to ensure no strategy oscillations or coverage regressions occur. Long-standing unresolved issues are addressed through in-depth root cause analysis to avoid blind upgrades.

[0027] 7. Continuous closed loop: This invention continuously improves the migration rate by automatically executing multiple rounds of iterative logic, including detection, strategy generation, strategy upgrade, verification, and re-detection, without requiring manual intervention in each round. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, 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 embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0029] Figure 1 This is a flowchart of the post-quantum mobility loop detection method based on topology discovery and strategy optimization provided in an embodiment of the present invention. Figure 2 This is a framework diagram of a post-quantum mobility closed-loop detection system based on topology discovery and strategy optimization provided in an embodiment of the present invention. Figure 3 This is a flowchart of the interaction timing of post-quantum mobility closed-loop detection based on topology discovery and strategy optimization provided in an embodiment of the present invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] First, the key terms involved in this invention are explained as follows:

[0032] This invention belongs to the field of information security technology for cryptographic device clusters. These cryptographic devices include, but are not limited to, cryptographic machines, encryption machines, SSL VPN gateways, IPSec VPN gateways, signature verification servers, and financial data cryptographic machines. It can be specifically applied to the intersection of network security and cryptographic engineering, specifically involving zero-trust communication security and post-quantum cryptographic migration for enterprise data centers. Applicable environments include scenarios deploying transparent encrypted tunnels in non-container environments such as physical machines and virtual machines, as well as post-quantum migration management platforms that require continuous monitoring of network communication encryption status, automatic discovery of encryption problem links, and generation of remediation strategies.

[0033] Example 1: Reference Figure 1 As shown, this embodiment of the invention provides a post-quantum mobility loop closure detection method based on topology discovery and strategy optimization, comprising: Node connection snapshot collection steps: The agent deployed on each node periodically collects the network connection information of the node, forms a connection snapshot and reports it to the management platform. The connection snapshot includes outbound connection records, inbound connection records, a list of listening ports and the encryption status classification results of each connection. Communication topology construction steps: The management platform constructs a network communication topology map based on the connection snapshots reported by each node, through cross-validation of outbound records, inbound records, and listening services, and labels each topology link with a confidence level; Link-level three-state encryption state determination steps: For each topology link, through two steps of path determination and encryption strength determination, the three encryption states of plaintext, traditional encryption and post-quantum encryption are distinguished at the link level; Policy coverage status matching steps: Obtain all currently effective encryption policies, perform policy matching on the target port of each topology link, and obtain the policy coverage status; Encryption-Policy Consistency Analysis Steps: Cross-reference the encryption state of the link with the policy coverage state to generate consistency analysis results and identify the core problematic links; Automatic strategy generation and pattern state machine processing steps: Candidate encryption strategies are automatically generated based on the problem link type, and the strategy pattern state machine is used to perform state transitions between four modes: observation, grayscale, tolerance, and strict. Coverage calculation and closed-loop iteration steps: Calculate the post-quantum mobility based on the consistency analysis results, and execute a new round of policy generation and distribution when convergence is not achieved, forming a continuous closed loop.

[0034] This invention combines topology discovery with strategy optimization to achieve dynamic monitoring and adaptive adjustment of the post-quantum cryptography migration process. It effectively improves migration efficiency, avoids business interruptions caused by blind migration, and ensures that the migrated system meets quantum security requirements. At the same time, the closed-loop feedback mechanism enables the migration rate to continuously converge to the target level, significantly reducing the cost of manual intervention and migration risks.

[0035] Next, let's combine... Figure 1 Each step is described in detail. The entire process relies on bidirectional data interaction between the management platform and each node to achieve dynamic monitoring and adaptive optimization of the post-quantum cryptography migration process, including the following: 1. Steps for collecting node connection snapshots; The agent deployed on each node periodically reads the system connection table, collecting outbound connection records, inbound connection records, and a list of listening ports for that node, forming a connection snapshot which is then reported to the management platform. Outbound connection records include: source IP, destination IP, destination port, and connection status. Simultaneously, after completing the TLS handshake in the transparent encrypted tunnel, the agent associates the handshake negotiation algorithm classification result with the corresponding connection 5-tuple (source IP, source port, destination IP, destination port, protocol). For connections that do not go through the transparent encrypted tunnel, the agent passively inspects the packet content to determine whether the connection uses TLS encryption, and reports the identification result along with the connection snapshot.

[0036] 2. Steps for constructing a communication topology; The management platform constructs a network communication topology map through cross-validation based on the connection snapshots reported by each node. To verify whether a communication link exists between any two nodes, the following three conditions must be met: ① The fact that the source node has outbound records to the target IP:Port indicates that the source node did indeed initiate a connection; ② The fact that the target node has inbound records from the source IP indicates that the target end has indeed received the connection; ③ The target node has a listening service on the corresponding port, indicating that the port is indeed providing services.

[0037] Based on the cross-validation results of the three conditions, the link is labeled with a four-level confidence level according to the quality of evidence, as follows:

[0038] Subsequent problematic links with different confidence levels are handled differently: L1 and L2 are directly entered into the policy generation process as valid problematic links, L3 is downgraded in priority, and L4 is marked as "pending confirmation" and does not trigger policy generation. In this way, cross-verification is performed from both sides of the communication to ensure that each link in the topology graph is a real communication relationship, rather than an instantaneous connection attempt.

[0039] 3. Link-level three-state encryption state determination steps; For each topology link, its encryption status is determined through a two-step decision process.

[0040] The first step is path determination: determine whether the connection is hit by firewall rules and redirected to a transparent encrypted tunnel, and classify the connection into two categories: tunnel connection and non-tunnel connection.

[0041] The second step is to determine the encryption strength: for tunneled connections, the key exchange algorithm is extracted from the TLS handshake results and classified; for non-tunneled connections, the proxy passively detects the TLS handshake messages and extracts the key exchange algorithm to distinguish between traditional encryption and post-quantum encryption.

[0042] The specific judgment logic is as follows:

[0043] For non-tunneled connections, the proxy passively detects plaintext messages transmitted during the TLS handshake phase and extracts the negotiated key exchange algorithm for classification, rather than simply judging the presence of TLS characteristics. This allows non-tunneled connections to distinguish between traditional encryption and post-quantum encryption, thereby identifying the post-quantum encryption implemented by the application itself. Since the TLS handshake in a tunnel only configures post-quantum cryptographic suites, the tunneled connection is necessarily post-quantum encrypted, and there is no possibility of traditional encryption. When the tunnel handshake fails, in lenient mode, the application can establish a direct connection itself; in strict mode, the connection is discarded, and there is no degradation to traditional encryption within the tunnel.

[0044] Path determination and encryption strength determination are associated with the same link through connection quintuples, and a time window is defined based on the acquisition time of the connection snapshot. Only handshake results generated within the time window are associated with that connection. When a topology link corresponds to multiple connections, the state with the highest encryption level is selected as the encryption state of that link in the priority order of post-quantum encryption > traditional encryption > plaintext.

[0045] 4. Policy coverage state matching steps; The system retrieves all currently active encryption policies from the automatic policy upgrade engine. Each policy includes: ① the policy's scope of application, such as applicable nodes and ports; ② the encryption mode, such as observation mode, grayscale mode, permissive mode, or strict mode; and ③ the cryptographic configuration, such as post-quantum cryptography configuration. Policy matching is performed on the target port of each topology link to determine if the port is covered by a policy. The result is categorized into two policy coverage states: no policy and post-quantum policy. The automatic policy upgrade engine maintains all generated and deployed encryption policies within the system and provides policy storage, version management, and query functions.

[0046] 5. Encryption-Policy Consistency Analysis Steps; The link encryption state (plaintext / traditional encryption / post-quantum encryption) output in step 3 is cross-referenced with the policy coverage state (no policy / post-quantum policy) output in step 4 to generate a 3×2 consistency analysis result, with a total of 6 combinations:

[0047] Among them, unprotected links (plaintext and no policy), post-quantum migration links (traditional encryption and no policy), and links with ineffective policies (plaintext or traditional encryption but with post-quantum policies) are the core problematic links, triggering the subsequent automatic policy upgrade process. Unmanaged encryption (post-quantum encryption and no policy) indicates that the application itself has configured post-quantum encryption, which the proxy identifies by passively detecting TLS handshake messages. This link is already protected by post-quantum encryption but has not been managed by the management platform's policies. Therefore, marking it does not trigger policy generation to avoid interfering with existing application-layer encryption, and it is included in the migration rate calculation.

[0048] The three types of core problem links have different routing in subsequent processing: Unprotected links and post-quantum migration links skip the cause analysis and proceed directly to step 7, topology impact sorting, and step 8, automatic strategy generation; links where the strategy has not taken effect proceed to step 6, cause analysis, locate the cause of the failure, and then decide on the repair action.

[0049] The consistency analysis results also indicate the confidence level; the handling of problematic links differs depending on the confidence level.

[0050] 6. Steps for analyzing why the strategy failed to take effect; Perform multi-dimensional cause analysis on the "policy not effective links" (plaintext or traditional encryption + post-quantum policy) in the consistency analysis results to locate the specific reasons why the policy has been issued but has not actually taken effect, and trigger the corresponding remediation actions. The cause analysis checks the following dimensions one by one: (1) Rule consistency: Compare the rule hash reported by the agent with the rule hash issued by the management platform. If they are inconsistent, it means that the agent's local rules have been overwritten or modified by other processes. The repair action is to reissue the policy and force the local rules to be overwritten.

[0051] (2) Firewall integrity: Verify whether the iptables rule chain is complete, check whether there are conflicting rules with higher priority. If a conflict is found, it means that other security policies are matched first, causing traffic not to be redirected to the tunnel. The repair action is to adjust the rule priority and ensure that the encryption policy is matched first.

[0052] (3) Node online status: Check the proxy online status and last heartbeat time of the source node and the target node. If the node is offline, it means that the policy has not been delivered or executed. The repair action is to mark the node as offline and wait for the node to recover before re-delivering the policy.

[0053] (4) Certificate validity period: Check whether the certificate used by the tunnel is within the validity period or about to expire. If the certificate expires, the TLS handshake will fail and the tunnel cannot be established. The repair action is to trigger the certificate renewal process and reissue the policy after the renewal is completed.

[0054] (5) Handshake success rate: Statistically analyze the tunnel handshake success rate and failure type of this link within the current policy period. Possible reasons include the peer not supporting the post-quantum cryptographic suite, network intermediate device interception, and incompatible cryptographic component versions. The repair action is to mark the peer as incompatible according to the failure type (upgrade to the tolerant mode and wait for the peer to upgrade) or adjust the network configuration.

[0055] (6) Gray-scale failure comparison: The handshake failure records reported by the agent are associated with the links in the consistency analysis results. The handshake failure rate of the links covered by the gray-scale strategy is statistically analyzed. If the quantum handshake success rate is lower than the threshold after the gray-scale stage, it indicates that quantum encryption is not feasible after the link. The repair action is to mark the link as "gray-scale verification failure" and fall back to the observation mode to avoid unverified links directly entering the tolerant or strict mode.

[0056] After the repair actions are implemented, the effects are verified in the next round of closed-loop testing. The depth of the root cause analysis is differentiated according to the confidence level: for L1 and L2 links where the strategy has not taken effect, a complete multi-dimensional root cause analysis is performed; for L3 links where the strategy has not taken effect, a lightweight analysis is performed, and a more in-depth analysis is conducted after the confidence level is improved in the next round.

[0057] 7. Topology affects sorting steps; Based on the network communication topology diagram, the core problem links identified in step 5 are sorted according to the following rules to determine the processing order for subsequent automatic strategy generation: First, aggregate by target port: group the problematic links by target node and target port, and count the number of source nodes associated with each group. A target port with more associated source nodes indicates that more business systems communicate through that port, and the impact of problematic links on that port is larger, so it should be dealt with first.

[0058] Then, within the same group, sort by confidence level: for multiple problematic links associated with the same target port, those with higher confidence levels are processed first. Link data with higher confidence levels is more reliable, and strategies generated based on these links are more likely to take effect on the first try, reducing subsequent repeated adjustments.

[0059] Finally, sort by problem link type: when the number of source nodes associated with the target port and the confidence level are the same, the unprotected link (plaintext + no policy) is preferred over the post-quantum migration link (traditional encryption + no policy), because the plaintext link has a higher security risk and should be configured with an encryption policy first.

[0060] The sorting results determine the processing order of the automatically generated strategies in step 8: the problem links ranked higher are given priority in the strategy generation process. Simultaneously, the sorting process also produces an additional result—automatically determining the applicable scope for each strategy: the target port of the strategy is directly obtained from the grouping information, and the set of source nodes for the strategy is obtained by summing the source nodes of all problem links under that group.

[0061] 8. Steps for automatically generating strategies driven by problem link types; The sorted list of problem chains is traversed, and candidate encryption strategies are automatically generated based on the problem chain type. The generated strategies adopt one of the following four modes: (1) Observation mode: No iptables redirection rules are deployed, and no traffic is interfered with. The agent only passively reads the kernel connection table and bypasses the detection packets to collect encrypted status information of the link and establish baseline data. In this mode, all traffic maintains its original path, and the agent does not access business traffic.

[0062] (2) Gray-scale mode: For traffic matching the policy, i.e., traffic matching the specified source node and destination port, iptables redirection rules are deployed to forward the matching traffic to the proxy. The proxy selects a portion of the matching connections (controlled by the gray-scale percentage parameter, e.g., 10%) based on the consistent hash of the connection tuple (calculating the hash value using the source IP, destination IP, and destination port in the tuple as input, and mapping the hash value to the gray-scale percentage) to go through the post-quantum encryption tunnel, while the remaining matching connections are passed through directly (still following the original path). Traffic that does not match the policy is unaffected. The purpose of the gray-scale mode is to verify the handshake success rate of the post-quantum encryption tunnel on a small scale, confirm the technical feasibility of post-quantum encryption on this link, and avoid the risk of a full switch. The gray-scale percentage starts from a low value and can be gradually increased after verification.

[0063] (3) Tolerant Mode: Deploy iptables redirection rules for traffic matching the policy, forcing all matching traffic to go through the post-quantum encryption tunnel. Traffic that does not match the policy originates from clients without a deployed proxy and is allowed to connect directly to the server in plaintext or traditional encryption, without the server imposing mandatory inbound control. Tolerant mode ensures that all matching traffic within the policy coverage is post-quantum encrypted, while not blocking normal communication from clients that have not yet deployed a proxy. It is suitable for the transition phase during migration when new and old clients coexist.

[0064] (4) Strict Mode: Deploy iptables redirection rules for traffic matching the policy, forcing all matching traffic to go through the quantum-encrypted tunnel; at the same time, deploy iptables rules on the server side to discard all inbound connections that do not go through the tunnel. In strict mode, traffic that does not match the policy, i.e., traffic from clients without a deployed proxy, is discarded by the server, and the server only accepts connections that go through the tunnel and are quantum-encrypted. Strict mode achieves complete control, requiring all clients accessing the server port to have a deployed proxy and connect through the tunnel.

[0065] Based on the correspondence between problem link types and policy modes, candidate encryption policies are automatically generated: 1) Unprotected link (plaintext + no policy) → Automatically generate observation mode policy, observe only and do not intervene.

[0066] 2) Post-quantum migration link (traditional encryption + no policy) → automatically generate grayscale mode policy, redirect matching traffic to the proxy, and select some connections to go through the post-quantum encryption tunnel through consistent hashing, which is used to verify the feasibility of post-quantum encryption on a small scale.

[0067] 3) Policy not effective link (plaintext or traditional encryption + post-quantum policy) → no new policy is generated, triggering step 6 for troubleshooting.

[0068] 4) Unmanaged encryption (post-quantum encryption + no policy) → No policy generation is specified.

[0069] The automatically generated policy content follows these guidelines: The policy's scope of application automatically extracts the target IP and target port from the problem link record, and extracts all source nodes with the target IP and port as the destination from the topology map as the policy deployment target; the password configuration defaults to post-quantum configuration; before generation, it checks whether a policy covering the same target IP, port, and source node already exists to avoid duplication.

[0070] 9. Strategy pattern state machine processing steps; For the candidate policies generated in step 8 and the existing historical policies in the system, the policy pattern state machine manages their state transitions between the four modes: observation, grayscale, tolerant, and strict.

[0071] (1) Positive transfer conditions (upgrade); Each mode must meet the following conditions to upgrade to the next level: Observation → Grayscale: ① The system has run for at least a preset threshold detection period. This preset threshold can be set on the management platform, allowing you to set the interval between each detection period and the number of detections. The detection interval can be set from 5 to 60 minutes. For example, with a detection period of 5 minutes and a preset threshold of 6, this means that the strategy must run continuously in observation mode for approximately 30 minutes (6 periods × 5 minutes) and accumulate at least this number of connection snapshots and handshake data before it is ready for upgrade. This threshold can also be adaptively adjusted by the management platform based on network size and traffic stability: a lower value (e.g., 3-4 periods) is used when traffic is stable to speed up the migration process, and a higher value (e.g., 8-10 periods) is used when traffic fluctuates significantly or link confidence is low to avoid misjudgments based on instantaneous data. ② The proxy has confirmed that the strategy is effective (rule hash matching in the ACK receipt); ③ The target port is online; ④ Certificates and post-quantum cryptography configurations are ready. These conditions ensure that the system has a full understanding of the baseline status of the link and has the basic conditions to start post-quantum cryptography testing.

[0072] Grayscale to Tolerant Mode: ① Sufficient detection cycles have been run to ensure that enough observation data has been accumulated during the grayscale phase; ② The success rate of the post-quantum handshake in the grayscale connection is not lower than a set threshold, such as 95%, verifying that post-quantum encryption is technically feasible and stable on this link. The grayscale percentage can be gradually increased to 100% during this phase, and a transition to the tolerant mode is triggered when the handshake success rate consistently meets the target.

[0073] Tolerant → Strict: ① Sufficient detection cycles have been run; ② The success rate of the post-quantum handshake remains consistently higher than the set threshold; the default success rate threshold is 99%, with a duration of 5 cycles, which can be customized in the management platform. If the success rate falls below this threshold in any cycle, the count will restart, indicating that the post-quantum encryption has been stable on this link for a long time and is ready for full mandatory takeover; ③ The proportion of non-tunnel connections without matching policies continues to decrease to zero or below the set threshold. This proportion of non-tunnel connections is the ratio of the number of non-tunnel connections without matching policies to the total number of inbound connections to the target port within one detection cycle. The threshold is no higher than 1% (ideally 0%). "Continuous" is defined in the same way as condition ②, indicating that the client to be protected has basically completed the proxy deployment, and the remaining non-tunnel connections are only tolerable noise (such as scanning probes, health checks), which will not affect normal business after being discarded. Condition 3 is reachable in a controlled network environment where all clients have deployed the agent; in scenarios where there are external clients without deployed agents, if the proportion of non-tunnel connections remains stable and no longer decreases for several consecutive rounds, it indicates that the remaining clients cannot complete deployment in the short term. In this case, skip condition 3 and directly enter strict mode and generate an alarm to prompt the operation and maintenance personnel for confirmation, or maintain the operation in lenient mode.

[0074] (2) Reverse transfer conditions (rollback); A reverse transfer is triggered when any of the following conditions are met, and the judgment is stricter than that of a forward transfer, so as to form an asymmetric design of "cautious upgrade and timely rollback": ① Handshake failure rate continuously exceeds the set threshold: The failure rate is the ratio of the number of failed quantum handshakes in a detection cycle to the total number of handshakes. The threshold is configurable, and the default value is greater than 5% (i.e., the success rate drops below 95%). "Continuously" means that the failure rate of each cycle exceeds the configured threshold for no less than 2 consecutive detection cycles. If the failure rate drops in any cycle, the count will be reset to avoid false triggering by a single jitter.

[0075] ② Abnormal events in certificate or password configuration: The certificate is less than the preset security margin (e.g., ≤7 days) before expiration, or it is revoked, or the signature chain is broken; or the hash configured in the password component is inconsistent with the hash configured by the management platform, or the configuration is rolled back to a non-post-quantum algorithm.

[0076] Rollback target: Rollback to the next lower-level mode that was most recently stable before the trigger; when the grayscale mode triggers rollback, it will directly rollback to the observation mode.

[0077] Cooldown period: After rollback, the automatic upgrade of this strategy will be paused for 3 to 5 detection cycles, during which the lower mode after rollback will continue to run; after the cooldown period ends, the forward transition will be automatically retried, and if an anomaly is detected again during the process, the cooldown period will be counted again.

[0078] If the same strategy fails to operate stably after three cooling-off periods, automatic optimization will be suspended and a manual intervention alarm will be generated. Proceed to step 11 for in-depth cause investigation.

[0079] 10. Coverage calculation and trend reporting steps; The post-quantum mobility rate is calculated based on the consistency analysis results: it is the ratio of the number of post-quantum encrypted links to the total number of links. The number of post-quantum encrypted links includes links in the compliant state (tunnel encrypted and policy-controlled) and uncontrolled encrypted links (applications have configured post-quantum encryption but have no policy); both are included in the migrated links. The mobility rate is calculated using confidence weighting, with L1 having the highest weight and L4 the lowest. Simultaneously, sub-indicators are calculated: the percentage of links without policy, the percentage of links with ineffective policy, and the percentage of post-quantum migrated links.

[0080] The migration rate and various metrics of the current round are compared with those of historical rounds to generate a trend report, including: the direction of change in the migration rate (e.g., continuous increase, stagnation, or decrease), the trend of changes in the number of various problem chains (e.g., which types of problems are decreasing, which types are increasing, or stagnating), and changes in the distribution of strategy patterns (e.g., changes in the number of strategies under each pattern). The trend report is used to determine whether the overall optimization direction is correct and which types of problem chains should be focused on in the future.

[0081] The following conditions are checked to improve the judgment: fully compliant (the list of problematic links is empty) or nearly compliant (the number of problematic links no longer decreases in several consecutive iterations). If the conditions are met, the final coverage report is output; otherwise, the unresolved problematic links are passed to step 11 for further processing.

[0082] 11. Iterative processing steps for the problem chain; For the unresolved problem links submitted in step 10, the following rules will be applied in this iteration: Each iteration follows a monotonically increasing principle, ensuring the optimization process only progresses and never regresses. Here, "normal iteration" refers to iterations that do not trigger the reverse transition condition in step 9, i.e., iterations that do not detect anomalies such as a handshake failure rate exceeding a threshold or certificate expiration. Specific rules are as follows: (1) Add only, do not delete: Only new strategies or upgrade modes can be added. Strategies that have been verified and effective in previous iterations are not allowed to be deleted. (2) Mode does not downgrade: In normal iterations, strategies are only upgraded and not downgraded (observation → grayscale → tolerant → strict). (3) Deduplication verification: Before generating a new strategy, check whether a strategy covering the same port and node already exists. Do not generate duplicate strategies. (4) Coverage rollback protection: If the coverage decreases due to the new strategy added in this round, the new strategy added in this round will be revoked. This will not affect the strategies that have been verified in previous rounds.

[0083] For long-standing unresolved issues that persist despite multiple rounds of investigation, a thorough root cause analysis should be conducted first. This analysis should include: 1) Peer capability detection: Check whether the remote node supports post-quantum cryptography suites; 2) Verify the entire policy process, checking for firewall rule priority conflicts and traffic bypassing address translation rules; 3) Environment consistency check: Check the cryptographic component versions of the source and target nodes.

[0084] The handling method will be determined based on the investigation results: If the underlying cause can be fixed, such as rule priority conflict or configuration error, it will be automatically fixed and then wait for the next round of verification; if the underlying cause cannot be automatically fixed, such as the peer not supporting the post-quantum cryptography suite or certificate system incompatibility, the automatic optimization of this link will be suspended and a manual intervention alarm will be generated.

[0085] After step 11 is completed, the newly added and adjusted strategies in this round will be issued and executed in step 12; the repaired links and the suspended links will wait for the next round of closed-loop detection to verify the effect.

[0086] 12. Strategy distribution, tunnel establishment, and closed-loop procedures; The final policy, processed by the state machine, is pushed to the proxies on each node for execution. The source proxy intercepts matching outbound traffic according to the policy, establishes a post-quantum encrypted tunnel with the target proxy, and the target proxy forwards the received traffic to its local service, forming an encrypted channel from the source proxy to the target proxy. The entire process is completely transparent to the application. In strict mode, the target proxy simultaneously rejects all inbound connections that do not go through the tunnel.

[0087] After the policy is issued, wait for an observation window, which is the period during which the policy runs in the actual network and accumulates enough handshake data and connection state data. After the observation window ends, return to step 1 to start a new round of closed-loop detection.

[0088] Example 2: Based on the same inventive concept, this embodiment of the invention also provides a post-quantum mobility loop detection system based on topology discovery and strategy optimization. Since the principle of the problem solved by this system is similar to the aforementioned post-quantum mobility loop detection method based on topology discovery and strategy optimization, the implementation of this system can refer to the implementation of the aforementioned method, and the repeated parts will not be described again.

[0089] like Figure 2 As shown, the system includes nodes and a management platform. Nodes refer to various devices or service instances in the network that have deployed cryptographic components, such as servers, gateways, and terminal devices; these are the objects of the migration operation. The management platform, as the centralized control terminal, is responsible for topology discovery, policy formulation, migration scheduling, and closed-loop feedback.

[0090] The node agent is deployed on each node and is responsible for collecting connection snapshots, classifying tunnel handshake algorithms, passively identifying the TLS encryption status of non-tunnel connections, executing policies issued by the management platform, and reporting tunnel handshake results.

[0091] The management platform consists of three parts: an observation and analysis system, an automatic policy upgrade engine, and a policy distribution module.

[0092] The observation and analysis system includes: (1) a topology discovery module and a policy matching module, which independently observe the actual encryption status and policy coverage status of the link; (2) a consistency analysis engine module, which performs 3×2 cross comparison, identifies the status of problematic links, and superimposes confidence weighting; and (3) a cause analysis module, which performs multi-dimensional cause analysis on links where the policy has not taken effect and triggers repair actions. The automatic policy upgrade engine automatically generates policies based on the type of problem link, determines priorities through topology sorting, controls mode transitions through state machines, and ensures monotonically increasing coverage calculation and improvement judgment.

[0093] The policy delivery module pushes the final policy to the node agent for execution, forming a closed loop.

[0094] Protocol flow description as follows Figure 3 As shown: S1, the node agent reports the connection snapshot, tunnel handshake algorithm classification results, and TLS detection results of non-tunnel connections to the observation layer of the management platform.

[0095] S2. The observation layer outputs the link encryption status and policy coverage status through topology discovery and policy matching, respectively, and sends them to the analysis layer.

[0096] S3, the analysis layer performs consistency analysis and cause analysis, outputs a list of problem links and cause analysis results, and sends them to the upgrade layer.

[0097] S4. After completing the problem link sorting, automatic policy generation, pattern state machine processing and coverage calculation, the upgrade layer will send the final policy to the node agent for execution.

[0098] S5. The node agent returns an ACK receipt and tunnel handshake result to the observation layer, waits for the observation window, and then reports a new round of snapshots to form a closed loop.

[0099] The entire process relies on two-way data interaction between the management platform and each node, thereby enabling dynamic monitoring and adaptive optimization of the post-quantum cryptography migration process.

[0100] Example 3: A company's data center deploys 50 servers (a mix of physical and virtual machines), with each server having a node agent deployed.

[0101] 1. First round of testing: The management platform constructed approximately 200 topology links through cross-validation of three conditions. The three-state encryption status determination results showed that approximately 60% of the links were post-quantum encrypted, approximately 15% were traditionally encrypted, and approximately 25% were plaintext. Policy coverage matching showed that approximately 70% of the links already had post-quantum policies, and approximately 30% had no policies. A 3×2 consistency analysis was performed between the encryption status and policy coverage status, identifying three core problem links: unprotected links (plaintext and no policy), post-quantum migration links (traditional encryption and no policy), and links where policies were ineffective (plaintext or traditional encryption but with post-quantum policies). Analysis of the reasons for ineffective policies on these links identified firewall rule priority conflicts, proxy offline issues, etc., triggering corresponding remediation actions. The system automatically generated policies after sorting by topology impact: observation mode policies were generated for unprotected links, gray-scale mode policies for post-quantum migration links, and no new policies were generated for links where policies were ineffective; they were directly remediated.

[0102] 2. Gray-scale verification stage: After running for several detection cycles in observation mode, the upgrade conditions are met, and the system upgrades to grayscale mode. During grayscale operation, the success rate of post-quantum handshake on individual links falls below the threshold. The system marks these links as "grayscale verification failed" and rolls back to observation mode for a cooling-off period. The cause analysis revealed that the peer does not support post-quantum cryptographic suites. The handshake success rate of the remaining grayscale strategies reaches the threshold, and the proportion of grayscale traffic gradually increases, triggering a transition from grayscale to a more tolerant mode.

[0103] 3. Tolerance Operation Phase: In lenient mode, all traffic matching the policy is forced to go through the quantum-encrypted tunnel. Links where the original policy was ineffective are confirmed to be effective after the cause is fixed, and offline links of the original proxy are automatically reissued the policy after the node recovers. After running in lenient mode for several detection cycles, the handshake success rate continues to meet the target, and the proportion of non-tunnel connections continues to decrease, triggering a transition from lenient to strict mode.

[0104] 4. Strict Mode and Final Result: In strict mode, the server discards all inbound connections that do not pass through the tunnel, achieving complete control. After multiple rounds of automatic iteration, the post-quantum migration rate has increased from approximately 60% initially to over 90%. Links that failed during gray-scale deployments were re-verified and passed after the peer upgrade; long-standing unresolved issues were partially automatically fixed and eliminated after in-depth investigation, while others were eliminated after forced upgrades; a small number of links that did not support post-quantum cryptographic suites on the peer generated manual intervention alarms. Additionally, a small number of unmanaged encrypted links (the applications themselves have configured post-quantum encryption) were marked but did not trigger policy generation; these were included in the migration rate calculation.

[0105] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0106] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A post-quantum mobility loop closure detection method based on topology discovery and strategy optimization, characterized in that, include: Node connection snapshot collection steps: The agent deployed on each node periodically collects the network connection information of the node, forms a connection snapshot and reports it to the management platform. The connection snapshot includes outbound connection records, inbound connection records, a list of listening ports and the encryption status classification results of each connection. Communication topology construction steps: The management platform constructs a network communication topology map based on the connection snapshots reported by each node, through cross-validation of outbound records, inbound records, and listening services, and labels each topology link with a confidence level; Link-level three-state encryption state determination steps: For each topology link, through two steps of path determination and encryption strength determination, the three encryption states of plaintext, traditional encryption and post-quantum encryption are distinguished at the link level; Policy coverage status matching steps: Obtain all currently effective encryption policies, perform policy matching on the target port of each topology link, and obtain the policy coverage status; Encryption-Policy Consistency Analysis Steps: Cross-reference the encryption state of the link with the policy coverage state to generate consistency analysis results and identify the core problematic links; Automatic strategy generation and pattern state machine processing steps: Candidate encryption strategies are automatically generated based on the problem link type, and the strategy pattern state machine is used to perform state transitions between four modes: observation, grayscale, tolerance, and strict. Coverage calculation and closed-loop iteration steps: Calculate the post-quantum mobility based on the consistency analysis results, and execute a new round of policy generation and distribution when convergence is not achieved, forming a continuous closed loop.

2. The method according to claim 1, characterized in that, In the communication topology construction step, the confidence level is divided into four levels according to the satisfaction of three conditions: L1 complete confirmation, L2 two-way confirmation, L3 one-way confirmation, and L4 single evidence; different processing methods and mobility calculation weights are used for problem links with different confidence levels.

3. The method according to claim 1, characterized in that, In the link-level three-state encryption state determination step: Path determination is used to determine whether a connection is redirected to a transparent encrypted tunnel by firewall rules, classifying connections into tunnel connections and non-tunnel connections. Encryption strength is determined by classifying the key exchange algorithm extracted from the TLS handshake result for tunneled connections, and by classifying the key exchange algorithm extracted from the TLS handshake message through passive detection for non-tunneled connections. Tunneled connections are necessarily encrypted using post-quantum encryption, while non-tunneled connections are distinguished between traditional encryption and post-quantum encryption through passive detection.

4. The method according to claim 1, characterized in that, In the encryption-policy consistency analysis step, the link encryption state includes three types: plaintext, traditional encryption, and post-quantum encryption, and the policy coverage state includes two types: no policy and post-quantum policy. A total of six combinations of 3×2 are generated by cross-generating. Among them, unprotected links, post-quantum migration links, and links where the policy is not effective are the core problem links. Unmanaged encrypted links do not trigger policy generation after being marked. The analysis results for the unprotected link are in plaintext and without a policy. The post-quantum migration link is the result of traditional encryption and no strategy analysis; The strategy was not effective for plaintext links or links that were traditionally encrypted but had post-quantum strategy analysis results.

5. The method according to claim 4, characterized in that, It also includes a step to analyze why the policy is not effective: the policy is not effective in six dimensions: rule consistency, firewall integrity, node online status, certificate validity, handshake success rate and comparison of gray-scale failures, and corresponding repair actions are triggered based on the analysis results.

6. The method according to claim 1, characterized in that, In the automatic strategy generation and pattern state machine processing steps, candidate encryption strategies are automatically generated according to the problem link type: an observation mode strategy is generated for an unprotected link, a grayscale mode strategy is generated for a post-quantum migration link, and no new strategy is generated for a link whose strategy has not taken effect, thus triggering the cause analysis. The strategy mode state machine management strategy involves forward and reverse transitions between four modes: observation, grayscale, tolerance, and strictness. Forward transitions require multiple conditions to be met simultaneously, while reverse transitions are triggered and enter a cooldown period when any abnormal condition is met.

7. The method according to claim 6, characterized in that, The observation mode passively collects encrypted status information of the link to establish baseline data; all traffic remains on its original path, and the proxy does not access business traffic. The grayscale mode selects some connections to go through the post-quantum encryption tunnel by using a consistent hash based on the connection quintuple, while the remaining matching connections go straight through, which is used to verify the feasibility of post-quantum encryption on a small scale. The permissive mode forces matched traffic to go through a quantum-encrypted tunnel, while unmatched traffic is allowed to connect directly in plaintext or with traditional encryption. Strict mode forces matching traffic to go through a quantum-encrypted tunnel and discards all inbound connections that have not gone through the tunnel on the server side.

8. The method according to claim 1, characterized in that, In the coverage calculation and closed-loop iteration steps, the post-quantum mobility is the ratio of the number of post-quantum encrypted links to the total number of links, calculated by confidence weighting; the closed-loop iteration follows the monotonically increasing principle, including only adding and not deleting, no mode degradation, deduplication verification, and coverage rollback protection; for long-term unresolved problem links, in-depth cause investigation is performed and automatic repair is performed or manual intervention alarms are generated.

9. The method according to claim 8, characterized in that, The investigation into underlying causes includes: 1) Peer capability detection: Check whether the remote node supports post-quantum cryptography suites; 2) Full policy verification: Check for firewall rule priority conflicts and traffic bypassing address translation rules; 3) Environment consistency check: Check the cryptographic component versions of the source and target nodes.

10. A post-quantum mobility closed-loop detection system based on topology discovery and strategy optimization, characterized in that, The system, employing the post-quantum mobility loop closure detection method based on topology discovery and policy optimization as described in any one of claims 1-9, comprises: A node is a physical or virtual machine on which a node agent is deployed; the node agent is used to collect connection snapshots, classify tunnel handshake algorithms, passively identify the TLS encryption status of non-tunnel connections, execute policies issued by the management platform, and report tunnel handshake results. The management platform includes an observation and analysis system, an automatic policy upgrade engine, and a policy distribution module; The observation and analysis system includes: (1) a topology discovery module and a policy matching module, which independently observe the actual encryption status and policy coverage status of the link respectively; (2) a consistency analysis engine module, which performs 3×2 cross comparison, identifies the status of problematic links, and superimposes confidence weighting; (3) a cause analysis module, which performs multi-dimensional cause analysis on links where the policy has not taken effect and triggers repair actions. The automatic upgrade engine automatically generates strategies based on the type of problematic links, determines priorities by topology sorting, controls mode transitions through a state machine, and performs coverage calculations and improvement judgments. The strategy distribution module pushes the final strategy to the node agent for execution, forming a closed loop.

Images