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/
