[Traffic Shaping] Transparante Proxy

[No13]

Ik ben de laatste tijd wat meer bezig met traffic shaping met behulp van HTB. Dit gaat op zich lekker en ik begin het redelijk door te krijgen maar nu loop ik tegen een probleempje aan.

Normaal als ik een transparante proxy op wilde zetten installeerde ik Squid op de router en via iptables stuur je dan alle verkeer naar poort 80 via squid door.

Het traffic shaping wordt toegepast op de interne netwerkkaart van een linux doos (niet mijn keus, zo werkt dat nu eenmaal)

Met andere woorden als ik HTTP traffic zou gaan shapen kan Squid mijn hele internet lijn toch dichttrekken, maar daarentegen zouden downloads uit de cache van Squid geshaped worden... een beetje de omgekeerde wereld.

Een van de oplossingen die ik heb verzonnen is om de Squid proxy niet op de router maar op een aparte machine binnen het interne netwerk te zetten. Maar als je die proxy dan transparant wil maken komen de pakketjes toch weer langs de traffic shaper VOOR ze bij squid zijn geweest... (en daarbij weet ik niet of het transparant maken van een proxy zomaar kan als deze niet op de router draait... wellicht dat het met --snat werkt maar dan komen al je requests van 1 ip. Wil je dan je logs achteraf nog eens terugkijken schiet je daar niet veel mee op)

Lijkt dus de enige echte oplossing te zijn om een niet-transparante proxy op te zetten? Is dit echt zo? Is er iemand al eens tegen dit probleem aangelopen die er een betere oplossing voor heeft gevonden?

[it0]

Traffic shapen kan alleen maar op je uitgaande interface.

Dus niet shapen bij squid, maar shapen bij je wan verbinding.

[No13]

it0 schreef op maandag 22 oktober 2007 @ 14:55:
Traffic shapen kan alleen maar op je uitgaande interface.

Dus niet shapen bij squid, maar shapen bij je wan verbinding.

Ok ter verduidelijking, ik wil het downloaden gaan shapen. De uitgaande interface is dan dus de interne interface (webserver verstuurd, wan iface ontvangt, lan iface verstuurd)

Als ik Squid van de router naar een andere machine ga verplaatsen kan ik volgens mij niet makkelijk/fatsoenlijk transparant proxy-en. Als ik de proxy op de router laat kan ik volgens mij niet shapen.

Ik hoop dat ik het mis heb en vraag of anderen hier een betere oplossing voor hebben

[it0]

Snap het niet meer zo goed, je hebt 2 netwerkkaarten in je machine zitten en je shaped op de verkeerde nic? Iptables kan je toch per subnet en of nic doen?

[No13]

it0 schreef op maandag 22 oktober 2007 @ 16:00:
Snap het niet meer zo goed, je hebt 2 netwerkkaarten in je machine zitten en je shaped op de verkeerde nic? Iptables kan je toch per subnet en of nic doen?

Ik heb een router met inderdaad 2 netwerkkaarten. Achter deze router komen een hoop pc's en ik wil de download's over mijn internet lijn kunnen shapen. De upload ga ik ook shapen maar dat is niet relevant voor dit verhaal.

Ik heb begrepen dat je alleen kunt shapen op de interface waar de data wordt verzonden. Bij het downloaden zou dat dus niet de WAN interface zijn, deze ontvangt de data. De LAN interface is de interface die deze data weer naar de client in kwestie gaat sturen, en hierop moet het shapen dus plaats vinden (of heb ik dat niet goed begrepen?)

Het shapen op zich werkt prima, lijkt me dus niet dat ik op de verkeerde nic zou shapen (er is zowieso maar 1 nic waarop je kan shapen lijkt me?).

Iptables doet niets met shapen, dat doet TC. Iptables komt pas om de hoek kijken wanneer ik de proxy transparant wil maken, dit scheelt het moeten instellen van de proxy op alle clients. Ik ben echter bang dat het technisch gezien niet mogelijk is om de traffic shaper en transparante proxy op dezelfde machine te draaien.

[it0]

De LAN interface is de interface die deze data weer naar de client in kwestie gaat sturen, en hierop moet het shapen dus plaats vinden (of heb ik dat niet goed begrepen?)

Je hebt het goed begrepen, maar het heeft geen nut.

Je limiteert er namelijk niet de snelheid/bandbreedte mee waarmee de pakketten binnen komen op de wan interface. Dit kan je alleen "enigzins" reguleren door de "ack" pakketten te vertragen. En dan nog werkt dat alleen voor connection-oriented verkeer en dus niet voor streaming (=udp) verkeer.

Stel je zou het bovenstaande toepassen dan krijg je dus allemaal small bursts ipv 50% van de bandbreedte.

[No13]

Ok maar hoe moet ik het dan aanpakken? Je hebt het een paar keer over shapen op de WAN kant, ik had begrepen dat dit niet kon maar dat kan dus wel?

