Skip to main content

Shuttle servers

experimental

Shuttle is an experimental feature of the Anapaya appliance. It was introduced in version v0.40.0.

Shuttle provides secure IP tunneling over SCION. It follows a client-server model: a Shuttle client establishes a tunnel to a Shuttle server, and the two ends route IP traffic over that tunnel. The main use case is the management of appliances over the SCION network. Typically, the managed appliance runs the client, and the managing party operates the server.

The two ends are configured in separate sections of the appliance configuration:

  • The server in the shuttle_servers section, described on this page. Each entry in shuttle_servers.servers creates a tunnel interface on which the connected clients are reachable.
  • The client as an interface in the interfaces.shuttles section, described in Network interfaces configuration.

A client can only connect if the server lists it under clients with the client's certificate as credential. For a step-by-step walkthrough of setting up both ends, including how to exchange the client credentials, see the Configure shuttle user guide.

Configuration reference

Anapaya appliance configuration (shuttle_servers only)

shuttle_servers object

The necessary configuration data for Shuttle servers on the Anapaya appliance.

servers object[]

The necessary configuration data for Shuttle servers on the Anapaya appliance.

  • Array [
  • addressip-prefix

    The IPv4/IPv6 address of the tunnel with a CIDR mask.

    advertised_routesip-prefix[]

    A list of IPv4/IPv6 addresses with a CIDR mask. The prefixes in the list are advertised to all connected clients. Subsequently, the clients route all traffic to these prefixes via the shuttle server. Must be in the same family as the tunnel address. If empty, it is by default equal to allowed_destinations. It must not be empty if shuttle traffic is NATed. Catch all are expressed as 0.0.0.0/0 (IPv4) and ::/0 (IPv6)

    allowed_destinationsip-prefix[]

    A list of IPv4/IPv6 addresses with a CIDR mask. The list indicates the networks that are reachable through the Shuttle server. All other destinations are disallowed. Must be in the same family as local tunnel address. The list is used to configure firewall forwarding rules on the appliance. Catch all are expressed as 0.0.0.0/0 (IPv4) and ::/0 (IPv6)

    clients object[]

    The list of Shuttle clients.

  • Array [
  • addressip-address

    The IPv4/IPv6 address that will be assigned to the client tunnel interface upon successful connection. Without CIDR mask. Must be in the same family as local tunnel address.

    credentialstring

    A base64 encoded string that is used to authenticate the client.

    disabledboolean

    Disable the Shuttle client. By default, it is false. If disabled, the corresponding Shuttle client cannot connect to this server.

    Default value: false
  • ]
  • endpointscion-port

    The endpoint address on which the server is listening for connection requests from Shuttle clients. In two alternative forms [ISD-AS,IP]:port, or IP:port, where ISD-AS is an ISD-AS number, IP is an IPv4/IPv6 address

    Example: 127.0.0.1:443
    mtuuint16

    The MTU (Maximum Transmission Unit) to be used on the shuttle interface. The user usually does not need to change this default value. The value is chosen to work in extreme circumstances.

    Default value: 1000
    namestring

    The name of the network interface.

  • ]
  • Loading...

    Addressing

    The tunnel address defines the subnet of the tunnel. Client addresses are assigned from it, and the prefixes in allowed_destinations and advertised_routes must be of the same address family.

    The name of a server must not collide with the name of any other interface on the appliance, including the Shuttle client interfaces configured in interfaces.shuttles.

    Non-overlapping address sets

    When configuring multiple servers on a single appliance, assign non-overlapping client address sets across the servers.

    Firewall and NAT

    The appliance installs the firewall rules that forward traffic from the tunnel interface to allowed_destinations automatically. Traffic that reaches the server on another interface and is destined for a client still needs an explicit accept rule in the firewall configuration, and translating client addresses towards other networks requires a NAT chain. Both are covered in the Configure shuttle user guide.

    To expose the management API over a Shuttle tunnel, add the tunnel interface to the management.api.interfaces section, see Management configuration.