Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

2984839

Cancelled
Original poster
Apr 19, 2014
2,114
2,241
A thread by @Dronecatcher on Google's rendering proxy reminded me that I wanted to try running Web Rendering Proxy on a server for my PowerPC laptops. WRP works by rendering the web page in Chrome/Chromium and creating a GIF or PNG with clickable elements. You could do this on your local network with a fast machine and access its RFC1918 address, but in my case, I wanted to run it on a remote server so I can access it from anywhere. The problem with this is that there seems to be no way to have a TLS connection to the proxy, and I don't really want the PNG/GIF begin sent in the clear to my client's browser, especially when I start submitting passwords and the like.

The solution I devised was to run WRP on a 2 core, 4 GB RAM Vultr OpenBSD VPS with a Wireguard VPN tunnel securing the connection. It actually works fairly well. I put a screenshot below of the full Macrumors site in Dillo on a titanium PowerBook:

09-19_screenshot.png


As you can see, Dillo on the PowerBook is making a plain HTTP connection to 10.1.2.1 which is the internal IP address of my Wireguard VPN, where WRP is listening on port 80. This whole connection is sent over the encrypted VPN tunnel, so it is still secure despite being HTTP. The toolbar at the top of the page has the controls for WRP. It's a bit weird in that you can only click in a web page. Entering text requires you to click in the form on the web page, fill in the field in the WRP control section (next to the "Bs" button, ironically) with the text you want, then submit by clicking WRP's Go button. Scrolling is done with the scrollbar as expected.

I strongly suggest setting the page height to 0. This will render the whole page as one big, scrollable image, though it has the downside of being a larger download. I also suggest using PNG if you can because it is faster than a GIF. I built in ad blocking by setting /etc/resolv.conf on the server to AdGuard's DNS. Lastly, make sure your server can run Chromium. I suggest 2 cores and 4 GB RAM at a minimum.

Performance is surprisingly good, even over a VPN tunnel. Another cool benefit of doing it this way is that you don't have to worry about snooping on an open wifi or WEP network if you're using an older Airport card like mine because the VPN takes care of that. I have no idea if it's possible to run Wireguard on older versions of OS X, but you could do this with any VPN.

If there's enough interest, I can work on a script that would automate almost all of this.

edit: Link to script is here: https://github.com/jsfierro/wrpguard
 
Last edited:
I've been looking for something like this! I've got a few servers at my house I could play around with this on. I'd be interested in your script as well. Also, have you heard of brow.sh before? it does something similar but it's for terminal clients. I've messed with it in the past and it workd pretty well http://www.brow.sh/
 
So here's a really basic script to run on the server that will basically duplicate my setup. It assumes an OpenBSD -current (6.8) server. I'll polish it more in a bit. Link to it on Github: https://github.com/jsfierro/wrpguard

Code:
#!/bin/sh
# This script will configure an OpenBSD -current (6.8)
# server with Wireguard and Web Rendering Proxy. It should be run as root.
#
# This script assumes the Wireguard server IP will be 10.1.1.1 and the
# client (peer) IP will be 10.1.1.2. Adjust these as you desire.
#
# Once wireguard-tools is installed, generate the private key with `wg genkey`
# Generate the public key with `echo privatekeygoeshere | wg pubkey`
#
# The private key will be placed in the /etc/wireguard/server.conf file we'll make.
# The public key will need to be supplied to the peer.
# Lastly, you'll need the peer's public key for that server.conf file too.
######################################################################

# Update existing packages, then install chromium and wireguard-tools
pkg_add -u
pkg_add chromium wireguard-tools

# Download and install WRP binary
ftp https://github.com/tenox7/wrp/releases/download/4.5.1/wrp-amd64-openbsd
install -m 755 wrp-amd64-openbsd /usr/local/bin

# Add a non-root user to run the WRP binary
useradd wrpuser

# Create wireguard interface. Modify the IP address as desired
touch /etc/hostname.wg0
cat <<EOF > /etc/hostname.wg0
10.1.1.1 255.255.255.0
!/usr/local/bin/wg setconf wg0 /etc/wireguard/server.conf
EOF