Maar over die ACK's, worden die dan niet automatisch vertraagd in mijn voorbeeld? Als een pakketje van de server, via de router, naar mijn client gaat; dan moet de client toch een ack sturen? Als de router het pakketje dan vertraagd wordt de ack ook pas later afgeleverd...

Ik dacht het zo goed te begrijpen maar dat valt dus tegen

Edit: Ik ben nog wat verder gaan zoeken en ben inmiddels de termen ingress en egress tegen gekomen, ingress is het shapen van binnenkomend verkeer, egress het uitgaande verkeer.

Er zijn hier en daar mensen die het over ingress shaping hebben maar 9 van de 10 keer is de conclusie dat ze toch egress gaan shapen... Zijn deze berichten dan verouderd en is er inmiddels wel fatsoenlijke ingress shaping mogelijk? Het lijkt technisch niet echt mogelijk als ik de diagrammen zo eens bekijk

[ Voor 32% gewijzigd door No13 op 23-10-2007 13:27 ]

[it0]

Volgens http://en.wikipedia.org/wiki/Ingress_filtering is ingress heel iets anders dan wat jij vertelt.

Je hebt 2 routes
a) Client ->squid ->router->internet
b) internet->router->squid->client

Als je via B een packet met data krijgt, dan stuur je met A een ACK terug.

Nu zijn er 2 manieren om je datatoevoer te beperken
1) Zorgen dat je data window beperkt blijft, zodat de ander kleine data pakketten stuurt
2) Zorgen dat de ACK via route A er langer over doet, met als gevolg data data pakketten pas worden verstuurd dat de ack terug komt.

Waarom zou je dit doen? tenslotte gebeuren stappen 1 en 2 automatisch als de pijp vol zit

[No13]

Ik ben bang dat we elkaar niet helemaal goed begrijpen

Ingress en egress filtering is inderdaad wat anders als ingress en egress shaping. Maar kijk je bijvoorbeeld hier dan klopt mijn definitie in grote lijnen wel.

Ingress qdisc

All qdiscs discussed so far are egress qdiscs. Each interface however can also have an ingress qdisc which is not used to send packets out to the network adaptor. Instead, it allows you to apply tc filters to packets coming in over the interface, regardless of whether they have a local destination or are to be forwarded.

Daarnaast klopt het helemaal wat je zegt, alleen dacht ik dat jij mijn hele idee van traffic shaping afkeurt. Als ik je goed begrijp nu heb je het alleen over de specifieke SQUID setup? Zo ja dan hebben we het probleem te pakken

Hoe vallen traffic shaping en een transparante proxy te combineren met de voorwaarden:
- Squid mag je internet lijn niet dicht kunnen trekken (bandbreedte instelbaar via de shaper)
- De clients moeten een snelle verbinding hebben met de proxy (zonder shaper ertussen dus)
- De proxy moet transparant zijn.
- De client ip's moeten in de squid log te zien zijn.

De wereld zal niet vergaan als dit niet blijkt te kunnen maar ik kom er alleen niet uit en daarom hoop ik hier jullie hulp in te kunnen schakelen.

Wanneer je slechts aan 3 voorwaarden hoeft te voldoen uit het bovenstaande lijstje (welke 3 dan ook) is het prima te doen, maar juist alle 4 lijkt een probleem te zijn.

[ Voor 12% gewijzigd door No13 op 23-10-2007 14:14 ]

[it0]

Voor stap 3 en 4 gebruik methode 6.2 http://tldp.org/HOWTO/TransparentProxy-6.html
Dat reroute pakketten via squid en daarmee transparantie en client ip in de log
Stap 2 is altijd zo
Stap 1 blijft moeilijk aangezien je weinig controle hebt over wat er binnenkomt.
Bv ingress shaping maakt gebruik van het bucket principe. Dit betekent dat alle pakketen in een emmer terecht komen, vervolgens gaan ze druppels gewijs door. Raakt de emmer vol dan worden worden de pakketten weggegooid en moeten ze opnieuw verstuurd worden.

Dus dat betekent dat
a) je lijn toch dicht gaat zitten
b) het pakket al is gearriveerd
c) het opnieuw laat versturen
Dus je maakt het alleen maar erger daarmee.

Een betere oplossing zou zijn om een 2e internetverbinding te nemen.

[No13]

Hmm die link komt denk ik goed van pas... Het lukte mij namelijk niet om een transparante proxy te draaien op non-local.... op een andere doos als mijn router zelf zonder dat alle ip's uit de log verdwenen. Als dat dan komt omdat ik iptables nooit goed heb ingesteld ben ik er een heel eind uit denk ik.

Wanneer de proxy niet op de router draait kan ik gewoon mijn bestaande Traffic Shaper setup gebruiken.

Ik ga dit eens in een test-setup gooien...