View Full Version : Floppy Firewall Info
Devo farmi un firewall/router e per risparmiare pensavo di utilizzare un vecchio PC ed una minidistro linux su floppy.
Il problema e' che non conosco per nulla Linux quindi non sono in grado di scegliere
dopo aver cercato in internet sono piu' indeciso di prima ...
quello che mi ispira di piu' e' questo
http://www.coyotelinux.com/products.php?Product=coyote
ma mi sembra troppo complicato e con troppe opzioni che non mi servono a nulla.
In pratica a me serve un floppy che non faccia null' altro che bootare il PC e caricare le (PIU O MENO) regole
iptables -A FORWARD -d eth0 -p tcp -m tcp --dport 80 -j allowed
iptables -A FORWARD -s eth0 -p tcp -m tcp --sport 80 -j allowed
iptables-A FORWARD -d eth0 -p tcp -m tcp --dport 443 -j allowed
iptables -A FORWARD -s eth0 -p tcp -m tcp --sport 443 -j allowed
cioe' che permetta solo il passaggio dei pacchetti sulla 80 e sulla 443 dalla ETH0 (internet) alla ETH1 (LAN)
penso che la scelta migliore (se vuoi qualcosa esclusivemente su floppy) l'hai già indicata.
le alternative possobili sono tutte su cd e molto piu' complicate
Con coyote linux e' possibile fare un bilanciamento di carico semplice?
Ad esempio far finire gli IP pari su una macchina , quelli dispari sull' altra (mi serve che lo stesso utente sia sempre sulla stessa macchina)
e solo nel caso che una macchina non risponda al ping girare il tutto sulla supersite.
Originariamente inviato da Athlon
Con coyote linux e' possibile fare un bilanciamento di carico semplice?
Ad esempio far finire gli IP pari su una macchina , quelli dispari sull' altra (mi serve che lo stesso utente sia sempre sulla stessa macchina)
e solo nel caso che una macchina non risponda al ping girare il tutto sulla supersite.
sei partito dalla cosa piu' semplice del mondo e adesso parli di bilanciamento di carico :muro:
forse e' meglio se recuperi un hd anche piccolo piccolo e ci metti una distro normale, hai molta piu' flessibilità.
con coyote probabilemente non si puo' fare (il kernel dovebbe essere compilato col supporto per un sacco di roba), ma non ne sono sicuro quando ho tempo ci guardo ;)
Originariamente inviato da kingv
sei partito dalla cosa piu' semplice del mondo e adesso parli di bilanciamento di carico :muro:
e' che prima dietro c'era solo un server ... ora ce ne sono
2
Originariamente inviato da kingv
forse e' meglio se recuperi un hd anche piccolo piccolo e ci metti una distro normale, hai molta piu' flessibilità.
Quello che non mi piace del hdd e' che si puo' rompere , e se si rompe e' un casino ripristinarlo , col floppy invece ne fai tante copie all' inizio e se ci sono problemi semplicemente cambi dischetto e riavvi
Originariamente inviato da kingv
con coyote probabilemente non si puo' fare (il kernel dovebbe essere compilato col supporto per un sacco di roba), ma non ne sono sicuro quando ho tempo ci guardo ;)
in teoria basterebbe crond e iptables
parti da una situazione dove gli IP pari finiscono su un server e quelli dispari su un altro (ogni user DEVE finire sempre sullo stesso server)
con crond fai uno scriptr che ad intervalli prestabiliti fa un GET HTTP page verso un server se la risposta e' uguale a quella che ci si aspetta vuol dire che il server e' a posto , altrimenti si carica una nuova iptables che gira tutto il traffico verso l'altro.
Originariamente inviato da Athlon
con crond fai uno scriptr che ad intervalli prestabiliti fa un GET HTTP page verso un server se la risposta e' uguale a quella che ci si aspetta vuol dire che il server e' a posto , altrimenti si carica una nuova iptables che gira tutto il traffico verso l'altro.
crond ha una risoluzione di un minuto, penso che il dispatcher dovrebbe "pingare" il servizio un po' piu' frequentemente.
se il servizio come mi sembra di aver capito e' http puoi usare diverse soluzioni, come ad esempio un reverse proxy davanti ai due web
una soluzione generale potrebbe essere questa, ma ho dato un occhio alla documentazione e non si mette in piedi in 5 minuti,
http://www.linux-vs.org/
il servizio e' HTTP ed HTTPS (per quello che lo stesso user deve finire sulla stessa macchina)
una risoluzione di un minuto va piu' che bene , crond serve a RILANCIARE lo script se per caso cade , e' lo script stesso che si occupa di "pingare in http" i server a cadense predefinite.
Anche se in effetti usare crond per il ping renderebbe molto piu' semplice lo script.
basterebbe farne 2
Ping web1 e
Ping web2
e lanciarli alternativamente ... nel peggiore dei casi si ha meta' utenti che restano fermi per neppure 2 minuti
Originariamente inviato da kingv
una soluzione generale potrebbe essere questa, ma ho dato un occhio alla documentazione e non si mette in piedi in 5 minuti,
http://www.linux-vs.org/
:eek: :eek: :eek: :eek: :eek: decisamente troppo ... come usare una portaerei per fare una gita in pedalo'.
Considera che il load balancing serve piu' per una questione politica di "fare figo" che non per un' effettiva necessita'
Originariamente inviato da Athlon
:eek: :eek: :eek: :eek: :eek: decisamente troppo ... come usare una portaerei per fare una gita in pedalo'.
Considera che il load balancing serve piu' per una questione politica di "fare figo" che non per un' effettiva necessita'
:D infatti mi sembrava un po' troppo.
ho guardato mod_proxy su apache e non sembra che abbia la possibilità di associare piu' di un server di backend a ogni url.
il balancing per dividere le richieste potresti farlo anche molto semplicemente via DNS , solo che non otteresti l'alta affidabilità girando le richieste sul server rimasto in piedi.
Originariamente inviato da kingv
il balancing per dividere le richieste potresti farlo anche molto semplicemente via DNS , solo che non otteresti l'alta affidabilità girando le richieste sul server rimasto in piedi.
:confused: :confused: :confused: :confused:
ma alta affidabilita' non e' proprio il garantire che se una machina muore il servizio continua perche' c'e' l'altra?
Originariamente inviato da Athlon
:confused: :confused: :confused: :confused:
ma alta affidabilita' non e' proprio il garantire che se una machina muore il servizio continua perche' c'e' l'altra?
infatti, io ho detto che utilizzando una soluzione semplice come due entry sul DNS per lo stesso alias otterresti solo di smistare le richieste (ottimizzando le prestazioni) ma non di avere il servizio in alta affidabilità perche' metà degli utenti si troverebbero il server giu' in caso di failure ;)
Zeno Cosini
09-06-2004, 10:05
Originariamente inviato da Athlon
Quello che non mi piace del hdd e' che si puo' rompere , e se si rompe e' un casino ripristinarlo
Guarda basta farne un backup con, ad esempio, Drive Image, e visto che l'HD in questione sarebbe piccolo ti occupa anche poco spazio...
Inoltre il programma consente anche di backuppare all'interno della rete, così non devi i salti mortali per inserire eventualmente fisicamente l'HD nel PC... :oink:
per la soluzione con iptables e lo script invece avresti il problema contrario, le richieste andrebbero o tutte su una macchina o tutte sull'altra, no?
Originariamente inviato da kingv
infatti, io ho detto che utilizzando una soluzione semplice come due entry sul DNS per lo stesso alias otterresti solo di smistare le richieste (ottimizzando le prestazioni) ma non di avere il servizio in alta affidabilità perche' metà degli utenti si troverebbero il server giu' in caso di failure ;)
sarebbe solo un down temporaneo , giusto il tempo di riloggarsi (l'HTTPS se il server fisico cambia ti obbliga a reiniziare la sessione) e tutti gli utenti sarebbero sulla macchina superstite.
Originariamente inviato da Zeno Cosini
Guarda basta farne un backup con, ad esempio, Drive Image, e visto che l'HD in questione sarebbe piccolo ti occupa anche poco spazio...
Inoltre il programma consente anche di backuppare all'interno della rete, così non devi i salti mortali per inserire eventualmente fisicamente l'HD nel PC... :oink:
tramite rete sicuramente NO ... si tratta di un FIREWALL.
l'hdd ha il grosso svantaggio che devi aprire la macchina per ripristinarlo e ci mette del tempo , con il floppy invece basta tenere una scatoletta di floppy gia' fatti , in caso di problemi butti via il floppy corrente , ne pigli uno nuovo e riavvi la macchina ... in meno di 30 secondi anche un UTONTO e' in grado di aggiustare tutto.
Originariamente inviato da kingv
per la soluzione con iptables e lo script invece avresti il problema contrario, le richieste andrebbero o tutte su una macchina o tutte sull'altra, no?
no , con IPTABLES di norma farei andare le richieste meta' da una parte e meta' dall' altra , solo in caso di guasti si dirotta tutti da una parte o dall' altra.
Originariamente inviato da Athlon
no , con IPTABLES di norma farei andare le richieste meta' da una parte e meta' dall' altra , solo in caso di guasti si dirotta tutti da una parte o dall' altra.
si puo' fare con iptables? :confused:
io non sono un esperto di iptables ma a sensazione dubito che implementi session affinity (per l'ssl o per eventualli applicazioni web) e tutto quanto necessario al load balancing.
Sul LUG di Asti c'è un firewall su floppy ed una miniguida (http://lugasti.it/Members/dodo)
ho trovato anche questo
http://www.gnu.org/directory/Security/firewall/floppyfw.html
Originariamente inviato da kingv
si puo' fare con iptables? :confused:
io non sono un esperto di iptables ma a sensazione dubito che implementi session affinity (per l'ssl o per eventualli applicazioni web) e tutto quanto necessario al load balancing.
qui
http://lists.debian.org/debian-firewall/2004/04/msg00006.html
mi sembra di aver capito di si.
Originariamente inviato da Athlon
qui
http://lists.debian.org/debian-firewall/2004/04/msg00006.html
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.
Originariamente inviato da kingv
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.
:confused: :confused: :confused: :confused: :confused:
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.
Originariamente inviato da Athlon
P.S. e' ovvio che se uno dei due server va giu' TUTTI quelli che stavano su quel server devono rilogarsi sul superstite.
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.
il sito e' praticamente tutto in SSL ed e' quasi completamente dinamico
Comunque il fatto che gli utenti si debbano riloggare e' accettabile
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.