filtrul fw iti zice ceva ? io ce zieam ? sau raspunde unde tre'ba!
Mihai Postelnicu wrote: > Se poate sari usor peste problema cu nat-ul (pt shaping pe upload) daca > marcam pachetul pe interfata interna, de ex : > > iptables -A PREROUTING -i eth1 -t mangle -s [ip_local] -j MARK > --set-mark 13 > > Facem scriptul htb-tools pt interfata externa, si in scriptu rezultat > dupa ce rulam q_parser, mai adaugam linii de genul : > > $TC $TFC 13 fw flowid 1:0x2a > unde de exemplu TFC="filter add dev $DEV protocol ip parent 1:0 prio 1 > handle" > > Pe interfata externa, chiar daca nu mai avem ip-ul, identificam > pachetele care pleaca dupa MARK. > > Mihai > > Cosmin Codita wrote: > > >>nu mai am mesajul original asa ca fac reply aici... >>cineva zicea ca din cauza nat-ului... e corect si asta >>nu stiu de interfete cum era da' sigur e si de la nat... ca pe placa de >>iesire deja pachetele nu mai au ip-ul sursa original ci nat-uit. >>hinturi: iqm sau filtrul fw >>bafta! >> >>Ratiu Petru wrote: >> >> >> >>>[EMAIL PROTECTED] wrote: >>> >>> >>> >>> >>> >>>>I-am trecut dst / src pe interfata spre retea, nu ar trebui sa imi >>>> >>>> >>>>ia pachetele pe destinatie / sursa? >>> >>> >>> >>> >>>>--- >>>>nu o faci pe interfata care trebuie. >>>> >>>> >>> >>>vezi ca qdisc-urile se ataseaza la iesirea de pe interfata, carevasazica >>>te poti lega numai de pachetele pe care le _trimiti_ (exista unele >>>solutii de ingress policing, dar sar peste astea). Deci limitarile de >>>download le pui pe interfata interna si cele de upload pe interfata >>>externa. Ca faci filtre cu u32 (dst/src) sau fw, asta vine mai tarziu. >>>Cert e ca pe eth1 n-o sa vezi pachetele care pleaca pe eth0. >>> >>>Petre. >>> >>>--- >>>Detalii despre listele noastre de mail: http://www.lug.ro/ >>> >>> >>> >>> >>> >> >>--- >>Detalii despre listele noastre de mail: http://www.lug.ro/ >> >> >> >> > > > > --- > Detalii despre listele noastre de mail: http://www.lug.ro/ > > > --- Detalii despre listele noastre de mail: http://www.lug.ro/
