Sessioni TCP e modifiche IP

Che cosa succede a una session TCP quando l'IP di un client cambia?

Ho fatto un semplice test di avere netcat ascoltato su una port e collegandomi a quella port da una macchina client. Ho quindi cambiato l'IP del client mentre la session nc è stata aperta e ha inviato alcuni dati, nessun dato è stato ricevuto dal server dopo la modifica dell'IP.

  1. So che sono strati diversi, ma TCP utilizza IP per una parte di come distingue le sessioni?
  2. Il mio esempio non funziona a causa dell'impiego dell'applicazione o non funziona a causa di qualcosa che accade a livello TCP / IP / Ethernet?
  3. Questo dipende dall'implementazione del sistema operativo? (Sono attualmente più interessato a Linux)

  • Come faccio a scoprire il mio indirizzo IP in una casella di tipo unix?
  • Perché la voce localhost manca nel file hosts?
  • Che cosa sono malinteso sul calcolo della MTU?
  • le connessioni aperte di tcp / ip sono circa 2,1 milioni!
  • Come è l'MTU di 65535 in UDP ma ethernet non consente la dimensione del frame più di 1500 byte
  • Come vengono assegnati gli indirizzi IP in realtà?
  • Stack TCP / IP in Windows Server 2008 vs Windows 7 Ultimate
  • Quando aliasing IP come determina l'indirizzo IP che verrà utilizzato come origine per le connessioni TCP / IP in output?
  • 6 Solutions collect form web for “Sessioni TCP e modifiche IP”

    La mia comprensione è che una presa TCP è costituita dal numero di port IP +, quindi cambiando il IP interrompe quella connessione. nc non ha modo di sapere che l'IP è cambiato, quindi continua a submit i dati all'IP originale finché la session non viene interrotta.

    Vedere RFC 793 (Transmission Control Protocol), specificamente sezione 2.7:

    2.7. Stabilimento e compensazione di connessione

    Per identificare i flussi di dati separati che un TCP può gestire, TCP fornisce un identificatore di port. Poiché gli identificatori di port sono selezionati indipendentemente da ciascun TCP, potrebbero non essere univoco. Per fornire indirizzi univoco all'interno di each TCP, concatenaamo un indirizzo internet che identifica il TCP con un identificatore di port per creare una socket che sarà univoco in tutte le reti collegate insieme.

    Suggerisco di utilizzare Wireshark o un altro sniffer di pacchetti per guardare il traffico per te e vederlo in azione.

    La session morirà. Le prese TCP sono dst port, dst ip, port src, src ip. Se uno di questi cambiamenti, la connessione dovrebbe essere abbandonata (alless secondo Stevens).

    EDIT: questo vale per qualsiasi implementazione compatibile con RFC. RFC 793, sezione 2.7

    Le risposte precedenti vi diranno che le connessioni TCP non possono essere mantenute vive quando l'indirizzo IP cambia. Questo è stato corretto nel 2009, quando quelle risposte furono scritte.

    Tuttavia nel gennaio 2013 è stata pubblicata la RFC 6824 , che introduce un modo per mantenere viva le connessioni TCP quando l'indirizzo IP cambia. A partire da giugno 2014, non è ancora ampiamente supportto. Soprattutto l'implementazione di riferimento esiste come una patch per Linux e iOS7 support per impostazione predefinita MPTCP. Wikipedia elenca un totale di cinque implementazioni .

    Le sessioni TCP vengono identificate dall'indirizzo IP e dal numero di port su entrambi i lati della connessione. Cambiare l'indirizzo IP da un lato interromperà quella session.

    La combinazione (indirizzo di origine, port di origine, indirizzo di destinazione, port di destinazione) viene definita una coppia di socket . Viene utilizzato dalla stack TCP per identificare la connessione. Una volta stabilito, TCP non ha modo di aggiornare nessuno di questi.

    SCTP consente agli endpoint di cambiare gli indirizzi in volo, ma non è ampiamente implementato (non ancora, comunque).

    Altri hanno risposto dal punto di vista della connessione identificata dalla coppia IP + Port. Permettethemes di parlare un po 'di come funziona nella struttura a strati.

    TCP è uno strato che fornisce l''illusione' di un stream affidabile su un livello di pacchetti non affidabile (IP). Per questo, deve tenere conto di diverse variables per gestire il stream, e deve inoltre fornire i relativi parametri al livello sottostante.

    Quindi, quando si chiede ad un TCP di aprire un stream, gli assegni la port IP + della destinazione. Mantiene quel numero IP e each volta che deve trasferire qualcosa, assembla un pacchetto IP e indica il livello IP per inviarlo alla macchina destinata, identificata solo dal numero IP originale.

    Quando hai cambiato il numero IP di una macchina, lo strato TCP di un altro non ha alcuna intenzione di sapere cosa è successo. Rivede solo che nessun pacchetto IP inviato al numero IP originale non risponde più (forse riceve un messaggio ICMP che dice che non esiste alcuna macchina con quel numero IP). Inoltre, non ottiene più pacchetti con quel numero IP. Ovviamente la connessione verrà eliminata dopo un certo timeout.

    Peggio ancora, potrebbe iniziare a get alcuni pacchetti non correlati da un'origine diversa (il nuovo numero IP), ma quelli che una connessione è già in atto! Naturalmente, l'unica risposta che la macchina potrebbe get (se a tutti) è un pacchetto RST per farlo immediatamente cessare e desistere.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.