All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
ovpn+tinyproxy tiny:312x=>tun+ HELP!!!!!
lowendtalk rocks, that said:
I'm trying to make something I haven't found a guide for, so please don't ask me to google it, I've already googled it.
I have a [email protected] service implementation, which works for "systemctl start openvpn@provider-country-etc" it has the "--proxy-noexec" argument so I can set my routing rules according to my network. all good so far.
when openvpn establishes the connection it will create a set of files for starting a tinyproxy service with the same @=>, so tinyproxy knows what ip to bind to according to the one assigned by vpn server. so far so good.
THE NEED:
I want to start a tinyproxy instance for each openvpn connection so using localhost:3128 will use tun0, 3129 will use tun1 and so on.
THE PROBLEM(S):
when I make several openvpn connections, tun0 and tun1 MIGHT get the same local ip assigned to them (ex: 172.21.22.91).
So when I make a rule like
"ip rule add from 172.21.22.91 checkout 100"
"ip route add default via 172.21.21.1 dev tun0 table 100" #vpn gateway
MIGHT be routing requests through the wrong tun interface.
Marking packets in the PREROUTING phase isn't a solution, since I'm already using a specific port for each tinyproxy instance, the problem is with the NEW connection tinyproxy establishes for the remote peer (ex: ipecho.net/plain).
I've seen GUID or UID approaches which don't apply for this case, since all the tinyproxy instances use the same user.
Also I've seen the ip route suit not allowing the --pid anymore (which would be a fantastic solution to this).
THE SOLUTION:
the only solution I can think of to make it work for several "dynamic values" tinyproxy instances, is giving tinyproxy a new conf option named-like "fwmark" and marking the packets that go from TINYPROXY to the remote server (ex: ipecho.net) so I can correctly forward them to the right tun interface..
After a couple try-and-error I am stuck with "spurious" packet retransmissions and I would like to call all the tremendous-minds here so maybe we can all figure a definitive in-code clean solution.
this involves touching tinyproxy c code and this is what I got so far:
SCREENSHOTS of packet captures:
case 1: http://www.zimagez.com/zimage/capturadepantalla-190417-123158.php
just apply a rule to all packets from tun+ local ip to go straight to that tun's default gateway.. (NOT 100% A SOLUTION since multiple TUN can have the same ip).
case 2: http://www.zimagez.com/zimage/capturadepantalla-190417-141409.php
applied a code change to tinyproxy source to add FWMARK=3 to the sockfd before it tries to connect.
PASTEBIN for code changes, unit files and scripts: https://pastebin.com/QieVLE17
SO at this point I don't know why tinyproxy connect() attempt to ipecho.net is not getting the ipecho response, since it's freaking giving a response and it even shows up coming back to tun0, then the retransmits begin and I start swearing all around the place.
thank you all guys/girls/etc in advance, I really feel comfy coming here every day to leech offers and always enjoy the drama.
Comments
Leech? Just make sure you leave some leftovers for me.
I wonder if it's possible or I'm just missing something