Diagnosing TSPU impact

Communication service providers are required to install TSPU in their networks — technical complexes for analyzing and filtering passing traffic; for more details, see the subsection What is TSPU. TSPU can affect traffic speed and cause connection issues with certain protocols.

If traffic issues show signs of TSPU impact, you can perform a TSPU impact diagnosis and follow up with certain actions based on the results.

What is TSPU

TSPU, or technical means for countering threats, are DPI complexes installed at the request of Roskomnadzor at telecommunication nodes to filter passing traffic. TSPU can block or slow down traffic based on various criteria: IP addresses, SNI (Server Name Indication), QUIC metadata, protocol signatures, and others.

Large mobile, broadband, and satellite service providers, as well as Internet Exchange Point (IXP) operators, are required to install TSPU in their networks. All user traffic must pass through TSPU. TSPU equipment is managed by the Main Radio Frequency Centre (or the Centre for Monitoring and Control of Public Communications Network); service providers do not have access to it.

TSPU are used within the country, as well as at cross-border communication nodes where traffic enters and leaves Russia. At such points, analysis and filtering may occur both within the provider's network and at the junction of national and international infrastructure, which allows for filtering traffic at network borders.

Due to TSPU operations, both permanent and intermittent issues with the transmission of certain types of traffic may be observed within Russia and during cross-border data exchange.

Signs of TSPU impact

TSPU can cause connection issues via SSH, HTTP/HTTPS, VPN, and sometimes RDP protocols. At the same time, the server responds to ICMP requests, and checks using the mtr and telnet utilities execute successfully. In rare cases, network speed issues may occur when connecting via these protocols. Connection and speed issues can be both permanent and intermittent.

Issues are most often observed if a public shared IP address is used on a dedicated server. In rare cases, issues are also observed with addresses from a public dedicated subnet.

Perform a TSPU impact diagnosis

To receive full diagnostic data, you need to perform a diagnosis for two servers between which connection issues are observed. One of the servers must be located within Servercore infrastructure:

• destination server (destination) — the server you are trying to connect to;
• source server (source) — the server from which you are trying to connect to the destination server.

The diagnosis must be performed in two directions—from the source server to the destination and from the destination server to the source. If you cannot connect to one of the servers, perform the diagnosis only from the second one.

1. Perform a diagnosis from the source server to the destination.
2. Perform a diagnosis from the destination server to the source.
3. Send us the diagnostic results.
4. If TSPU impact is suspected based on the diagnostic results, you can follow the actions based on the diagnosis results.

1. Perform a diagnosis from the source server to the destination

The diagnostic process depends on the protocol experiencing issues.

SSH

Linux

1. Connect to the source server. If the server is located in Servercore infrastructure, use the Connect to a server guide.

2. Create a text file to save the diagnostic results.

3. Check destination server availability:

   3.1. Check destination server availability. The check will show whether ICMP packets are passing:

   ping <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   3.2. Save the output to the diagnostic results file you created in step 2.

4. Check the SSH connection:

   4.1. Connect to the destination server via SSH with verbose output information about the connection:

   ssh -v root@<destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   4.2. Save the output to the diagnostic results file you created in step 2.

5. Scan destination server ports:

   5.1. Install the nmap utility; for more details, see the Linux Distributions article in the nmap documentation.

   5.2. Perform a port scan without checking server availability first:

   nmap -Pn <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   5.3. Save the output to the diagnostic results file you created in step 2.

6. Check the TCP connection on port 22:

   6.1. Install the telnet utility; for more details, see the Telnet Applications article in the telnet documentation.

   6.2. Connect to the destination server via TCP:

   telnet <destination_ip_address> 22

   Specify <destination_ip_address> — the destination server IP address.

   6.3. Save the output to the diagnostic results file you created in step 2.

7. Perform a traceroute to the destination server:

   7.1. Install the mtr utility. Read more on GitHub mtr.

   7.2. Perform a traceroute to the destination server:

   mtr --address <destination_ip_address> -bwzrc 100 <source_ip_address>

   Specify:

   • <destination_ip_address> — the destination server IP address; ;
   • <source_ip_address> — the source server IP address.

   7.3. Save the output to the diagnostic results file you created in step 2.

8. Collect a traffic dump to the destination server:

   8.1. Install the tcpdump utility; for more details, see the documentation on tcpdump.

   8.2. Collect a traffic dump. The command will create a file in .pcap format:

   tcpdump --count 1000 -w dump_<source_ip_address>_<destination_ip_address>.pcap host <destination_ip_address>

   Specify:

   • <source_ip_address> — the source server IP address; ;
   • <destination_ip_address> — the destination server IP address.