# Create wireguard conf directory and conf file. Allowed IP will be the client IP
mkdir /etc/wireguard
touch /etc/wireguard/server.conf
cat <<EOF > /etc/wireguard/server.conf
[Interface]
PrivateKey = pasteyourserverprivatekey
ListenPort = 51820

[Peer]
PublicKey = pasteyourclientpublickey
AllowedIPs = 10.1.1.2/32
EOF

# Configure firewall

cat <<EOF > /etc/pf.conf
set skip on { lo, wg }
int_ip = "10.0.0.0/8"

block drop      # block stateless traffic
pass in quick on egress proto tcp from any to egress:0 port 22
pass in quick on egress proto udp from any to egress:0 port 51820
pass in quick on 10.1.1.1 proto tcp from $int_ip to 10.1.1.1 port 80
pass out

block return in on ! lo0 proto tcp to port 6000:6010

block return out log proto {tcp udp} user _pbuild
EOF

# Use AdGuard DNS for adblocking
touch /etc/dhclient.conf
echo 'prepend domain-name-servers 176.103.130.130;' >> /etc/dhclient.conf

# Clean up
rm wrp-amd64-openbsd
echo 'Configuration done!'
echo 'Run `wg genkey` and paste the output into the PrivateKey section of /etc/wireguard/server.conf'
echo 'Run `echo privatekeygoeshere | wg pubkey` and provide the resulting public key to peer'
echo 'Add the peer public key to the [Peer] section of /etc/wireguard/server.conf'
echo 'Lastly, run `sh /etc/netstart` or reboot to apply all changes'

When all is done on the server and your client is connected, switch to the regular user, and run WRP from the server like so:

Code:
su wrpuser
wrp-amd64-openbsd -l 10.1.1.1:80 &

Then from your connected peer, point your browser to 10.1.1.1.
 
Last edited:
I've been looking for something like this! I've got a few servers at my house I could play around with this on. I'd be interested in your script as well. Also, have you heard of brow.sh before? it does something similar but it's for terminal clients. I've messed with it in the past and it workd pretty well http://www.brow.sh/

Don't know why but your post just appeared now for some reason. Anyway, if you are going to run this on your local network, you can skip the VPN stuff and it will be easier to get going. Just make sure WRP is listening on the external IP of your server and your firewall allows connections to it. The default listening port is 8080 but I just use port 80 to make it easier.
 
Hey 556fmjoe, this is awesome, thanks! I got it running it on an a cheap 1Gb / 1vCPU Vultr instance. Will see if I need to bump it up for more memory, chrome seems to enjoy ~550Mb with light pages.
 
Hey 556fmjoe, this is awesome, thanks! I got it running it on an a cheap 1Gb / 1vCPU Vultr instance. Will see if I need to bump it up for more memory, chrome seems to enjoy ~550Mb with light pages.

Great to hear, I will try it with a smaller instance later today. It does seem to use quite a bit less RAM than Chromium on the desktop. I suspect the UI is extremely bloated, and certainly multiple tabs is a big factor as well. I am wondering if the extra vCPU is useful at all here or if 1 is enough.
 
So, I worked on cleaning up the script a little and it has also been improved thanks to a helpful Github user's pull request.

I tested this on a 1 vCPU, 1 GB RAM Vultr High Frequency instance and it works fine, but heavy sites will consume 700+ MB of RAM and the CPU hits around 65%. It does work though, and this would probably be the floor in terms of server performance I'd accept. Just know that's a option if you want to save some money.
 
  • Like
Reactions: dextructor
Got it running on a local Fedora server 31 vm with 2 cpus and 2gb ram. Performance is pretty good, memory and cpu usage is similar to yours @556fmjoe.

Also i should add that only one device can realistically connect at once. Having multiple devices try to connect to the same server concurrently causes problems and page overlap. I did work around this by spawning another instance on another port, which i was then able to connect to from a different device. may seem obvious, but just thought i'd clear that up
 
Last edited:
  • Like
Reactions: 2984839
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.