iptables routing based on port or IP address should do it, I would think.
EDIT: /u/Warepredator, I did a little more digging into different forms of matching rules iptables supports. If you have a hard time making a rule based on ip/port (as /u/talking_to_strangers said), you could match by the process creating packets -- namely, the Twitch client. See here for how to. You could either launch twitch as its own user or group and filter based on either of those, or determine the PID with a command like pidof [twitch process name]
or ps aux | grep -i twitch
, roughly.
Also, here are a bunch more matching rules. Feel free to reply or message me if you need help.
NAT one of the networks. You could even do 1-to-1 NAT if you still want each device to have a unique IP. In IPTables, you'd do a Netmap.
You're not going to find much outside of the code itself. There's a breakdown of netfilter here that might help: http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-4.html
Really, just doing basic research using Google is all you can do.
Put it behind a linux gateway and play around with the random patch until the connection is so bad that the remote control software only just works...
Or if you're using a VM with the capability to mess with the stability/quality/speed of the internet connection, you can just do it there...
You would just make the actual PC handle the routing duties. Nothing special needed, just 2 NICs in the PC. You'd still need an external switch though.
With Windows, you'd use Internet Connection Sharing/Windows Firewall. It's doable in Linux as well, I think using the various tools from the Netfilter project.
I replied in more detail to /u/fryed_chikan, but if you add the following to your iptables.up.rules (or whatever you called that file) it'll work:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
I'm pretty sure this can go anywhere as part of your chain, but generally you should stick it at the top of the INPUT section, right above `A INPUT -p udp -m udp --dport 53 -m state --state RELATED,NEW,ESTABLISHED -j ACCEPT'
If you want to more about the netfilter configuration language (which iptables uses), there are docs, faqs, and howtos on the netfilter homepage.
If you have not read it, i would recommend reading this guide.
Linux Advanced Routing & Traffic Control
Its not new, and some of the stuff might be outdated, but it gives a good indication of the possibillities in Linux network routing and trafic control.
Another guide about iptables is this one.
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
It's also not new, but it covers almost every detail about iptables.
And there is also the official documentation for netfilter/iptables.
I personally don't use IPCop so I'm not sure if the IP cop UI will help you there because it's more of an advanced setup.
If it was me I'd stand up an alias on the same network as the VPN tunnel and selectively mangle all traffic from that one host to look like it's coming from the new alias you stood up.
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
If you're going to try something like this you'd be better off creating an IP tables init script to configure your own firewall and avoid products like IPCop. You can still do traffic accounting without it, you just have no pretty UI.
http://www.catonmat.net/blog/traffic-accounting-with-iptables/
These links might not be the best, they're honestly the first ones that came up with my powerful google-fu skillz.
Use a DNAT with iptables, and add a static route to github through your fiber line.
edit: On further consideration I reccomend you do a stateless NAT with iproute2
Well, the -L flag is for listing, and you'd probably want to combine that with -v and -n. If you don't specify a table with -t then by default the 'filter' table is listed, but most likely you also would care about other tables like 'nat' and 'mangle' (see /proc/net/ip_tables_names
for a dynamic list of the names of active tables.) Combining that you could use something like
while read T; do iptables -t $T -nvL; done </proc/net/ip_tables_names
I tried the above on an embedded system with busybox and for some reason busybox doesn't support that form of redirection, so you'd have to use something like this instead:
for T in $(cat /proc/net/ip_tables_names); do iptables -t $T -nvL; done
However, the output of iptables -L is meant for human consumption and it can't be used as input to restore anything, so I'm really not sure how useful any of this would be in the first place. You could conceivably write a script that turns the -L output into a series of iptables commands to recreate the rules, but that would be a lot of work. It would be much easier just to compile the iptabes-save command from source. Surely you have a crosscompiler toolchain from the vendor? If not, it should be available on their site somewhere. Grab the iptables source and get cross-compiling.
It sounds like you need to change the NAT rule in your iptables configuration.
Example from netfilter NAT HOWTO:
## Change source addresses to 1.2.3.4. # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
> Rereading your rule again, I don't see how that actually would work at all. Remember that the issue is that my source device can only specify the remote server to which it wants to connect using a hardcoded IP address.
You could mangle the packet with iptables. In short your read-only-limited device sends a packet to an IP on NAT. That device then does the necessary lookup and sends it to the right place.
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
http://www.faqs.org/docs/iptables/mangletable.html
iptables -t nat -A PREROUTING -d 8.8.8.8 -j DNAT --to-destination 208.122.23.22
You might have to write a script which does a lookup on --to-destination and substitutes the IP in, because that parameter cannot accept a hostname.
Looking at your squid.conf I don't see any entries for "intercept" or "Transparent" http_port configurations. This is a BIG reason why it won't work.... Don't forget squid will listen on one port for non-transparent operation (like when you plug the info into IE) and it will listen on another port for the transparent operations. Make sure this port (after you configure it) is open too!
You want to use the PREROUTING not POSTROUTING for sending web packets transparently to squid. See here:
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect
IPTables of course has a standard command syntax:
Documentation about the netfilter/iptables project has some docs.
If you are not familiar with TCP/IP The TCP/IP Guide seems to be a good start.
> iptables -t nat -A PREROUTING -p tcp --dport 32400 -s localhost -d localhost -j REDIRECT
You may need to alter the -s (source ip) or -d (destination ip) arguments.. for examle.. if the server is listening on 0.0.0.0 instead of localhost. Note: those options are used to filter packets and don't correspond to redirecting the connection.
http://blog.softlayer.com/2011/iptables-tips-and-tricks-port-redirection
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-5.html