Colocation Cross-Connect Turnup Checklist on Debian 12

Start with the turnup plan, not the cable

If your server is already in a rack, the first live cross-connect is usually the point with the most risk. A colocation cross-connect checklist keeps the handoff controlled: you confirm the port, verify the switch path, test addressing, and only then move production traffic. This tutorial uses Debian 12 because it is still a common, stable choice for colocated servers in 2026, and it fits the least-covered OS track for this run.

Hostperl customers usually reach this stage after a migration, a hardware refresh, or a new carrier turnup. If you are building the rest of the stack around hosted infrastructure, a dedicated server hosting plan can complement colocated hardware for secondary services, staging, or backup nodes. This guide stays on the operations side: what to verify before you accept the circuit as live.

What this checklist covers

You will take a fresh Debian 12 server from first SSH access to a validated network turnup. The goal is not just “link up”; it is a documented handoff with routing, firewall, and rollback steps in place.

• Confirm Debian 12 and baseline network state.
• Create a non-root sudo user and secure SSH access.
• Inspect interface naming, IP addressing, and default route.
• Validate the colocation cross-connect path with live tests.
• Harden firewall rules without locking yourself out.
• Record failure checks for carrier, switch, and routing issues.
• Prepare rollback actions if the new path behaves poorly.

1) Connect and identify the operating system

On your local computer, open the first SSH session using the reserved documentation IP shown below.

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with the real public IP assigned to your colocation host. Keep this root session open until the new non-root login is verified.

Once connected, confirm the OS version.

On the VPS as root, run:

cat /etc/os-release

You should see Debian 12 details such as ID=debian and VERSION_CODENAME=bookworm. If the server is not Debian 12, stop and adjust the package commands before you continue.

2) Create a non-root admin and test SSH safely

Colocation servers are easier to support when daily work happens from a named admin account. Debian uses the sudo group.

On the VPS as root, create the user and grant sudo:

adduser deploy
usermod -aG sudo deploy

Set a strong password when prompted. If you use SSH keys only, you can still keep the password locked later, but do not do that until SSH key login works.

Create the SSH directory and key permissions for the new account:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

If you do not already use root authorized keys, copy your public key into /home/deploy/.ssh/authorized_keys manually with nano or vim. Keep the permissions strict: 700 for the directory and 600 for the file.

Now open a second terminal and test the new login before changing root access.

On your local computer, run:

ssh deploy@203.0.113.10

Again, replace 203.0.113.10 with your server's IP. If the login succeeds, confirm sudo works:

On the VPS as the non-root sudo user, run:

sudo -v
whoami
pwd

You should see deploy for whoami and your home directory for pwd. Keep the original root session open until this is confirmed.

3) Update the server and install the network tools you need

Before you trust the cross-connect, bring the system current and install diagnostics. On Debian 12, use apt.

On the VPS as the non-root sudo user, run:

sudo apt update
sudo apt -y full-upgrade
sudo apt -y install iproute2 iputils-ping traceroute dnsutils curl ethtool nftables netcat-openbsd tcpdump

These packages give you route inspection, packet tests, DNS lookups, interface statistics, and firewall control. A successful run ends without package errors.

Check the kernel and interface inventory:

uname -r
ip link show
ip addr show
ip route show

You should see the active Ethernet device, its IP address, and a default route pointing at the colocation gateway or upstream router.

4) Verify the physical and logical cross-connect

This is where a colocation cross-connect checklist earns its keep. You are checking that the handoff is not only plugged in, but actually carrying the expected traffic path.

On the VPS as the non-root sudo user, inspect the link state and negotiated speed:

ip link show enp1s0
sudo ethtool enp1s0

Replace enp1s0 with your actual interface name from ip link show. Look for Link detected: yes and the expected speed, such as 1Gb/s or 10Gb/s. If the link is down, the issue is usually physical, patch-panel, or switch-port related, not Linux.

Run a local gateway ping and a route check:

ping -c 4 203.0.113.1
traceroute -n 203.0.113.1

Use your real gateway or upstream address in place of the example. If the gateway does not answer, ask the colo provider or remote hands to confirm the patch-panel path and switch port status.

For a deeper packet check, watch traffic while you generate pings:

sudo tcpdump -ni enp1s0 icmp

In a second terminal, run the ping again. You should see echo requests and replies. If you only see outbound packets, the return path is broken.

5) Record the addressing and routing state

Documenting the live network state helps when support or remote hands need to compare notes. Save this output in your change record.

On the VPS as the non-root sudo user, run:

ip addr show enp1s0
ip route show
resolvectl status 2>/dev/null || cat /etc/resolv.conf

Check that the assigned IPv4 address, prefix length, and default route match your handoff sheet. If you also use IPv6, confirm the IPv6 address and the router advertisement or static gateway are present.

When the route looks wrong, compare the config with the interface file. Debian 12 commonly uses /etc/network/interfaces or NetworkManager depending on how the server was built. If your host uses ifupdown, inspect it with:

sudo cat /etc/network/interfaces

If the address or gateway is wrong, fix it in the correct file, then apply the change during a maintenance window. Do not guess. A bad gateway can isolate the box from the colo switch immediately.

