Skip to main content

Networking

There are two primary networks on srv

  1. The locally accessible network (LAN) 10.0.0.0/24 10.0.0.0 - 10.0.0.253 Gateway: 10.0.0.254

You can use the Wireguard VPN to connect and access this local network on your own machine. See Connecting via WIreguard VPN

Currently there is no local IPv6 bridge as it isn't strictly necessary.

  1. The publicly addressable network (WAN)

136.243.40.234/26 2a01:4f8:212:8d2::2/64 (IPv6) Gateway: 136.243.40.193 Gateway: fe80::1 (IPv6)

IPv4​

We have a single publicly addressable IPv4 address which is assigned to the host system. The host system then runs a bridge, vmbr1 in the 10.0.0.0/24 CIDR range. The host system uses 10.0.0.254 and serves as the default gateway for the network, and then each individual VM is allocated a /32 within the range for internal networking purposes.

IPv6​

While we are allocated a /64 IPv6 subnet from Hetzner at this time networking is not configured internally for its use, which is unfortunate but it is a low priority given so few residential homes have IPv6 configured.

HTTP(S)​

As we only have one publicly addressable IP, that also means we only have one 80:443 pair, for this reason we run a single reverse-proxy and webserver in the form of nGinx which all HTTP(S) traffic must be served from, in certain cases wildcard HTTP routing is used, passing traffic to a secondary nginx server hosted within a VM, such as in the case of An Scéalaí.

VPN (Wireguard)​

To aid in setting up various services without having to expose them to the general internet, as well as to provide access to internal services (such as MongoDB or Postgres, which we don't expose to the internet as a general rule) we have a Wireguard VPN which runs on 10.0.0.4/32 providing access to the internal network. The Wireguard server runs on a nonstandard port, 123 (often used for the Network Time Protocol) so as to avoid undue filtering of VPN traffic done by certain firewalls.

Access to the Wireguard VPN is by request, as not all researchers will need access to it.

See WireGuard VPN for more details on getting connected.

TURN​

We needed a TURN Server to relay audio when direct peer‐to‐peer paths failed. Our client sent audio to the dictation API on the Vosk server in the Recognition VM, and the TURN server—hosted via coturn on the Webserver VM—ensured the media streamed reliably through restrictive NATs.