the server component had a small bug, empty checking the wrong variable before building a list of allowed zones
when using a config without any Fqdns defined this would result in the server refusing the client access to tunnel anything if any zones where about to be used
tup proxies services on the local network to a remote gateway, all traffic between the remote server and the service on the local network is sent through a wireguard tunnel
think of tup as an open source and self-hosted alternative to ngrok and cloudflare tunnel
tupd (the server) can be found at: https://drive.proton.me/urls/GEJM1HT0DW#aOop4p7zxaPA
the tup client can be found at: https://drive.proton.me/urls/63SE9PW020#GFzZrprg9wjZ
I also noticed all file extensions were not inspectable directly in the drive (even though everything is only text files), I apologize for that, I believe transparancy is a very important key factor
I've complemented with .diff files generated with diff from GNU diffutils, there are 'full' diff files for both tup and tupd (ending with _full.diff), and there is also a diff file for only the changes between tupd-0.5 and tupd-0.6 (tupd-0.6.diff)
the 'full' diff files can also be applied to an empty directory with GNU patch like this:
mkdir tupd-0.6
patch --directory=tupd-0.6/ --strip=1 < tupd-0.6_full.diff
Since my project is not uploaded by me to any git service many people didn't look on how it can be used so I want to give a few examples of the client, more explanations and examples can be found in the README.md and EXAMPLE.md of the client
Syntax: tup [-zone <zone>] [@][host]:[#]<port>
Examples:
tup :8080 this would proxy http://127.0.0.1:8080 onto a random subdomain on default zone, for example: https://xyz123.zone.domain.tld
tup 192.168.1.11:8080 this would proxy http://192.168.1.11:8080 onto a random subdomain on default zone
Syntax: tup -fqdn <domain> [@][host]:[#][@]<port>
Examples:
tup -fqdn sub.domain.tld :8080 this would proxy http://127.0.0.1:8080 directly onto https://sub.domain.tld
tup -fqdn sub.domain.tld 192.168.1.11:@8443 this would proxy https://192.168.1.11:8443 directly onto https://sub.domain.tld, skipping caddy and its tls termination on the server, same as a raw tcp proxy / sni proxy
Syntax: tup -udp|-tcp [rport:][@][host]:<port>
Examples:
tup -udp :27015 this would proxy udp://127.0.0.1:27015 onto a random UDP port on the server
tup -udp 27016:27015 this would proxy udp://127.0.0.1:27015 onto UDP port 27016 on the server
tup -udp 27016:192.168.1.11:27015 this would proxy udp://192.168.1.11:27015 onto UDP port 27016 on the server
tup -tcp :3306 this would proxy tcp://127.0.0.1:3306 onto a random TCP port on the server
I also want to clarify that the code is released with the Unlicense template, dedicating my software to the public domain
I think you have realized that every comment here was about your decision not to use Git. I don't think there is much more to say about this...
Yes unfortunately most of the comments on my last post was also about me not using git and git platforms, seems very controversial.
I totally understand it, I've also wanted to have everything git and social development platform before when it was new
This isn't about social platforms or using the newest-hottest tech. It's about following industry standard practices. You act like source control is such a pain in the ass and that it's some huge burden. And that I just don't understand. Getting started with git is so simple, and setting up an account with a repo host is a one time thing. I find it hard to believe that you don't already have ssh keys set up too. What I find more controversial and concerning is your ho-hum opinion on automated testing, and your belief that "most software doesn't do it". You're writing software that you expect people to not only run on their infra, but also expose to the public internet. Not only that, but it also needs to protect the traffic between the server on public infra and client on private infra. There is a much higher expectation of good practices being in place. And it is clear that you are willingly disregarding basic industry standard practices.
It is obviously about that since no good arguments are really made for anything else. There is just a constant nonsense talk why to use git and git platforms. Developers seems to have got stuck in some mindset that everything needs to version controlled all the time, if you make a change or at least a couple you gotta have to make a git commit, or otherwise most of the benefits are lost anyway, but of course I don't really know how much of developers you really are. I don't care what the industry standard is for public development, I'm not making public development, I'm only making a public release here. Are you really saying that using a VCS isn't a pain in the ass? I do it because I most and when someone pays me to do it. Everyone is acting like it is just a natural piece in the workflow of any software project, I strongly disagree. It is in the way and causing extra job in every step on the way (or is everyone using a auto-commiter or a full blown CI/CD system for everything?). But that is the point when you develop something in group or for money, it has strong benefits then. Here I have time to develop it linearly and in my own pace and do all the testing I need. I don't need git as a CTRL+Z tool or as a unfinished feature branch tool. My text editor alone got me covered, I've trusted it with my life for over 10 years. I couldn't be happier and more productive with it than I already am. It might be simple to use git, but it is still extra, and in this case unnecessary extra. It literally doesn't give me anything. Why would I also setup a git provider account, even if it is one time, ssh keys are made in a split second but you got to manage them as well, add them to the provider website and take them with you where you want to develop. I got all that setup on private instances, I fully manage myself, I know exactly how everything of that works.
It is a fact that most software skip unit tests and functional tests, I don't believe it is good and neither do I brag about that I don't have that yet. This project doesn't need to be exposed to the public internet at all. You can run them perfectly fine in a own VLAN or something. I'm not saying anyone should run anything they aren't fully trusting. I would much rather be discussing design decisions or security concerns than why I'm not using git or have any unit tests yet. I know exactly how sensitive it is for software to run in someones infrastructure, and tools that could alter and manage that, and protect the traffic between the node and the endpoint. But then give something real critical of that and refer to the code or design and not just good practices. I know they are good and useful, but it is not everything. What matters is the code in the end. Don't run if you can't trust it because its lacking automated testing then. I don't care if I'm the only one ever using it, I created it for myself and it is solving a whole lof of issues no other tool or solution comes close to. I'm sharing it if anyone else is looking for something like this and maybe wants to just take a look on how I solved it when developing their own tools. I'm more than happy to help with setting it up or answering any questions related to it or the things it does