On Fri, 26 Nov 2010 16:08:14 +0200
Florin Popovici <[email protected]> wrote:

> 2010/11/26 Adi Pircalabu <[email protected]>
> 
> > 2010/11/26 Alexandru Cristea <[email protected]>:
> > > Routerul are ruta spre 192.168.x.y/24, deci stie ce sa faca cu
> > > pachetele buclucase (care pleaca cu sursa <qmail_outgoing_ip> spre
> > > reteaua interna). Banuiala mea e ca mailer-ul intern nu stie ce
> > > sa faca cu pachetele destinate <qmail_outgoing_ip>. Pachete care,
> > > daca ar ajunge la router, chiar pe interfata interna, ar fi
> > > recunoscute ca 'proprii'.
> > > Daca-i asa, o ruta pe mailerul intern ar rezolva problema.
> >
> > Nu sunt sigur ca ai inteles problema. Ce se intampla e ca, atunci
> > cand qmail-remote creaza socket-ul ca sa se conecteze la server sa
> > livreze mesajul, foloseste neconditionat adresa configurata in
> > /var/qmail/control/outgoingip. Daca acel IP e atasat unei interfete
> > diferite fata de cea pe care se intentioneaza sa se initializeze
> > conexiunea, tcp-ul cracks the shits.
> >
> 
> 
> Actually, cred ca Alex Cristea are dreptate; si eu am propus aceeasi
> solutie (ca "varianta 2").

Intr-adevar. Se pare ca nu am citit chiar cu mare atentie toate
mesajele.

> 
> TCP-ul n-ar trebui sa "crack the shit" daca IP-ul e pe alta interfata.

`ssh -b` face acelasi lucru ... si functioneaza.

> Decizia de routing din kernel se uita la IP destinatie, si daca acesta
> corespunde la *oricare* din IP-urile locale ale masinii (indiferent
> pe ce interfata), il proceseaza local (trimite la chainurile INPUT,
> apoi la procesul local bind-uit pe IP/portul respectiv).
> 
> Cred ca totusi trebuie disablat rp_filter pentru ca asa ceva sa
> functioneze.
> 
> Vezi http://linux-ip.net/html/routing-tables.html#routing-table-local
> si http://lartc.org/howto/lartc.kernel.html
> 

ducu
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug

Raspunde prin e-mail lui