Diciamo che quando la tabella di NAT è satura, a prescindere da tutto, non è una bella cosa. E penso che su questo siamo d'accordo. Il router o firewall di turno inoltre lo segnala come warning. Collegandosi sull'interfaccia web ci mostra anche il warning con una timeline indicande il livello di criticità. Ovviamente quando accade l'esplosione di sessioni di cui ti dicevo... Rosso a fondoscala !!
Detto questo... mi complimento con te per la tua preparazione in merito. Si vede che ho avuto naso (o culo), ma mi sembri non voglio dire esperto.. magari nemeno un appassionato... ma quanto meno un amante del'argomento.
Quello che dici riguardo un giusto rapporto tra architettura, potenza di calcolo e ram (quindi sessioni) è giustissimo. Daltronde un appliance in fase progettuale è un po un compromesso di tutto in virtù del segmento che andrà a coprire.
Ti do ragione anche sul fatto che non si dovrebbe incriccare nel momento in cui si satura la nat table, ma mi permetto di fare un'osservazione: se un client P2P genera in un preciso momento un numero insostenibile di sessioni, andrà a saturare immediatamente la nat table. Una volta satura il povero PC di turno che magari tentava di visitare una pagina web non putrà instaurare nuove sessioni, fino a che non scaddrà qualcuna delle precedenti. Anche se il client P2P di turno si sta ancora SFOGADO generando sessioni a josa, magari un buco vuoto che sia uno per allocare una sessione ci scappa.
Ora entra in gioco il discorso del timeoute delle sessioni che di default mi pare sia impostato a 5min su questo appliance (non vorrei dire una cazzata, mi riservo il diritto di controllare). Ovviamente è customizzabile (ci mancherebbe) e avevo già pensato di abbassarlo, ma sarebbe niente più che un operazione di tuning. Non la soluzione suprema.
Cmq.. diciamo che per come stanno le cose, in caso di nat table satura, hai quanto meno la navigazione bloccata per un lasso di tempo X. Ora amministrando io questi apparati da remoto... cosa posso dire una volta che sono irragiungibili? Non posso sapere se si sono incriccati o meno.
Condivido comunque la tua opinione. Tanto che all'inizio.. al verificarsi dei primi blocchi... ho pensato come prima cosa al modem. Uno di quelli forniti in comodato d'uso da telecom/alice/Tin.it. IE' un glorioso e vecchio Ericcson HM220DP sul quale faccio autenticazione PPOE col netscreen. E' Quello dato in comodato d'uso da telecom/alice/Tin.it. Come modem scalda parecchio anche se... per mesi e mesi non ho mai avuto problemi. Come è pur vero che non avevo mai usato torrent. Cmq.. decido di aprirlo in modo tale che sia più fresco e per vedere anche quali sono i componenti che scaldavano maggiormente. Nella foto si intravedono anche il netscreen e il Sonicwall.
Fatto sta che dopo un po (anche aperto) con bittorrent in moto, linea congelata. Ovvero: il modem dalle spie risulta connesso e la portante c'è. Ma non riesco a fare nemmeno un ping. Il mio firewall è raggiungibile (ovviamente da rete locale, non da internet) e risponde ai comandi. Vedo che per lui il modem risulta connesso, conserva ancora l'ip pubblico eppure non riesco a fare nemmeno un ping.
Ora come fare a dire con certezza se l'apparato responsabile del blocco è il modem o il firewall? Sia che resetto l'uno o l'altro, non faccio altro che buttare giù l'adsl e farlo risalire. Solitamente cmq scollego il modem e lo ricollego e tutto torna a funzionare.
I componenti del modem sono molto caldi. Non so quali siano i limiti di tolleranza e non so di preciso quale sia la temperatura alla quale arriva.
Mi piacerebbe fare la prova con un altro modem, ma purtroppo non ne ho (potrei solo farmi prestare un secondo ericcson identico al mio). Ero quasi disposto a comprarne uno, magari usato senza spendere tantissimo, ma guardandomi intorno sento pareri sfavorevoli verso la quasi totalità dei modem.