TCP RST e analisi PCAP di ripristino della connessione: chi ha chiuso la connessione e perché
Come analizzare TCP RST, reimpostazione della connessione da parte del peer, reimpostazione dopo SYN, reimpostazione durante TLS, reimpostazione del firewall, chiusura dell'applicazione e prove di acquisizione dei pacchetti.
"Connessione reimpostata dal peer" è un errore comune nei client HTTP, nei database, negli strumenti TLS, nei proxy e nelle applicazioni TCP personalizzate. Gli utenti cercano "analisi TCP RST pcap", "reimpostazione della connessione tramite peer Wireshark", "RST dopo SYN", "reimpostazione della connessione TLS" e "reimpostazione TCP del firewall" perché hanno bisogno di sapere chi ha interrotto la connessione e se il ripristino è avvenuto dall'applicazione, dal sistema operativo, dal firewall, dal bilanciatore del carico o dal server.
Un RST TCP è esplicito. Dice "interrompi questa connessione". La parte difficile è l'attribuzione.
PCAP Surgery è utile perché le indagini di ripristino necessitano di una traccia pulita e mirata con direzione, timestamp, numeri di sequenza e pacchetti sufficienti prima del ripristino.
Modelli di ripristino comuni
L'RST può verificarsi:
- Subito dopo SYN.
- Dopo SYN-ACK.
- Dopo ClientHello.
- Dopo la richiesta HTTP.
- Durante il timeout di inattività.
- Dopo dati di protocollo non validi.
- Quando un'applicazione chiude un socket con dati non letti.
- Quando un firewall rifiuta una policy.
- Quando un sistema di bilanciamento del carico non ha un backend integro.
- Quando un processo del server si arresta in modo anomalo o rifiuta lo stato.
Il tempismo ti dice dove guardare.
Chi ha inviato l'RST
Identificare innanzitutto l'IP di origine, la porta di origine, l'IP di destinazione e la porta di destinazione del pacchetto di ripristino. Se l'IP del server invia RST, il lato server o qualcosa che impersona quel lato lo ha terminato. Se l'IP del client invia RST, il lato client lo ha terminato. Se il comportamento TTL, MAC o percorso suggerisce una middlebox, è possibile che venga iniettato il ripristino.
Non fare affidamento solo sulla formulazione della domanda. "Reset by peer" può essere segnalato dalla parte che ha ricevuto l'RST.
Reset dopo SYN
RST dopo SYN spesso significa che la porta è chiusa o che la policy rifiuta la connessione. Se SYN riceve RST immediatamente, l'applicazione non ha mai raggiunto TLS o HTTP.
Cercare:
- SYN -> RST,ACK
- Nessun serverCiao
- Nessun dato dell'applicazione
- Comportamento coerente tra i tentativi
Non si tratta di un errore del certificato o di un errore HTTP; si tratta di un errore di raggiungibilità/stato del servizio TCP.
Reimposta durante TLS
L'RST dopo ClientHello può essere causato da una porta errata, da un TLS non supportato, da una mancata corrispondenza SNI, da criteri middlebox o dal rifiuto del server. Conserva i metadati DNS e ClientHello in modo da poter visualizzare nome host, ALPN, versioni TLS e tempistiche.
Se il ripristino arriva dopo un avviso TLS, l'avviso è più informativo del ripristino. Se non viene visualizzato alcun avviso, il ripristino potrebbe essere di livello inferiore o basato su criteri.
Reset dopo richiesta
RST dopo una richiesta HTTP, una query sul database o un comando di protocollo spesso significa che l'applicazione ha compreso abbastanza da rifiutare o bloccare la richiesta. Può anche significare che un proxy è stato chiuso perché l'upstream non era disponibile.
Correlare:
- Ultimi byte dell'applicazione inviati.
- Risposta o mancanza di risposta del server.
- Tempo di inattività prima del ripristino.
- Registri di backend/bilanciatore del carico.
- Se il ripristino avviene solo per determinate dimensioni di richiesta.
Checklist
Utilizza questo flusso di lavoro:
- Identifica il primo RST nella conversazione.
- Identificare chi lo ha inviato.
- Ispeziona cosa è successo immediatamente prima.
- Controlla se l'handshake TCP è stato completato.
- Controlla se TLS è iniziato o completato.
- Controlla se i dati dell'applicazione sono stati inviati.
- Controllare i tempi di timeout di inattività.
- Confronta gli indizi TTL/MAC/percorso per l'iniezione middlebox.
- Conserva DNS, TCP, TLS e byte dell'applicazione durante il ripristino.
- Utilizza i log del server/bilanciatore del carico per confermare l'attribuzione.
Diagnosi finale
TCP RST è un'interruzione della connessione, ma il motivo dipende dal momento e dal mittente. Un pcap è in grado di distinguere la porta chiusa, il rifiuto del firewall, il rifiuto di TLS, la chiusura dell'applicazione, il timeout di inattività, l'errore del bilanciatore del carico e il ripristino del middlebox.
PCAP Surgery aiuta a preservare la sequenza dei pacchetti che risponde alla domanda più importante: chi ha ripristinato la connessione e cosa è successo subito prima?