6) Add firewall rules without cutting off SSH

On a colocated server, firewall work should be conservative. Add the new rule before removing any old one. Debian 12 works well with nftables.

On the VPS as the non-root sudo user, open the rules file:

sudo nano /etc/nftables.conf

Replace the file contents with this baseline that allows SSH, ping, established traffic, and then your service ports if needed:

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    ct state established,related accept
    iif lo accept
    ip protocol icmp accept
    ip6 nexthdr ipv6-icmp accept
    tcp dport 22 accept
    tcp dport 80 accept
    tcp dport 443 accept
    counter reject with icmpx type port-unreachable
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}

Save and exit the editor. Then test the syntax before reloading.

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable nftables
sudo systemctl reload nftables
sudo nft list ruleset

You should see no syntax errors and a loaded ruleset. If SSH is on a nonstandard port, allow that port before you drop the old rule. Never close the working terminal until the new path has been tested from a second session.

For server operators who prefer UFW on smaller Debian hosts, the safer sequence is the same: allow the new service port first, test, then tighten. The command set differs, but the lockout risk does not.

7) Lock down SSH after the new login works

Once the deploy account logs in cleanly, you can harden SSH. This is a good time to disable password login if your environment uses keys only.

On the VPS as the non-root sudo user, open the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Add or confirm these lines:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Save the file, then test syntax before reload:

sudo sshd -t
sudo systemctl reload ssh

On Debian, the service name is usually ssh. Keep the root session alive until a fresh login from your local machine succeeds with the new rules.

8) Smoke-test the cross-connect from both ends

Good turnup work checks both the server and an external client. On the server, confirm the listening state and packet counters.

On the VPS as the non-root sudo user, run:

ss -tulpn
sudo nft list ruleset
journalctl -u nftables -n 20 --no-pager
journalctl -u ssh -n 20 --no-pager

You should see SSH listening, the firewall loaded, and no repeated authentication or binding errors.

On your local computer, run:

ssh deploy@203.0.113.10
ping -c 4 203.0.113.10
curl -I http://203.0.113.10

Replace the IP with the real public address. If you have a web service on the server, curl should return an HTTP status. If you only expose SSH, the ping and SSH checks are enough for a network turnup smoke test.

9) Troubleshoot the most likely failures

Most colo handoff problems fall into a small set of patterns. Use the command first, then the clue, then the correction.

• No link light or Link detected: no: run sudo ethtool enp1s0. If the link is down, ask remote hands to reseat the patch lead or verify the switch port.
• Wrong gateway or no default route: run ip route show. If the default route is missing, correct the network config and reapply it during the maintenance window.
• Ping works but HTTPS fails: run sudo nft list ruleset and ss -tulpn. If the firewall blocks 443 or the service is not listening, open the port and start the service.
• SSH login fails after hardening: run sudo sshd -t from the root console session or out-of-band access. If the config is invalid, revert the last change and reload SSH only after syntax passes.
• Packet loss on the colocation path: run sudo tcpdump -ni enp1s0 icmp while pinging. If requests leave but replies do not return, escalate to the carrier or colo operator with timestamps and packet captures.

10) Roll back safely if the new turnup misbehaves

If the cross-connect is live but unstable, reverse only one change at a time. Restore the previous firewall rules first, then SSH hardening, then network configuration if necessary.

On the VPS as the non-root sudo user, keep a rollback copy of each config before you edit it. For example:

sudo cp /etc/nftables.conf /etc/nftables.conf.bak.$(date +%F)
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)

If you need to revert, restore the file and reload only after a syntax check. That sequence matters more than speed.

Final verification and service readiness

A complete colocation turnup ends with confirmed persistence. Reboot the server, then verify the network comes back without manual fixes.

On the VPS as the non-root sudo user, run:

sudo systemctl status nftables --no-pager
sudo reboot

After the server returns, reconnect from your local computer:

ssh deploy@203.0.113.10

Then confirm the firewall, interface, and route again:

ip addr show enp1s0
ip route show
sudo nft list ruleset

If those checks pass, your colocation cross-connect is ready for production traffic.

For operators who want to pair colocated hardware with elastic services, Hostperl VPS hosting is a practical secondary layer for backups, monitoring, or staging. If you are planning the next procurement cycle, the colocation cross-connects and remote hands guide and the rack planning for 10/25GbE growth article are useful follow-ups for capacity and carrier planning.

FAQ

How do I know the cross-connect is live?
Check link state with ethtool, confirm a valid route with ip route show, and test traffic with ping and tcpdump. You want link, route, and packet return all working.

Should I enable the firewall before or after testing?
Enable it after you have confirmed SSH access and allowed the new ports first. That sequence avoids self-inflicted lockouts.

What if my provider uses a different handoff address?
Replace the example gateway and IP values with the details from your colo turnup sheet. The commands stay the same.

Can I use UFW instead of nftables on Debian 12?
Yes, but use one firewall system consistently. Do not mix UFW and nftables rules unless you understand how they interact on your host.

What should I send support if the port stays down?
Send the server IP, switch port label, patch-panel reference, test timestamps, and the output of ethtool, ip addr show, and ip route show. That shortens the remote-hands loop.