`private-mode`/`lainos-private-sync`

Repositories: lainos-dns-mediation ~ lainos-private-sync

Automated orchestration script that manages the complete privacy stack lifecycle on lainOS. It coordinates network teardown, Tor bootstrap with Snowflake bridges, time synchronization via sdwdate, MAC randomization, and fail-closed kernel firewall enforcement into a single atomic sequence. This ensures that DNS resolution, package synchronization, and all other network traffic is transparently forced through Tor, eliminating any clearnet escape path.

State transitions are leak proof, as the script forces network interfaces down before activating Tor and confirms no active routes before re-enabling plaintext time sync.

Commands

private-mode on       # Force network down, enable Snowflake + sdwdate, bring WiFi/eth0 back up, activate fail-closed firewall
private-mode off      # Force network down, disable firewall, disable sdwdate, stop Tor
private-mode status   # Show current state of all components including firewall

Fail-closed Portage sync

Once private-mode is active, use demerge and drepo instead of raw emerge commands. The wrappers verify the kernel firewall is active before executing:

demerge --sync        # Sync Portage through Tor (refuses if firewall is inactive)
drepo sync            # Sync repo masters through Tor

What happens if you use raw emerge instead:

When private-mode is ON: Raw emerge will work because the kernel firewall forces all traffic through Tor automatically
When private-mode is OFF: Raw emerge will work but traffic goes clearnet (not through Tor)

What happens if you use demerge/drepo:

When private-mode is ON: They execute normally, routing through Tor via the kernel firewall
When private-mode is OFF: They refuse to run with an error message

The wrappers exist as a safety check to prevent you from accidentally syncing over clearnet when you intended to use Tor.

Why the ordering matters

on forces network down first: If WiFi/eth0 are already up when you run private-mode on, starting Tor/sdwdate would expose the first packets. The script forces the network off, confirms it's actually down, then starts the privacy stack.

off waits before disabling sdwdate: Disabling sdwdate switches back to chrony, which fires a plaintext NTP request immediately. If the network is still live during teardown, that request leaks. The script confirms no active default route before touching sdwdate.

firewall activates after Tor bootstraps: The kernel firewall (lainos-private-sync) only activates after Tor's DNSPort is listening. This prevents the firewall from redirecting traffic to a dead port. If the kernel lacks nftables NAT support, the firewall is skipped with a warning.

You'll be asked for your password once per direction (on or off), not once per sub-step.

Manual verification required

private-mode does not tell you when it's safe to proceed. After private-mode on, you must verify:

nyx                                # Wait for "Bootstrapped 100%"
lainos-sdwdate status
doas tail -20 /var/log/sdwdate.log # Confirm recent 'success' line
doas lainos-private-sync status    # Confirm firewall is ON

Only checking Tor's actual bootstrap state, sdwdate's actual sync log, and the firewall status confirms safety.

Firewall verification

To prove traffic is being routed through the kernel firewall:

doas watch -n 1 "nft list table ip lainos_private_sync_nat"

Run demerge --sync in another terminal. The redirect to :9040 counters should increase, proving the kernel is intercepting and redirecting traffic to Tor.

Bridge config behavior

private-mode off stops Tor directly via torctl st rather than disabling the Snowflake bridge config. The bridge config remains in place between sessions, which is harmless at rest since Tor is fully stopped. To remove the bridge config entirely, run snowflake disable separately.