Windows

1. Connect to the source server. If the server is located in Servercore infrastructure, use the Connect to a server guide.

2. Create a text file to save the diagnostic results.

3. Run PowerShell as an administrator.

4. Check destination server availability:

   4.1. Check destination server availability. The check will show whether ICMP packets are passing:

   ping <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   4.2. Save the output to the diagnostic results file you created in step 2.

5. Check the SSH connection:

   5.1. Connect to the destination server via SSH:

   ssh -v root@<destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   5.2. Save the output to the diagnostic results file you created in step 2.

6. Scan ports:

   6.1. Install the nmap utility; for more details, see the Windows article in the nmap documentation.

   6.2. Perform a port scan without checking server availability first:

   nmap -Pn <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   6.3. Save the output to the diagnostic results file you created in step 2.

7. Check the TCP connection on port 22:

   7.1. Install the telnet utility; for more details, see the Telnet Applications article in the telnet documentation.

   7.2. Connect to the destination server via TCP:

   telnet <destination_ip_address> 22

   Specify <destination_ip_address> — the destination server IP address.

   7.3. Save the output to the diagnostic results file you created in step 2.

8. Perform a traceroute to the destination server:

   8.1. Perform a traceroute.

   8.2. Save the output to the diagnostic results file you created in step 2.

9. Collect a network traffic dump to the destination server. Name the dump file as dump_<source_ip_address>_<destination_ip_address>, where <source_ip_address> is the source server IP address, and <destination_ip_address> is the destination server IP address.

HTTP/HTTPS

Linux

1. Connect to the source server. If the server is located in Servercore infrastructure, use the Connect to a server guide.

2. Create a text file to save the diagnostic results.

3. Check destination server availability:

   3.1. Check destination server availability. The check will show whether ICMP packets are passing:

   ping <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   3.2. Save the output to the diagnostic results file you created in step 2.

4. Check service availability on the destination server:

   4.1. Check service availability:

   curl -Iv http://<example.com>

   Specify <example.com> — the service domain name.

   4.2. Save the output to the diagnostic results file you created in step 2.

5. Scan destination server ports:

   5.1. Install the nmap utility; for more details, see the Linux Distributions article in the nmap documentation.

   5.2. Perform a port scan without checking server availability first:

   nmap -Pn <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   5.3. Save the output to the diagnostic results file you created in step 2.

6. Check the HTTP/HTTPS connection on ports 80 and 443:

   6.1. Install the telnet utility; for more details, see the Telnet Applications article in the telnet documentation.

   6.2. Check the connection on port 80:

   telnet <destination_ip_address> 80

   Specify <destination_ip_address> — the destination server IP address.

   6.3. Check the connection on port 443:

   telnet <destination_ip_address> 443

   Specify <destination_ip_address> — the destination server IP address.

   6.4. Save the outputs to the diagnostic results file you created in step 2.

7. Perform a traceroute to the destination server:

   7.1. Install the mtr utility; read more on GitHub mtr.

   7.2. Perform a traceroute:

   mtr --address <destination_ip_address> -bwzrc 100 <source_ip_address>

   Specify:

   • <destination_ip_address> — the destination server IP address; ;
   • <source_ip_address> — the source server IP address.

   7.3. Save the output to the diagnostic results file you created in step 2.

8. Collect a traffic dump:

   8.1. Install the tcpdump utility; for more details, see the documentation on tcpdump.

   8.2. Collect a traffic dump. The command will create a separate data file in .pcap format:

   tcpdump --count 1000 -w dump_<source_ip_address>_<destination_ip_address>.pcap host <destination_ip_address>

   Specify:

   • <destination_ip_address> — the destination server IP address; ;
   • <source_ip_address> — the source server IP address.

Windows

1. Connect to the source server. If the server is located in Servercore infrastructure, use the Connect to a server guide.

2. Create a text file to save the diagnostic results.

3. Run PowerShell as an administrator.

4. Check destination server availability:

   4.1. Check destination server availability. The check will show whether ICMP packets are passing:

   ping <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   4.2. Save the output to the diagnostic results file you created in step 2.

5. Check service availability on the destination server:

   5.1. Check service availability:

   curl -Iv http://<example.com>

   Specify <example.com> — the service domain name.

   5.2. Save the output to the diagnostic results file you created in step 2.

6. Scan destination server ports:

   6.1. Perform a port scan of the destination server:

   nmap -Pn <destination_ip_address>

   Specify <destination_ip_address> — the destination server IP address.

   6.2. Save the output to the diagnostic results file you created in step 2.

