Skip to main content

Using tuna in a corporate network

Most often there should be no problems with this, as corporate firewalls allow outgoing connections, however there may be restrictions on connection ports that may interfere with tuna operation.

If you encounter errors when creating a tunnel, run the tuna diagnose command to get diagnostic information. The report will help you better understand where exactly the problem is.

Please wait, testing connectivity...

TLS connectivity:
  Google.com: ok [1.46189625s]
  Yandex.ru: ok [1.246520375s]
  tuna API: ok [1.484186875s]
DNS:
  api.tuna.am: alt-lb.tuna.am. → eu-lb.tuna.am. [147.45.149.16, 194.31.173.118]
  a.2na.am: edge-eu-a.2na.am. [2.28.136.177, 89.19.217.251]
TCP connectivity:
  tuna edge a 2.28.136.177:443: ok [41.53925ms]
  tuna edge a 89.19.217.251:443: ok [38.112708ms]
  tuna node DE node-1-de.2na.am:443: ok [52.81425ms]
  tuna node RU node-1-ru.2na.am:443: ok [34.079541ms]

As a rule, tuna uses port 443 to connect to nodes when creating a tunnel. If the TCP connectivity checks fail, contact your network administrators to resolve the issue.

Which addresses to allow in the firewall​

tuna CLI connects to the API and to nodes on port 443. If your firewall only lets through allowed addresses, open access to:

  • api.tuna.am and my.tuna.am, the API and the dashboard: the CLI calls the API on every run;
  • nodes: the CLI connects to them when it brings up a tunnel;
  • cells, if tunnel addresses are opened from the same network: cells receive the traffic to tunnels and custom domains.

The table lists the addresses of nodes and cells. The addresses of api.tuna.am and my.tuna.am are not in it.

The current address list in JSON: https://api.tuna.am/v1/system/ips

Allow every address in the list, not just the ones that resolve from your office. api.tuna.am, my.tuna.am and the cell zones are served by GeoDNS, which returns different load balancers for Russia and for other regions. The DNS section of the tuna diagnose output shows where GeoDNS sent your network: the region is given by the last name in the CNAME chain. For example, edge-ru-a.2na.am. means Russia, and edge-eu-a.2na.am. means other regions.

The addresses are currently fixed. If they change, we will try to notify you by email in advance. Either way, the current list is always available from the API method, so you can check for changes yourself.

If your firewall supports FQDN-based rules, allow access by name, and you won't have to update the rules when the addresses change.

Fetching the addresses automatically​

The list is available from a public API method that requires no authorization:

curl -fsS https://api.tuna.am/v1/system/ips | jq -r '.ingress_cells[].ips[], (.nodes[].ip // empty)' | sort -u

The response has two arrays:

  • ingress_cells are cells. ips holds the addresses that receive traffic to tunnels, and zone is the cell's main zone, which CNAME records of custom domains point to. Take the addresses of all cells regardless of status: cells in the draining status still receive traffic.
  • nodes are nodes. address is the host and port the CLI connects to, ip is the node's address, and region is the node's country as an ISO 3166-1 alpha-2 code, such as DE. The ip and region fields may be missing. Without ip, allow access by the name from address.

The server refreshes the response every 5 minutes, so polling the method more often makes no sense. The method supports ETag: with the If-None-Match header it returns 304 if the list hasn't changed, which makes it convenient to check for changes on a schedule. The limit is one request per second from a single IP address; above it, the server responds with 429. The method is described in Swagger, tag SystemIPs.