Having some kind of central "meta server" or "locator server" is pretty standard practice, and they are pretty generic and straightforward (even though entire middleware solutions, such as GameSpy, used to be popular in the early days of internet gaming).
A locator server just maintains a list of known active game servers that can accept connections, probably in a very simple database table (or entirely in-memory if you really want to be simple). Consequently:
A game server, when it starts up, will send a message to the locator server with some basic information about itself, such as the IP and port it's running on, how many players spots are available for joining, and what the gametype (if applicable) is.
The game server will send a "close game" message when it either fills up or is cancelled. The locator server should probably also time-out entries as well, to handle cases where the game server just crashed outright.
A game client can then request, from the locator server , the list of all games. Often this list is refreshed from the server every few seconds while the player is on the "join a game" screen in the client.
At the bare minimum, that's all a locator server needs to do. When a player elects to join a listed game, the client can attempt a direct connection to the server using the information reported from the locator server -- you don't need to shuffle state between the two by way of the locator at all.
However, a locator server can be useful to act as a third-party in NAT punch-through (alternate explanation) scenarios as well, which does involve transferring more information between the locator as a third-party, though never full game state.
You could use it to pass through complete game state updates and act as a proxy, although in that case while the locator itself is still very straightforward to implement, it's potentially moving a lot more data around and that won't scale as well to a larger number of clients and servers. If that's what you're after (effectively avoiding the need for the game client and game server to ever talk directly), then you'll probably want to additionally have the locator server responsible for talking to a bunch of proxy servers you run. Each of these proxy servers exist solely to act as the intermediary for communication between a game client and server, which never talk directly. The proxies also must periodically communicate with the locator some information about how many games they are managing, for load-balancing purposes.
The game client and server still use the locator server to establish an initial connection, but the locator immediately negotiates with which proxy is least-loaded at the time and messages are sent to the game client and server to "talk to proxy 32" (or whichever). The game client and server will then use proxy 32 (or whichever) to rely communication about game state updates and so on, until the game ends.
It's quite likely your game won't be high-traffic enough to actually warrant needing a whole fleet of proxies, but if you do intend to avoid having a direct communication between the client and server for some odd reason (which seems unnecessarily complex), you should probably at least design the locator and proxying aspects of the intermediate server as separate. Just in case.
You don't want to have your game become suddenly popular, and then have your network infrastructure fall over when the surge of new players happens.