7. Check the HTTP/HTTPS connection on ports 80 and 443:

   7.1. Install the telnet utility; for more details, see the Telnet Applications article in the telnet documentation.

   7.2. Check the connection on port 80:

   telnet <destination_ip_address> 80

   Specify <destination_ip_address> — the destination server IP address.

   7.3. Check the connection on port 443:

   telnet <destination_ip_address> 443

   Specify <destination_ip_address> — the destination server IP address.

   7.4. Save the outputs to the diagnostic results file you created in step 2.

8. Perform a traceroute to the destination server:

   8.1. Perform a traceroute.

   8.2. Save the output to the diagnostic results file you created in step 2.

9. Collect a network traffic dump. Name the dump file as dump_<source_ip_address>_<destination_ip_address>, where <source_ip_address> is the source server IP address, and <destination_ip_address> is the destination server IP address.

2. Perform a diagnosis from the destination server to the source

Linux

1. Connect to the target server. If the server is in the Servercore infrastructure, use the Connect to a server guide.

2. Perform a traceroute to the source server:

   2.1. Install the mtr utility; read more on GitHub mtr.

   2.2. Perform a traceroute:

   mtr --address <source_ip_address> -bwzrc 100 <destination_ip_address>

   Specify:

   • <source_ip_address> — the source server IP address; ;
   • <destination_ip_address> — the destination server IP address.

   2.3. Save the output to the diagnostic results file you created in step 1.

3. Collect a traffic dump to the source server:

   3.1. Install the tcpdump utility; for more details, see the documentation on tcpdump.

   3.2. Collect a traffic dump. The command will create a separate data file in .pcap format:

   tcpdump --count 1000 -w dump_<destination_ip_address>_<source_ip_address>.pcap host <source_ip_address>

   Specify:

   • <destination_ip_address> — the destination server IP address; ;
   • <source_ip_address> — the source server IP address.

Windows

1. Connect to the destination server. If the server is located in Servercore infrastructure, use the Connect to a server guide.

2. Run PowerShell as an administrator.

3. Perform a traceroute to the source server:

   3.1. Perform a traceroute to the source server.

   3.2. Save the output to the diagnostic results file you created in step 1.

4. Collect a network traffic dump to the source server. Name the dump file as dump_<destination_ip_address>_<source_ip_address>, where <destination_ip_address> is the destination server IP address, and <source_ip_address> is the source server IP address.

3. Send diagnostic data

1. Create a ticket, and specify the following data in it:

   • describe the problem you encountered in as much detail as possible;

   • specify the pair of IP addresses between which connection issues are observed and for which you performed the diagnosis;

   • if the issue is observed with an HTTP/HTTPS connection, specify whether a VPN server is located at the specified IP addresses;

   • attach the files with the diagnostic results.

2. Wait for a response from a Servercore support engineer. We will perform additional diagnostics on our end and update you on the results.

3. Optional: if our diagnostic results confirm a suspicion of TSPU-related impact, you can additionally request confirmation from transit providers regarding the presence of TSPU on the traffic route. Servercore can send a text request only to those transit providers (uplinks) that connect directly to our data centers. Contacting providers does not guarantee the resolution of traffic issues. You may contact the providers yourself from the side of the server, provided it is located outside the Servercore infrastructure.

   3.1. On the source server, start traffic towards the destination server. Do not stop the traffic for at least 7 days; this is required for diagnostics on the provider's side:

   ping <destination_ip_address>
   while true; do <protocol> -o ConnectTimeout=5 user@<destination_ip_address> exit; sleep 60; done

   Specify:

   • <destination_ip_address> — the destination server IP address;
   • <protocol> — the protocol experiencing issues: ssh for SSH protocol, curl for HTTP/HTTPS protocols.

   3.2. In the ticket, report that you have started the traffic. We will send a written request to the communication service provider that is connected directly to the Servercore infrastructure and through whose channel the started traffic passes.

   3.3. Optional: contact the communication service provider to which the server outside Servercore infrastructure is connected, yourself.

4. Follow the actions based on the diagnostic results

Servercore does not manage traffic filtering settings on the side of transit providers and cannot directly influence the operation of TSPU outside of its infrastructure. If TSPU impact is confirmed by the diagnostic results, you can:

• contact the support team of the transit provider whose network is experiencing the issue and request a check for possible excessive traffic filtering. If necessary, the provider can contact regulatory authorities themselves and submit an application via the technology network owner's personal account. The request does not guarantee the resolution of traffic issues;

• you can also change the IP address on your server in Servercore. Changing the IP address does not guarantee that the traffic issue will be resolved:

  • request a different public shared IP address; to do this, create a ticket;
  • or order a public routed subnet.