On 09/27/2012 06:59 PM, alex alex wrote:
> Totusi, inca nu inteleg logica dupa care doar primele pachete creaza entry
> nou cu match;
> ma gindesc ca era mai bine sa matchuiasca de cite ori putea si * sa
> instaleze in nf_cache*
Pune-te in pielea unei masini care ruteaza sute de megabiti. Chiar
On Thursday, September 27, 2012 08:08:28 pm manuel "lonely wolf" wolfshant
wrote:
> On 09/27/2012 06:59 PM, alex alex wrote:
> > Am facut asta de mai multe ori; oricum, pentru ca regulile
> > erau in testing, le introduceam manual de fiecare data.
> > Banuiesc ca lusrurile se intimplau astfel:
> >
On 09/27/2012 06:59 PM, alex alex wrote:
> Am facut asta de mai multe ori; oricum, pentru ca regulile
> erau in testing, le introduceam manual de fiecare data.
> Banuiesc ca lusrurile se intimplau astfel:
> 1/restartam firewall-ul standard, in vreme ce sursa trimitea permanent.
> 2/ kernelul isi fa
On 09/27/2012 12:50 PM, alex alex wrote:
> Asta a fost.
> Dupa expirarea flow-lui, cu regulile existante am pornit sursa.
> Magie: functioneaza DNAT-ul, desi numai 2 pachete se inregistreaza in
> cahain-ul de prerouting
Ar fi mers de la inceput daca dadeai un service iptables stop urmat de
reporni
On 09/27/2012 12:12 PM, Mircea Ciocan wrote:
> 2012/9/27 alex alex:
>> Linux 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:13 EDT 2011 x86_64 x86_64
>> x86_64 GNU/Linux
>2.6.18, hmm... probabil masina mai ruleaza si un chiumail cu multe
> patchuri, ca e secure :
Acel 2.6.18 asa o sa ramina in
On Thursday, September 27, 2012 11:49:28 am alex alex wrote:
> Regula e neatinsa de pachete. Ce ma macina este faptul ca nu se face match
> in prerouting.
> Poate ca prima intrebare este de ce un pachet nu face match pe o regula in
> prerouting,
> DNAT-ul fiind o actiune ulterioara match-ului. Sau
On Thu, 27 Sep 2012, alex alex wrote:
Salut.
"cat /proc/net/nf_conntrack|grep -w 1234" ce zice?
> Regula e neatinsa de pachete. Ce ma macina este faptul ca nu se face match
> in prerouting.
> Poate ca prima intrebare este de ce un pachet nu face match pe o regula in
> prerouting,
> DNAT-ul fiind
On Thu, 27 Sep 2012, alex alex wrote:
Salut.
Ce kernel ai?
> Regula e neatinsa de pachete. Ce ma macina este faptul ca nu se face match
> in prerouting.
> Poate ca prima intrebare este de ce un pachet nu face match pe o regula in
> prerouting,
> DNAT-ul fiind o actiune ulterioara match-ului. Sau
ipforward ce zice ?
si incearca si dnat-ul recomandat intr-un singur pas (n-am testat
niciodata cu chain-uri, teoretic ar trebui sa mearga, dar mai safe
incearca si fara jump-uri, ca am mai patit diverse dude de genul asta)
On 9/27/2012 11:28 AM, alex alex wrote:
> Dump-ul imi spune ca pachetul
On Thursday, September 27, 2012 10:41:14 am alex alex wrote:
> Cum am spus, celelalte tabele au default ACCEPT:
> iptables -L -n -v
> Chain INPUT (policy ACCEPT 1442K packets, 488M bytes)
> pkts bytes target prot opt in out source
> destination
>
> Chain FORWARD (policy ACCEPT 300K p
On Thu, 27 Sep 2012, alex alex wrote:
Salut.
Lipseste dump-ul pachetului ICMP (pachetul UDP original).
Poti sa refaci tcpdump-ul, te rog?
> E accesibil, insa nu e direct conectat. Din B:
> ping 172.16.116.142
> PING 172.16.116.142 (172.16.116.142) 56(84) bytes of data.
> 64 bytes from 172.16.11
ce netmask e pus pe eth0 ? sigur e accesibil serverul A direct de pe B ?
9/27/2012 10:38 AM, alex alex wrote:
> Schema e simpla (A, B, C sunt calculatoarele; intre ele sunt rutere (R)) :
>
> A
> --- Eth0 -- Eth1
> 172.20.44.36
pare in regula la prima vedere (nu stiu de ce te-ai complicat cu
chain-uri in plus, dar in fine, daca ti-e mai usor atunci asa sa fie -
de fapt vad ca si loghezi pe acolo, e mai simplu de gandit asa)
o singura nedumerire am: sigur e eth1 interfata pe care vin pachetele de
dnat-uit ?
cred ca nu
13 matches
Mail list logo
