Newsgroup: it.comp.os.linux.sys
Titolo: Squid + winbind + iptables redirect

Qualcuno può dire un sì o un no alla semplice domanda:
posto un proxy con squid + winbind, è possibile effettuare un redirect
per farlo funzionare in transparent o le due cose si escludono
vicendevolmente?
Mandi...
-- 
Emanuele Balla aka Skull
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

 vicendevolmente?
Ritengo che sia fattibilisimo. Le due cose non si escludono assolutamente.
Ovviamente se vuoi che gli utenti usino squid e non siano solo mascherati,
blocca la porta 80 in forward altrimenti se sul browser disabilitano il
proxy, navigano ugualmente.
Suppongo ovviamente che il tuo redirect significhi un NAT.
Max

 tuo redirect significhi un NAT.
Intendo proprio il redirect ;-)
Che poi sia un nat siamo d'accordo...
In ogni caso bloccare la porta 80 in FORWARD non ha nessun significato,
dato che intercetto il traffico per la porta *prima* che passi per la
catena di forward...
Byez!


 catena di forward...
Scusa, come fai? Mica ho capito? Non i torna molto questo discorso, ma forse
mi sono perso qualcosa.
Max

> Prerouting.
Ops, non ci avevo pensato.
Avete ragione.
Max

 catena di forward...
