MAAT's URL-classification/rule-matching RESTful service (url_label_restiful, maat_table_info.conf, Maat_rule.h) is built on the shared MESA 'stream' C headers -- including stream_inject.h, stream_control.h, stream_proxy.h, and stream_rawpkt.h -- confirming packet injection, proxying, and raw-packet control are core primitives of the same low-level framework MAAT's rule engine sits on.

An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.

The same T1/NTC node config (ntcconf/t1conf/main.conf, K18/Astana/Kazakhtelecom) exposes concrete DPI enforcement toggles: a SYNACK_OR_RST switch and SEND_INJECT_PKT flag governing active TCP-response/packet-injection behavior; ASN- and IP-based blocklists (ASN_MAAT, IPD_DYN_MAAT, IPD_STATIC_MAAT) refreshed from MAAT/Redis on a 1-second effect interval; a dynamic blacklist with a 180s timeout; explicit protocol-blocking switches for BitTorrent (DHT/uTP) and eMule (Kad); and TLS metadata harvesting including certificate SAN fields (NTC_SSL_COLLECT, collect_san_sw=1) streamed to a Kafka topic.

The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.

Primary-source MESA Lab wiki documentation confirms SAPP ("Stream Analyse Process Platform") is a plugin-based traffic-inspection engine achieving 10-40Gbps per hardware unit, deployable either inline (串联) or as a passive mirror tap (并联), and exposes core platform APIs available to any business-layer plugin for forging a TCP RST (MESA_kill_tcp), spoofing a fake SYN/ACK to block connection establishment (MESA_kill_tcp_synack), and injecting arbitrary application-layer data into an established flow (MESA_inject_pkt).

"stellar" (git.mesalab.cn / geedgenetworks.com) is a C++ core DPI packet-processing engine with protocol decoders (HTTP, FTP, mail, QUIC, RTP, SIP, DTLS, SSL, DNS, SOCKS, stratum) and a dedicated packet-injection module (src/stellar/inject.cpp) with an extensive TCP-RST-injection test suite covering injection timed after SYN, SYN-ACK, first C2S payload, and sub-ACK. It integrates the MAAT rule engine (security_enforcer.cpp / scanner_maat.c, "Security enforcer maat plugin table"), the Marsio packet-I/O framework (marsio_io.cpp), and glimpse_detector as an integrated decoder plugin ("integration glimpse_detector", "rename to lpi plugin").

The tango/tsg-service-chaining-engine (SCE) repo implements TSG's traffic-steering core: it VXLAN-encapsulates and routes both "raw" and "decrypted" copies of a session (four tracked metadata directions) through a chain of up to 32 third-party "Service Functions", with explicit per-flow actions of block, bypass, forward, and rx_drop for both mirrored and inline-steered traffic, coordinating with SAPP, mrzcpd (packet capture/re-injection), and MAAT4 (rule engine) via control-plane messages.