A portion of Moneta clients recently lost connectivity to company servers due to filtering on the TSPU segment of the network. Initial checks of firewalls and bidirectional traces ruled out internal causes, while client sites and Pay URL payment notifications also became unreachable.
Eugene, a DevOps engineer at Moneta, documented the full diagnostic path using curl, traceroute, nping, and a custom Python script for post-handshake tracing. Basic tests showed timeouts on TLS Client Hello packets, with responses stopping after operator routers and BRAS equipment.
When payload-specific filtering was suspected, hexadecimal TCP data was extracted from Wireshark and replayed via nping and netcat to reproduce retransmissions. A dedicated script allowed TTL-controlled probes after completing the TCP handshake to isolate the exact hop where drops occurred.
Verification from multiple Russian nodes via globalping helped exclude routing faults. Once TSPU involvement was confirmed, a request was filed through the VTS personal account using organization credentials from Gosuslugi, specifying source and destination ranges, ports, protocol, and traffic justification.
After the request received “Partially Accepted” status without restoration, escalation to DCOA via support_asbi@dcoa.ru or support_asbi@noc.gov.ru was required. Obtaining the four-digit TSPU site identifier (e.g., 4XXX) proved difficult until direct contact with SSOP at supervising@noc.gov.ru succeeded.
The final diagnostic package sent to DCOA included DNS results, ICMP and TCP traces, curl output, and confirmation of ongoing traffic from the source IP. The article stresses that active traffic must be present during DCOA analysis and that the process applies only to legitimate information resources of legal entities.
