Perché lo stato TCP TIME-WAIT è presente ad entrambe le estremità dopo una terminazione della connessione?

Sto leggendo come funzionano gli stati TCP e in particolare la parte di terminazione della connessione.

Tutti i libri o il materiale online che ho letto mostrano che per la procedura di terminazione questi stati sono seguiti dal lato avviato (attivo) la terminazione della connessione:

STABILITO, FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT, CHIUSO

E questi dal lato ricevente (passivo):

STABILITO, CHIUSO-ATTENDERE, ULTIMO ACK, CHIUSO

Ora ecco la domanda: ho modprobed il modulo nf_conntrack_ipv4 su entrambi i lati per controllare gli stati di connessione in / proc / net / ip_conntrack.

Con mia sorpresa, quando la connessione viene terminata, sia l'iniziatore (attivo) che il ricevitore (passivo) passano allo stato TIME-WAIT.

Mi aspetterei che solo l'iniziatore attraversi questo stato e il ricevitore chiuda semplicemente la connessione.

Qualcuno può spiegare perché questo sta accadendo?

AGGIORNAMENTO: Come posso eseguire questo test

Ho una macchina virtuale con IP 10.0.0.1 (Ubuntu 12.04) e inizio due connessioni ssh a 10.0.0.2 (Debian 6) da esso (10.0.0.2 è anche una macchina virtuale). Controllo l'ip_conntrack di entrambe le estremità e questo è quello che ottengo.

root@machine1:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 431997 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 [ASSURED] mark=0 use=2
tcp      6 431944 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 [ASSURED] mark=0 use=2

root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 432000 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 packets=206 bytes=19191 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 packets=130 bytes=18177 [ASSURED] mark=0 secmark=0 use=2
tcp      6 431947 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 packets=16 bytes=4031 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 packets=17 bytes=3741 [ASSURED] mark=0 secmark=0 use=2

Finora tutto sembra a posto. Ora disconnetto una delle connessioni ssh da machine2 e questo è quello che ottengo:

root@machine1:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 431989 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 [ASSURED] mark=0 use=2
tcp      6 117 TIME_WAIT src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 [ASSURED] mark=0 use=2

root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 432000 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 packets=211 bytes=19547 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 packets=133 bytes=18925 [ASSURED] mark=0 secmark=0 use=2
tcp      6 115 TIME_WAIT src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 packets=31 bytes=5147 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 packets=25 bytes=4589 [ASSURED] mark=0 secmark=0 use=2

Lo stack e conntrack TCP di Linux hanno due diverse visioni della connessione TCP. Quello che vedi /proc/net/ip_conntrackè diverso da quello che vede il kernel. Lo stato del kernel è memorizzato in /proc/net/tcpe /proc/net/tcp6e può essere visualizzato con netstat.

Come visto qui: https://serverfault.com/questions/313061/netstat-and-ip-conntrack-connection-count-differ-by-order-of-magnitude-perché entrambi i conteggi differiscono. Presumo che se guardi netstatl'output vedrai solo un'estremità inTIME-WAIT

Questo per impedire a una nuova connessione di fare in modo che i segmenti non aggiornati continuino a fluttuare nella rete dalla vecchia connessione.