Situatie:
Onderstaande aan elkaar geknoopt:
Provider IPTV backend <--> Linux Bridge <--> IPTV settopbox
Het IPTV subnet is geheel gescheiden van mijn LAN en van het internet. Dat wil zeggen dat het IPTV subnet ook zijn eigen nameservers heeft.
Doel:
De bridge gebruiken om verkeer tussen de settopbox en het backend te onderscheppen en te wijzigen. In eerste aanleg gaat het dan om TCP (HTTP verkeer), later wil ik ook multicast-verkeer wijzigen.
Huidige stand:
De Linux bridge werkt. Het betreft een software bridge welke twee fysieke etherner adapters brugt. Omdat de brug op L2 (ethernet) niveau werkt is hij volledig transparant waardoor TCP-, UDP- en multicast-verkeer er gewoon doorheen lopen.
Om het HTTP-verkeer te onderscheppen en te wijzigen dacht ik een Squid als transparante webproxy te gebruiken met een redirector. Dit heb ik werkend gekregen en getest in een browser zodat ik zeker weet dat http://iptv.net/file wordt geredirect naar http://lan.net/file.
Ik heb op de bridge alle TCP-verkeer bestemd voor poort 80 (HTTP) naar poort 3128 (Squid) geredirect:
Vragen:
- In welk subnet moet Squid staan, in mijn LAN- subnet of het IPTV-subnet? Zelf dacht ik
- Wordt de pagina naar aanleiding van de redirect door Squid opgehaald of door de settopbox? De settopbox kan http://lan.net niet bereiken omdat deze in een ander subnet zit. Dit zou mogelijk verklaren waarom het niet werkt.
- Is Squid i.c.m. een redirector de beste manier om mijn doel te bereiken?
- Het is mogelijk om een IP-adres aan de bridge interface te geven. Heeft dit nut in bovenstaand geval of niet? (Er over nadenkend: in welke (algemene) gevallen zou je een bridge interface uberhaupt een IP-adres geven?)
Onderstaande aan elkaar geknoopt:
Provider IPTV backend <--> Linux Bridge <--> IPTV settopbox
Het IPTV subnet is geheel gescheiden van mijn LAN en van het internet. Dat wil zeggen dat het IPTV subnet ook zijn eigen nameservers heeft.
Doel:
De bridge gebruiken om verkeer tussen de settopbox en het backend te onderscheppen en te wijzigen. In eerste aanleg gaat het dan om TCP (HTTP verkeer), later wil ik ook multicast-verkeer wijzigen.
Huidige stand:
De Linux bridge werkt. Het betreft een software bridge welke twee fysieke etherner adapters brugt. Omdat de brug op L2 (ethernet) niveau werkt is hij volledig transparant waardoor TCP-, UDP- en multicast-verkeer er gewoon doorheen lopen.
Om het HTTP-verkeer te onderscheppen en te wijzigen dacht ik een Squid als transparante webproxy te gebruiken met een redirector. Dit heb ik werkend gekregen en getest in een browser zodat ik zeker weet dat http://iptv.net/file wordt geredirect naar http://lan.net/file.
Ik heb op de bridge alle TCP-verkeer bestemd voor poort 80 (HTTP) naar poort 3128 (Squid) geredirect:
Dit lijkt echter niet te werken. Wellicht ook belangrijk te vermelden dat de Linux bak waarop dit draait drie fysieke ethernet adapers heeft: 2 voor de bridge en 1 voor het LAN. Squid en Apache zijn gebonden aan localhost en het LAN IP-adres.ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 --ip-destination-port 80 -j redirect --redirect-target ACCEPT
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128
Vragen:
- In welk subnet moet Squid staan, in mijn LAN- subnet of het IPTV-subnet? Zelf dacht ik
- Wordt de pagina naar aanleiding van de redirect door Squid opgehaald of door de settopbox? De settopbox kan http://lan.net niet bereiken omdat deze in een ander subnet zit. Dit zou mogelijk verklaren waarom het niet werkt.
- Is Squid i.c.m. een redirector de beste manier om mijn doel te bereiken?
- Het is mogelijk om een IP-adres aan de bridge interface te geven. Heeft dit nut in bovenstaand geval of niet? (Er over nadenkend: in welke (algemene) gevallen zou je een bridge interface uberhaupt een IP-adres geven?)
"Kill one man, and you are a murderer. Kill millions of men, and you are a conqueror. Kill them all, and you are a god." -- Jean Rostand