TSPU Checker: How I Built a Tool for Diagnosing Blockages

The idea for this project came after attempts to figure out why VPN works fine with some providers, while on others the connection either gets cut off or simply hangs without any errors. Standard ping checks showed almost nothing: ICMP traffic passed through, but TCP connections could already drop out.

At some point it became clear that a simple tool was needed that could be quickly launched on a server, in WSL, or even in Termux, and let you figure out in a couple of minutes where exactly the problem lies: DNS, TCP, TLS, or even HTTP.

This is how TSPU Checker came to be — a bash script for diagnosing blocks and analyzing the operation of TSPU in Russian networks. The script can check port availability, detect signs of SNI filtering, compare DNS responses, and look for typical DPI symptoms.

The code is hosted on GitHub under the MIT license, so anyone can freely adapt it to their own needs.

Why we had to write our own tool in the first place

Starting around 2025, Russian operators have increasingly shown signs of operating on an allowlist model — where access is only permitted to specific IP addresses, and all other traffic is either dropped or starts behaving erratically.

In practice this looked strange — I connect to VPN, but no traffic goes through, ping to the server works, but TCP does not. Meanwhile DNS responds normally, but TLS connections suddenly hang. Some cloud servers started dropping out partially. Sometimes it was unclear exactly where the connection was breaking.

I read about several existing solutions like OONI Probe and rkn-block-checker, but for everyday diagnostics they seemed either too heavy or not very convenient. I wanted something as simple as possible: run the script and in 30 seconds understand exactly what the provider is cutting off. That's how TSPU Checker came to be.

Architecture and approach

The script is written in bash. At first I thought about doing everything in Python, but then it became clear that I don't know it at all:). It doesn't require many resources in the console, so it can be run even on a minimal VPS server. Turns out that standard tools are more than enough for network diagnostics.

And then the weekend came, I had a free minute, so I started testing a script. I have Linux installed on my home computer, and I also have a VPS server, so I started my tests on those. Then I thought it would be nice to write a mini script to run it on my phone in Termux.

To make the script easy to run on most Linux machines, I decided to use standard utilities like ping, nc, curl, openssl, dig, hping3, nmap. The entire idea of the script is to sequentially check several network layers and figure out where the problem starts.

For example:

a. ICMP helps to figure out if the server is alive at all;

b. TCP shows if the connection is being cut off;

c. TLS lets you see signs of SNI filtering;

d. HTTP helps detect blocks;

e. Comparing DNS and DoH shows possible response substitution.

I don't know if my script is capable enough

========================================
     TSPU Diagnostic Tool    
              v1.0                      
========================================

 Current target server: 192.168.1.1

Select an action:

  0)   Change server IP (current: 192.168.1.1)
  1)   Determine TSPU mode
  2)   Check TSPU activity (curl)
  3)   Check port availability (TCP)
  4)   Check SNI filtering (L7)
  5)   Check UDP ports
  6)   Check external DNS
  7)   Launch web server on 443
  8)   Full server check
  9)   Detailed port analysis
  10)  Determine your IP
  11)  Advanced block diagnostics
  12)  Check Split DNS/leak
  q)  Exit

Your choice: 

I wanted to make the menu as simple as possible so that the tool can be used even without documentation. I think one of the most useful modes is the advanced block check.

The script works in stages:

• Checks DNS;

• Tries to establish a TCP connection;

• Performs a TLS handshake;

• Checks the HTTP response.

I think this approach helps to localize the problem quite quickly. For example, when DNS responds normally, but TCP doesn't connect, or TCP works but TLS hangs. And sometimes TLS goes through fine, but HTTP returns a block.

Example:

=======================================
     TSPU Diagnostic Tool    
              v1.0                      
========================================

 Current target server: 192.168.1.1

[11] Advanced Block Diagnostics (4 layers)

--- Whitelist (control group) ---

