Skip to content

RTFM · Networking

Remote public servers

A remote Saphira host may have public addresses directly, but public reachability never removes the need for host firewalls and careful service separation.

Saphira Linux dragon mascot

Direct public addressing

In a datacentre or VPS, the server's interface may hold a public IPv4 address and one or more IPv6 addresses. There may be no port forwarding step. The provider's network firewall, the host's nftables policy, and the service listener all need to agree.

Remote checks
ip addr
ip -6 addr
ip route
ip -6 route
ss -lntup
sudo nft list ruleset

Build a business edge in a safe order

A business deployment earns its reliability from sequence. Create the layer-2 VLANs and routed gateway interfaces first. Give each one an IPv4 subnet and IPv6 /64. Establish DHCP/RA/DNS for clients, then write a default-deny forwarding policy with specific business flows. Only after private routes work should you publish HAProxy, MailDragon, webDragon, or authoritative DNS at a public edge.

  1. 1. Inventory physical and virtual ports

    Record switch trunk/access membership, OVS bridge/port membership, VM vnet interfaces, interface names, and uplinks. A VLAN tag mismatch looks like a DHCP or firewall failure until you inspect the port.

  2. 2. Create the address and DNS plan

    Allocate a unique IPv4 subnet and IPv6 /64 to every zone. Define gateway, DHCP range, reservation space, resolver, and internal DNS suffix. Do not reuse a branch's private range at head office.

  3. 3. Route only declared flows

    Use nftables forward rules for users to application ports, servers to DNS/NTP/package mirrors, management to administration ports, guests to Internet only, and the public edge to its named backend ports.

  4. 4. Keep public and private names intentional

    Public DNS resolves Internet services to public addresses. Internal DNS may resolve private services to their private addresses. Make the resolver choice explicit in DHCP, RA/RDNSS, and VPN configuration.

  5. 5. Test failure isolation

    Prove that a guest cannot reach management, a user cannot reach database administration, and public traffic cannot bypass HAProxy. A design is not complete because the permitted path works.

Business service separation
Internet
   │
public IPv4 / routed IPv6
   ▼
Saphira edge: nftables + HAProxy
   │ public edge VLAN (192.168.50.0/24, 2a02:8012:bc57:50::/64)
   ▼
server VLAN (192.168.20.0/24, 2a02:8012:bc57:fead::/64)
   ├── MailDragon
   ├── webDragon
   └── internal DNS/monitoring

management VLAN/VPN → SSH, backups, automation only

Protect management first

Before enabling public services, allow SSH or another management path from a known address or through a management VPN. Keep a provider console or recovery path available. Do not lock yourself out by replacing rules remotely without a tested rollback plan.

A public address is not a security policy. An unfiltered IPv6 address is especially easy to expose accidentally because no IPv4-style NAT is hiding it.

Provider edge, host edge, and service edge

A hosted deployment can have three independent filters. The provider security group or network firewall may drop traffic before it reaches the VM. nftables on Saphira may drop it next. HAProxy, Nginx, Postfix, or Dovecot may then reject a connection that reached the host. Record the owner of each layer so an outage is not escalated to the wrong place.

  1. 1. Record allocated addresses

    Record the exact public IPv4, IPv6 address or routed prefix, provider gateway, provider firewall policy, and reverse-DNS control path. These are provider facts, not values inferred from an application log.

  2. 2. Make a private management route

    Prefer a WireGuard management VPN or a narrow source allow-list for SSH. Confirm it works before reducing public management exposure.

  3. 3. Publish only named services

    Bind HAProxy/webDragon/MailDragon deliberately, add host firewall rules, then add matching provider rules. Avoid broad 'all TCP/UDP' provider openings just to make a test work.

  4. 4. Verify externally and preserve evidence

    Use a separate remote network, provider flow logs where available, nftables counters, ss, and tcpdump. Test IPv4 and IPv6 as separate paths.

Remote-host proof sequence
# On Saphira: distinguish route, listener, firewall, and name.
ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
ss -lntup
nft list ruleset
dig A www.example.test +short
dig AAAA www.example.test +short

# From a remote administration host you control.
ssh -vv admin@203.0.113.25
curl -6 -v https://www.example.test/
  • Provider firewall has no matching IPv6 rule: IPv4 may work through an IPv4-specific rule while IPv6 times out before Saphira sees a packet.
  • Saphira has a listener only on 127.0.0.1 or a private interface: the provider may deliver packets correctly but ss reveals the service cannot accept them publicly.
  • PTR panel is not available: ask the provider which public address is actually used for outbound SMTP and request PTR delegation or a PTR change; do not point a public A record at an unrelated address and call it reverse DNS.
  • Lost SSH after a firewall change: use the provider console/recovery system, restore the known-good rule, validate with nft -c, and retry with a separate management path.