By Russell Brown

About a year ago, I decided to set up a unity asset cache at home, for use when I was working there.

It turned out to be a good decision, and I continue to use it to this day.

Chug chug chug...

Chug chug chug…

Setting up the asset cache is not the subject of this article, however. You can read about that in Unity’s documentation.

This article concerns solving a problem I encountered when trying to get the transition from office to home working smoothly with my new asset cache server.

The problem is that you configure the asset cache server in Unity to a specific IP address:

fakingsubnets002

Chances are, the IP address of the server your cache is running on in the office won’t be the same as the IP address of the server you’re using at home. If they are the same, great! You don’t have this problem.

Furthermore, your local network at home may not even be using the same subnet. If you are, this problem is a little easier to solve. This article assumes you’re not using the same subnet.

Let’s say that at the office, your cache server is on 192.168.5.50, while at home the server is on 192.168.1.10.

There are probably a number of different ways to solve this problem. The most obvious is this:

fakingsubnets003

Just change the setting when you go home, and change it back when you’re back in the office! What could be more simple? Yeah, but I’m a programmer, and I don’t like repeating myself when I could automate a task with a little effort up front.

What I want is to be able to switch between the office and home, and for it to “Just Work” without any effort from me.

The solution I went with was to add a virtual IP address on my server, and a route on my router to forward requests on the other subnet to my server.

Here’s where we’re starting from:

fakingsubnets004

My laptop knows that it should go to the router for everything, so it sends the request intended for 192.168.5.50 to the router. But the router doesn’t have any route for that address, so it just fails.

We need to add a static route on the router so it knows where to send this request. Now, all routers are different, but here is an example from an ASUS router (LAN -> Route):

header_router

We’re telling the router that requests for addresses that start with 192.168.5 should be sent to 192.168.1.10 (it is assumed at this point that the server’s IP address is static: if it isn’t, this isn’t going to work reliably).

So is that it? Well, not quite. Now we have this situation:

fakingsubnets006

The request is now being sent to the correct server, but the server rejects the request because the IP doesn’t know what to do with it. That is to say, it knows it’s not for itself, and it doesn’t have anywhere further to which it should be routed.

So, we need to configure the server to accept requests to 192.168.5.50.

This is where this article becomes very platform-specific. My server runs Linux (Ubuntu 16.10, specifically). If your server is another OS (e.g. Windows or OSX), the steps are going to be different, but the outcome should be the same.

The trick here is to add a virtual interface on the machine’s existing physical interface. This is done in /etc/network/interfaces

The first step is to identify the primary physical interface (if you have multiple, you need the one that will be receiving requests from the router). For example:

# The primary network interface
auto br0
iface br0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    broadcast 192.168.1.255

Note the name of the interface (in this case, br0). Yours may be something different, such as eth0.

Now, add a section beneath that which defines the virtual interface (using the same base name as the primary interface):

# Virtual interface pretending to be the office
auto br0:0
iface br0:0 inet static
    address 192.168.5.50
    netmask 255.255.255.0
    network 192.168.5.0
    broadcast 192.168.5.255

This creates a virtual interface for the address that we need, leading to this happy situation:

fakingsubnets007

I had to reboot my server in order for this to work, but once I did, I was able to connect to my Unity Cache Server at home via the same IP address as the office server without having to reconfigure Unity.