Newsgroup: it.comp.os.linux.sys
Titolo: Strano problaema con FTP dietro ipvsadm

Ciao a tutti,
    a causa di una rottura del firewall zyxel ho dovuto mettere al 
lavoro una macchinetta linux con centos, nella quale tramite ipvsadm 
(ldirectord) ho tirato su un paio di servizi che dai server windows 
interni offro all'esterno.
Tutto parrebbe funzionare, tranne l'FTP.
O meglio, e qui ï¿œ la stranezza, se da una macchina linux esterna 
(l'unica che posseggo) cerco di collegarmi, non ho alcun tipo di 
problema: mi collego, scarico, carico etc etc.
Se chiuqne altro prova, con client tipo cuteFTP, rimane appeso, dopo la 
password.
L'iptables non sta bloccando, ho messo in redirezione sia la 21 che la 
20, ma ne in ACTIVE ne in PASSIVE mode, queste persone riescono a 
collegarsi.
Non so dove sbattere la testa, a qualcuno di voi ï¿œ mai capitato qualcosa 
del genere?
grazie e  ciao

 del genere?
Mi capitò una cosa simile, solo che era con un Cisco ASA al posto di
CentOS. Tutti i linux potevano collegarsi tranquillamente, mentre
tutti i Windows no. Alla fine è venuto fuori che era una cosa legata
all'ispezione dei protocolli da parte dell'ASA.
Federico

 
Hai abilitato il modulo ftp_conntrak nel kernel? Potrebbe essere 
semplicemente quello

 del genere?
Benvenuto nel meraviglioso mondo della perniciosa interazione
tra ipvs e netfilter, al quale si sovrappongono le peculiarità
dell'orribile protocollo ftp e la fantasia di coloro che scrivono
client ftp.
Grazie al cielo, è un bel po' che non devo affrontare l'incubo
dell'interazione lvs-netfilter (in verità lo stronzo è lvs...), quindi
non so quale sia lo stato dell'arte.

 del genere?
non e' che cuteFTP di default cerca di stabilire una connessione 
crittografata (via SSL o TLS?)
-- 
Mi contraddico, forse?
Ebbene mi contraddico (sono vasto, contengo moltitudini)
                                         -- Walt Whitman

 client ftp.
Yuk!
Le beghe dovrebbero sparire con l'integrazione in corso di LVS con lo
stack di netfilter, comunque.
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 stack di netfilter, comunque.
Speriamo che l'op possa aspettare.

 Speriamo che l'op possa aspettare.
Pi� che altro proverei con un kernel "bleeding edge", se pu�
permetterselo: non ho seguito gli sviluppi da vicino quindi potrei dire
castronerie, ma una buona parte dell'integrazione � gi� stata eseguita.
Alla documentazione e al testing sul campo da parte dell'OP stabilire
"quanta parte"...


 "quanta parte"...
Trovasse una distribuzione fatta apposta, che funziona allo scopo,
forse sarebbe la cosa migliore, nel senso che gli ultimi oltre
bleeding edge di natura, rispetto a quelli di alcuni mesi fa sono pure
piu` lenti.
A sproposito qualcuno ha mai usato e/o sa se per un lavoro del genere
potrebbe funzionare / essere appropriato / dare meno problemi ebtables
(fw a livello di bridge, livello 2 ISO/OSI se non sbaglio). Io ho
provato ad usarlo una sola volta su una macchina sottodimensionata con
squid a fare da transparent proxy e, vuoi per l'hw scarso, vuoi per le
mie scarse conoscenze dell'oggetto e infine per la scarsita` di tempo
ho poi dovuto ripiegare su una soluzione standard perche' quella era
troppo lenta (faceva passare un bit alla volta, piu` o meno al
secondo).
Andrea

 (fw a livello di bridge, livello 2 ISO/OSI se non sbaglio).
Mi rispondo da solo. Direi di no, dato che credo che lui abbbia
bisogno anche
di fare routing e questo a livello 2 non lo puoi fare.

 (fw a livello di bridge, livello 2 ISO/OSI se non sbaglio).
Non vedo che c'entri con il thread, ad essere sinceri.
Firewall in bridge ne ho installati per anni, fin dai tempi del kernel
2.4, ed ebtables mi � capitato di doverlo usare una volta sola per
girare attorno ad incompetenze altrui (brouter, che parola orrenda...).
E' fantastico per fare minchiate incredibili, ma da usare in situazioni
talmente particolari che non capita spesso di metterci mano...


 talmente particolari che non capita spesso di metterci mano...
Tutto il firewall di linux è fantastico, diciamolo.
Ha qualche feature in meno sul fronte HA rispetto a pf, ma su tutto il resto
è anni luce avanti e non solo rispetto a pf...

 stack di netfilter, comunque.
Era ora, visto che LVS fa un po' il cazzo che gli apre, rispetto a tutto
il resto del network stack di Linux...

 Quoto.
Calmini! :-)
Avevo cominciato la frase con "A sproposito" e 2 minuti dopo
l'affermazione incriminata
mi ero autocorretto, dicendo appunto che non c'entrava.
Andrea

 è anni luce avanti e non solo rispetto a pf...
Mah, questa è una considerazione sulla quale nel corso del tempo ho
finito per ricredermi.
L'approccio "doppio" di pf (pass in - pass out) lì per lì ti fa
incazzare, ma oggettivamente quando si tratta di gestire firewall con
una tonnellata di porte (fisiche o dot1q), ciascuna indipendente nel
ruleset, rende tutto *molto* più facile da gestire.
Potrei citare esempi di vita vissuta.
Di contro, gli helper di iptables sono assolutamente impagabili per la
gestione di traffico balordo (tipo FTP ecc) ma anche e soprattutto per
tutta la pletora di ICMP (peccato che ip6tables da questo punto di vista
sia ancora indietro, come mi sto accorgendo di recente).
pf ha quella di lavorare con un file di configurazione e non per script,
il che permette di usare sintassi compatte per raggruppare oggetti senza
dover ricorrere a cicli e scritture che rendono il ruleset molto meno
leggibile.
Con iptables dovresti ricorrere a wrapper, che però hanno il grosso
svantaggio di farti perdere molta dell'atomicità e del controllo sul
flusso che sono il più grande pregio di iptables.
Il capitolo HA lo hai citato tu quindi non ripeto.
Sinceramente, un firewall che permetta le scritture compatte di pf, con
il supporto HA di pf, ma che consenta il controllo fine di iptables e ne
utilizzi gli helper sarebbe IL firewall.


 leggibile.
Trovi che sia così determinante?
P.S.
A tal proposito, ma quella cosa di cui abbiamo discusso in privato
sull'active-active è morta lì o hai optato per bsd?

 Calmini!
- And what's Fonzie like?[...]
- Cool?
[...]
- [...] And that's what we're gonna be. We're gonna be cool. 

 sull'active-active è morta lì o hai optato per bsd?
Ho optato per l'active-passive. :-\
Troppa roba da fare e troppo poco tempo per farla, sicchè ho optato per
la soluzione meno figa ma anche meno problematica... :-(


 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)

 sulle proprie regole.
Leggasi "innestare le proprie regole sulle sue"


 client ftp.
Ciao a tutti,
    ci ho lavorato un pochino, ma in effetti le cose che mi si dicono 
qui, nel thread, le conoscevo.
Erano passati alcuni mesi e mi sono pure imbatutto in un utonto che mi 
diceva di fare quel che gli chiedevo, ma non era vero.
ALlora, il modulo conntrack l'ho caricato subito, le regole iptables ok, 
e lvs ok anch'esso.
Il dramma era la scelta PORT/PASV mode del client.
Poichè l'utonto uisava IE, mentre mi diceva e mi confermava di usare 
CuteFTPe di aver provato sia l'uno che l'altro modo.
IO avevo configurato correttamente tutto, era lui il problema.
Pe rla cronaca ha funzionato in PORT mode.
Io invece dal server linux lavoravo in PASV.
Non so bene il perhcè, ma mi sta bene cosi :)
Aggiungo, sempre per la cronaca, che ho abilitato anche il PPTP, dopo 
averci smadonnato un pochino: LVS ha fatto una piccola parte, poichè non 
riesce a gestire l'IP GRE, ma con iptables e i moduli del caso, anche 
lui è stato smarcato.
Grazie a tutti!!!

 client ftp.
Torno a bomba sul problema, perchè in effetti è una bella rogna.
Ho risolto semplicmente abolendo la seppur comoda presenza di LVS sulla 
porta 20/21.
Adesso con la regola di iptables seguente funziona sia ftp attivo che 
passivo.
-A PREROUTING -d interfaccia1 -i eth1 -p tcp -m tcp --sport 1024:65535 
--dport 20:21 -j DNAT --to-destination 192.168.1.1
Mi è comparsa però una semplice seccatura: il server FTP giustamente mi 
riporta come IP di connessione quello del firewall, l'interfaccia1.
Qualcuno ha un suggerimento per fare in modo di avere gli IP dei client ?

 Qualcuno ha un suggerimento per fare in modo di avere gli IP dei client
Occorerrebbe vedere tutto il set di regole di nat, in particolare modo quelle
di SNAT, per capire dov'è il problema...

 di SNAT, per capire dov'è il problema...
*nat
:PREROUTING ACCEPT [44159:13470616]
:POSTROUTING ACCEPT [505:36371]
:OUTPUT ACCEPT [39461:2520815]
:pptp - [0:0]
-A PREROUTING -j pptp
-A PREROUTING -d 128.0.0.2 -i eth1 -p gre -j DNAT --to-destination 
192.168.1.90
-A PREROUTING -d 128.0.0.2 -i eth1 -p tcp -m tcp --sport 1024:65535 
--dport 1723 -j DNAT --to-destination 192.168.1.90
-A PREROUTING -d 128.0.0.2 -i eth1 -p tcp -m tcp --sport 1024:65535 
--dport 21 -j DNAT --to-destination 192.168.1.1
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o eth1 -j MASQUERADE
Questa è la parte relativa.
eth1 è 
192.168.1.12/24
eth0 è 
128.0.0.2/24
Tramite fastweb le chiamate in ingresso è uscita da 128.0.0.2 vengono 
traslate all'ip pubblico.
Non credo sia in alcun modo questo il problema, poichè con LVS funziona 
correttamente...
Grazie

 poichè con LVS funziona correttamente...
Eh, ma ti è già stato detto che LVS fa un po' quel cavolo che vuole, per
quanto riguarda le interazioni con netfilter...