|
|
|
![]() |
|
Strumenti |
![]() |
#21 | |
Senior Member
Iscritto dal: Oct 1999
Messaggi: 3780
|
Quote:
qui http://lists.debian.org/debian-firew.../msg00006.html mi sembra di aver capito di si. |
|
![]() |
![]() |
![]() |
#22 | |
Senior Member
Iscritto dal: Jan 2001
Città: Milano
Messaggi: 5707
|
Quote:
uhm resto comunque perplesso. anche se funzionasse dovrebbe tenere traccia delle sessioni ssl e secondo me non lo fa. se fai la prova facci sapere. |
|
![]() |
![]() |
![]() |
#23 | |
Senior Member
Iscritto dal: Oct 1999
Messaggi: 3780
|
Quote:
![]() ![]() ![]() ![]() ![]() io pensavo di ragionare ad un livello piu' basso ... connetto sempre lo stesso client allo stesso server ... poi saranno il client ed il server a smazzarsi tutta la sbobba dell' SSL. in pratica e' come se ci fosse un omino che quando vede arrivare il pacchetto TCP/IP attacca il cavo di rete ad un server piuttosto che all' altro. P.S. e' ovvio che se uno dei due server va giu' TUTTI quelli che stavano su quel server devono rilogarsi sul superstite. |
|
![]() |
![]() |
![]() |
#24 | |
Senior Member
Iscritto dal: Jan 2001
Città: Milano
Messaggi: 5707
|
Quote:
ok e' questo che volevo dire. in particoalre: 1) tutti quelli che hanno una sessione SSL con il primo server quando va giu' devono rinegoziarla col secondo. Questo potrebbe essere trasparente all'utente a meno che ci siano applicativi che fanno uso della sessione SSL (difficile) 2) se oltre che un http c'e' un application serve per un sito dinamico (tomcat, applicazione asp) gli utenti loggati si devono riloggare, a meno che l'application preveda qualche meccanismo di clustering. |
|
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 22:19.