Hello.
The Mikrotik web proxy features confuse me a bit, I want to configure it as a reverse proxy, so that when accessing host1.mysite.com and host2.mysite.com , it would show data from different local computers (e.g 192.168.0.2:81, 192.168.0:3:81, etc), (without being obvious to the visitor), so visitor remains on:
http://host1.mysite.com
http://host2.mysite.com
Can the web proxy do that ? What options should I look at ? Is it “web proxy direct” ?
I know Nginx can do that.
I use a HapAc2 for this case, I know performance might not be great, but I wanted to experiment with it a bit.
First part would not work for me because I have 4-8 hosts and not that many public IPs.
I didn’t understand what you meant in second part, maybe you can tell me differently.
The 2nd part: install a proper reverse proxy on one of internal servers (e.g. haproxy, nginx or apache) and configure it to forward requests to the rest of servers.
Use a function near all webserver have, host1.mysite.com read HTTP header and if the site wanted from browser (readed on HTTP_HOST header) is host2.mysite.com,
That's against OP's requirement that it should be hidden from clients. Additionally using non-standard ports may break things for some clients (some corporate firewalls are quite restrictive when it comes to uncommon/nonstandard ports).
Additionally, anything else than what I proposed doesn't work for encrypted connections (i.e. for https).
Addittionally one https webserver with latest technology can handle more https sites with various names, than one a time, using internal pipes to show websites located on another machine.
But that’s not the point, and it has nothing to do with mikrotik.
Redirecting stuff is complicating things and it is visible to user. For example: if server1 replies to both https://host1.example.com/ and https://host2.example.com/, it needs installed certificate which works for both FQDNs. Then if sole function of server1 for requests for https://host2.example.com/ is to serve redirect to e.g. https://host2.example.com:444/, then server2 needs certificate covering host2.example.com as well (doesn’t need to be the same certificate as on server1 though). But then all the softwares I mentioned are fully capable of performing reverse proxy, which means they will terminate TLS/SSL (using one or multiple certificates), forward requests to appropriate back end servers (using plain http or https, whatever more appropriate) and will pass replies back to original clients. All of that without exposing any backend topology details to clients. haproxy can even perform load sharing and/or high availability between backend servers serving same FQDN.
The point in exercise is this: if one runs multiple actual backend web servers, then using router to perform reverse proxy is … I’ll be blunt: stupid. You already have multiple machines capable of doing job properly, why bother making router do it (poorly)?
Do you tinker with your lawn mover to make it walk your dog? I don’t.
No I put a stake in the middle of the lawn and attach a goat by rope to the stake and watch it move around in ever decreasing circles cutting/eating the lawn, whilst I sit back in my lawn chair pounding down some Valmiermuiža ale and reading Mikrotik Switching with LABS by Maher Haddad!
Yes, I know how to do that part, I was hoping the Mikrotik web proxy function has a feature to use different local computers based on host in the request.
So Mikrotik doesn’t have this ?
That is how Nginx does it, and also can use different data sources based on the path requested (/images /downloads), etc, it is also a nice way to spread the load on server(s).
Unfortunately, ROS can’t do it, although I feel it would be a useful feature, especially in front of a DMZ. It wouldn’t need to be a full-fledged HTTPS application proxy, just SNI-based firewall-routing would be enough to pipe the traffic to the right internal host (although you can’t use directory-based routing then). The funny part is that ROS already contains an option for SNI-based filtering, but the SNI information isn’t available in the first SYN/ACK-handshake, and that’s why that feature is only useful for blocking, but not for routing.
IPv6 might make the whole issue obsolete, though, as we are mainly just talking about ways on how to share a single public IP to multiple internal ones. If you have multiple public IPs for your servers, it suddenly turns into a non-issue.
