Le mie connessioni TCP sono sabotate dal governo del mio paese?

Ho il sospetto che il governo del mio paese stia distruggendo il pacchetto ACK ricevuto sulle connessioni TCP, in qualche modo.

Quando provo a stabilire una connessione TCP a un host esterno su porte diverse da 80, l'handshake TCP non avrà esito positivo. Ho acquisito il file pcap (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) e ho scoperto che il mio computer riceverà l'ACK dopo aver inviato TCP SYN ma invece di rispondere con un ACK SYN invierà un RST.

Ho controllato il pacchetto ACK dall'host esterno, ma sembra del tutto legittimo. Il numero di sequenza e tutte le bandiere di cui sono a conoscenza sono corretti. Qualcuno potrebbe dirmi perché il mio computer (una macchina Linux) invierà il pacchetto RST?

screenshot di pcap

— Mohammad
fonte

Possiamo informarci su quale paese?

— Kev

Non l'ho deliberatamente menzionato. Ma ora che mi chiedi, non riesco a pensare a un motivo per non dirlo. Questo è uno dei miei problemi quotidiani in Iran.

— Mohammad,

La cattura è stata presa dal tuo computer cercando di stabilire la connessione?

— the-wabbit il

Sì. Eseguo tcpdump -w gmail.pcap e quindi telnet gmail.com 443.

— Mohammad,

telnet non funzionerà, devi vedere la mia risposta qui sotto :-)

— The Unix Janitor

Risposte:

Dalla linea cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

Ciò dovrebbe verificare se è possibile connettersi SSL all'host remoto. Forse fai un Wireshark di questo traffico.

Se non hai openssl, puoi farlo apt-get install openssl.

Dobbiamo determinare dove viene generato l'RST. Succede a tutti i siti SSL? Hai una connessione diretta con il tuo gateway NAT? Stai usando un proxy?

L'uso di questo metodo esclude qualsiasi problema con lo stack SSL.

— Il bidello Unix
fonte

Il problema non è SSL. È TCP. La connessione TCP non verrà stabilita in primo luogo, quindi SSL non inizierà nemmeno a inviare la sua intestazione. non è solo il numero di porta 443, ad esempio non riesco nemmeno ad avviare una normale connessione http a un server sulla porta 8000 e il tuo comando openssl si tradurrà in "connessione: timeout della connessione"

— Mohammad

Anche se si dice che il governo iraniano rompa HTTPS di tanto in tanto, dai dati che hai fornito assomiglia semplicemente al SYN rispondente, il pacchetto ACK da 173.194.32.22 arriva al tuo host, ma non arriva mai al tuo stack TCP. Lo stack riprova a inviare SYN dopo un secondo, due secondi, quattro secondi e otto secondi, ma apparentemente non vede mai una risposta.

Il SYN in arrivo, ACK sembra essere filtrato - non hai una iptablesregola per il traffico tcp nella tua catena INPUT che ha un REJECT --reject-with tcp-resetobiettivo per caso?

— the-Wabbit
fonte

No, il mio iptables non ha alcuna regola e in un'altra nota devo dire che posso stabilire una connessione TCP con successo con qualsiasi host all'interno dell'Iran o anche un paio di siti web stranieri (solo kernel.org in realtà!)

— Mohammad

La mia ipotesi è che il governo stia cambiando il secondo pacchetto (SYN / ACK), quindi il pacchetto non è valido e quindi non lo fa mai nello stack TCP.

— Mohammad,

@Mohammad Il pacchetto è valido. Anche se non lo fosse, lo stack non farebbe entrambi: rispondere con un RST e procedere come se non fosse stato ricevuto. Qualcosa lo sta prendendo sulla strada per lo stack. Suggerisco di avviare un'installazione pulita (ad es. Un CD live di Linux) e rieseguire i test

— the-wabbit,

Grazie. Non ho riscontrato alcun problema anche con il pacchetto ACK. Ma il fatto è che questo problema si verifica ogni giorno (da 4 giorni fa) al mattino sul mio posto di lavoro! Ogni corpo (circa 50 persone) ha esattamente lo stesso problema e mi chiedo ancora perché? Non ho lo stesso problema a casa ma sento dai miei amici che Internet ha seri problemi in questi giorni.

— Mohammad,

@Mohammad verifica quindi la presenza di malware. L'esecuzione di un'installazione pulita nota come suggerito sopra è un test semplice e significativo per questo caso.

— the-wabbit il