Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


New on LowEndTalk? Please Register and read our Community Rules.

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

Sign In or Register to comment.