Dipende tutto dall'architettura di rete.
Ricorda pero` che i browser in circolo in questo momento non
gradiscono che gli venga chiesta autenticazione da parte di un proxy,
e pertanto o la ignorano o (talvolta) vanno in crash.
Ergo: se fai transparent-mode, niente autenticazione.
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
Happy feast of the pig!

 autenticazione.
Ottimo, esattamente quello che volevo sapere (possibilmente senza perdere
troppe ore in bestemmie per i test).
In effetti ho provato a farglielo fare e il browser (in questo caso IE)
mi dà un errore di host non trovato.
Eventualmente sai anche indicarmi browser che eseguono correttamente
l'autenticazione, tra quelli più gettonati?
Byez e grazie mille..


------------------------------  FINE  ------------------------------<
Se un pacchetto non crea una nuova connessione *NON* passa per la
PREROUTING.
-- 
Ciao da Villo  -  GPG public key available
                  Ferrara LUG 
http://ferrara.linux.it

 l'autenticazione, tra quelli più gettonati?
In una parola: nessuno.
Ricorda che il transparent-mode viola piu` o meno tutto cio` che e`
sacro del TCP (cosi` come l'autenticazione integrata Microsoft viola
tutto cio` che e` sacro dell'HTTP).
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
Fain would I climb, yet fear I to fall.
		-- Sir Walter Raleigh


Scusate se mi aggiungo....io ho configurato un proxy-firewall equipaggiato
con squid e iptables...poi ho patchato il kernel (2.4.20)  con il protocollo
h323 di netfilter per poter far uscire netmeeting(ma anche gnomemeeting), ma
ho questo problema: il router adsl non mi natta correttamente...la mia conf
è così:
[router adsl]===[Proxy-firewall]===[lan]
quel cane non mi permette di ricevere audio e suono ma solo di inviarlo...
Come faccio dal firewall a nattare la porta wan del router al firewall
stesso?..cioè vorrei che per i pc della lan quando si connettono con
netmeeting e lanciano una connessione al proxy sulla porta 1720(
ridirezionata al kernel) sembri come se già fossero sul router...
Grazie per eventuali tips
Ciao
Alessandro

 giustamente compilato.
...esattamente....purtroppo mentre non ero presente hanno comprato un router
asus che fàà da router adsl ,switch e wireless spendendo circa 1000
euro....se fossi stato presente avrei fatto comprare un modulo adsl per
cisco ed era fatta!...dovò lavorarci un pò sù...
ATTENZIONE
Colgo l'occasione per rispondere al thread....c'è un piccolo workaround per
fare un redirect  per taluni client o PC....si chiama proxy.pac.....forse fà
al caso di chi ha iniziato questo post...faccio un esempio...data la
funzione:
function FindProxyForURL(url, host)
    {
         if (isInNet(host, "198.95.0.0", "255.255.0.0"))
             return "DIRECT";
         else
             return "PROXY 
proxy.mydomain.com:3128
";
     }
 ...se il client appartiene alla lan, usa  la macchina del proxy, ma
bypassando squid e quindi ricadendo in eventuali regole di firewall, se non
appartiene usa la macchina del
 proxy passando per squid normalmente!...dovrebbe fare al caso tuo!
Cerca doc su proxy.pac in rete!
Ciao
Alessandro

 Ed allora passa per il prerouting.
Dal NG krukko non vedo l'originale... comunque...
Quale è il problema?
Il primo pacchetto crea lo stato. A tutto gli altri appartenenti alla
stessa connessione vengono applicate le stesse rules.
Il fatto che la rule la definisca il primo pacchetto è trasparente...


 Cerca doc su proxy.pac in rete!
Si, ho presente e già lo uso, ma non ha nulla a che vedere...
Ho due possibilità: usare il proxy con autenticazione e dovere impostare
il proxy su tutti i client, oppure farlo trasparentemente tramite
redirect delle sessioni http, ma senza autenticazione.
La tua ipotesi ricade comunque nel caso 1: devo comunque impostare su
tutti i client la posizione del proxy.pac.
La mia necessità era di avere l'uno e l'altro. Il motivo per cui
proponevo winbind è che, se il browser è explorer, squid piglia
direttamente il token assegnato alla macchina autenticata dal pdc, ne
verifica la validità con lo stesso pdc. Se l'utente che usa explorer è
già autenticato sul pdc, non domanda nient'altro e lo fa passare. In
questo modo ho un proxy con autenticazione "trasparente" all'utente e al
suo browser. La speranza era quella che, non essendoci richiesta *attiva*
di una password, si potesse effettuare il redirect, in modo che il client
lavorasse *senza* un proxy configurato, ma tuttavia usandolo e
autenticandocisi (esiste???).
Se trovo qualche maniera vi faccio sapere.
Byez


 Ed allora passa per il prerouting.
Scusa, ma hai letto quello che ho scritto?
Se sei di cattivo umore io lo sono di più, ho appena trovato un backup su 
nastro corrotto, quindi non conviene fare partire una flame war.


 PREROUTING.
Ok, adesso mi è arrivata ;-)
Si, hai ragione, ma il motivo è (dallo stesso man):
SNAT
This target is only valid in the nat table, in the POSTROUTING chain.
It  specifies  that  the  source address  of  the  packet should be
modified (and all future packets in this connection will also be
mangled), and rules should cease being examined.
(chiedo scusa per il quote un po' molesto)
Ovvero: è vero che la chain viene attraversata solo dal primo pacchetto
(quello che crea lo state). Ma questo per un motivo:
quando viene ricevuto un nuovo pacchetto, per prima cosa si va a vedere
se fa parte di uno state già esistente. Solo se così non è, viene tentato
il match con le regole delle varie chain. Se invece appartiene ad uno
state, viene applicata la regola che è definita dallo state.
La ragione è di performances: matchare gli state è molto più veloce ed
efficiente che non matchare le rules.
E' vero che i pacchetti non passano più per la chain, ma dal punto di
vista del comportamento, non mi cambia nulla: il nat viene applicato
ugualmente...
Ma l'argomento è interessevole ;-)


 
Si, ma parlando di quanto a subject, qui il concetto era quello di dare,
sul gateway/firewall/proxy, un 
$IPTABLES -A PREROUTING -p tcp -s $INT_NET --dport 80 -j REDIRECT \
--to-ports 3128
in questo modo inserire anche un 
$IPTABLES -A FORWARD -p tcp -s $INT_NET --dport 80 -j DROP
non mi serve a nulla.. tutto viene già rediretto a squid.
In ogni caso, la policy è ovviamente a DROP, quindi dovrei (casomai)
evitare di aprirla ;-)
Però in linea teorica non viene mai attraversata.. ci sono forse casi che
mi sfuggono nei quali invece questo accade?
1) Se una rule matcha in forward vuol dire che matcha anche in PREROUTING.
2) Se invece non attraversa la chain è perchè ha uno state. Ma questo state
ricade nel caso 1 e quindi anche nel caso 2 segue la stessa sorte.
Mi scappa qualcosa?


 1) Se una rule matcha in forward vuol dire che matcha anche in PREROUTING.
Non è detto, la man page (e quello che è capitato a me lo conferma) dice 
diversamente.


 un inizio di connessione avviene con un pacchetto tcp flaggato SYN?
Ok:
http://www.iptables.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES
Tanto per puntualizzare: "NAT - PREROUTING: This chain is used for 
Destination Network Address Translation mainly. Source Network Address 
Translation is done further on. Avoid filtering in this chain since it will 
be bypassed in certain cases."
E questa č la documentazione ufficiale, sul sito degli sviluppatori.
Se pensi di saperne piů di loro buon per te, percepirai uno stipendio 
adeguato alle tue conoscenze.


 attraversa quella chain.
Scusa, per il filtering ok, tant'evvero che è deprecated, ma riguardo al
NAT dove li intenderesti fare se non in {PRE|POST}ROUTING? 
Byez...


 newreader.
Huhm... eppur è pan.. :-P
cercherò di capire dove sta l'inghippo...
se qualcun altro ha lo stesso problema mi maili in privato plz : il
dominio è skullkrusher e non skull
Sorry for the inconvenience...