Check: Yandex (ya.ru)
  System DNS: OK → 5.255.255.242
  DoH DNS (1.1.1.1): OK → 77.88.44.242
  TCP port 443: OPEN

--- Blacklist (blocked resources) ---

Check: Twitter (twitter.com)
  System DNS: OK → 172.66.0.227
  DoH DNS (1.1.1.1): OK → 162.159.140.229
  TCP port 443: OPEN
  TLS Handshake: SUCCESSFUL

Press Enter to continue...

If you carefully study the received information, it becomes clear where exactly DPI starts to interfere.

During testing, I noticed several strange cases where a TLS connection only worked with a specific SNI. That's when I thought of this check. I thought that a script could establish TLS connections with different domains and show the results.

Example:

========================================
     TSPU Diagnostic Tool    
              v4.2                      
========================================

 Current target server: 192.168.1.1

[4] L7 SNI Filtering Check...

 Test IP (Yandex): 77.88.55.242

  SNI: ya.ru (Yandex): PASSED ✓
  SNI: google.com (Google): PASSED ✓
  SNI: twitter.com (Twitter): NO RESPONSE
  SNI: youtube.com (YouTube): PASSED ✓
  SNI: vk.com (VK): PASSED ✓

Press Enter to continue...

After the tests, it became clear that on some networks this allows you to quite quickly figure out whether TLS is filtered by hostname.

To test VPN, it was necessary to check what IP different services see and whether the real address leaks outside the tunnel.

========================================
     TSPU Diagnostic Tool    
              v1.0                      
========================================

Current target server: 192.168.1.1

[12]  Check Split DNS/WebRTC Leak

 WARNING: Run this test WITH VPN ENABLED

Press Enter if VPN is enabled, or 'q' to exit: 

[Check what IP websites see]:

  ya.ru sees IP: 77.88.44.242
  ifconfig.me sees IP: 144.31.198.40

 Analysis:
   Split DNS/tunneling IS WORKING

Press Enter to continue...

At first I wanted to add a full WebRTC check, but for bash it turned out to be too inconvenient.

What worked out in practice

VPS test inside the Russian Federation

For testing I used a regular VPS. The results were approximately as follows:

In my case the server responded normally and there were no signs of blocking.

Check via mobile carrier

But the mobile network showed much more interesting behavior. The following picture was observed:

That is, ping was still passing through, but a normal TCP connection could no longer be established.

DNS was also interesting: some external resolvers simply stopped responding.

Installation and Launch

On Linux / WSL

# Installing dependencies
sudo apt update
sudo apt install -y hping3 nmap netcat-openbsd openssl dnsutils curl

# Downloading the script
wget -O tspu_check.sh https://raw.githubusercontent.com/ku78/tspu-checker/refs/heads/main/tspu_check.sh

# Running
chmod +x tspu_checker.sh
sudo ./tspu_checker.sh

On Android (Termux)

pkg update && pkg install -y openssl-tool netcat-openbsd curl tsu nano
# Next — copy the script to a file and run

On Windows (PowerShell)

Full functionality is only available through WSL. A simplified version on PowerShell is available in the repository.

Development plans

• Add ECH (Encrypted Client Hello) check

• Implement speed benchmarks for different protocols

Links and acknowledgments

• GitHub link

• Inspiration: article by zarazaexe «Everything you need to know about white lists: how they work and 6 ways to bypass them»

• Diagnostic ideas: project rkn-block-checker by MayersScott

TSPU Checker was initially created as a small auxiliary script "for myself" to avoid manually figuring out why another VPN suddenly stopped working.

As a result, a fairly convenient tool was created that helps to quickly understand:

• whether DNS is broken

• whether TCP is blocked

• whether there are signs of SNI filtering

• whether responses are tampered with

• whether tunneling works

It is clear that this is not a full-fledged DPI analysis system, but the script is usually sufficient for quick diagnostics.

PS: this is my first article, I'm waiting for maximum hate.