Building a Secure Mining Infrastructure with GRIDNET Core’s DMZ Architecture

PauliX · December 8, 2024, 1:38am

Building a Secure Mining Infrastructure with GRIDNET Core’s DMZ Architecture

Note: this article covers advanced Operating topics for multi-node setups (operating/mining farms). For novice Operators it’s best to see this first.

The Challenge of Mining at Scale

Imagine you’re running a successful mining operation with multiple GRIDNET Core nodes. Everything seems perfect until suddenly, your nodes start getting banned from the network. What’s happening? Welcome to one of the most interesting intersections of security and scalability in blockchain networks.

GRIDNET Core implements sophisticated anti-DDoS protection that automatically tracks and limits connections from individual IP addresses. If multiple connections are detected from the same IP, the system’s self-defense mechanisms kick in, resulting in a 30-minute (or longer) ban. While this protection is crucial for network stability, it creates a unique challenge for legitimate mining operations running multiple nodes.

Understanding the Situation

Let’s break down the problem:

Each mining node typically needs network connectivity to:

Receive new blocks
Submit mined blocks
Maintain blockchain synchronization
Participate in network consensus

When multiple nodes operate from the same network:

They may share the same external IP
Each attempts independent connections
The network sees multiple connection attempts
Anti-DDoS triggers activate
Result: All your nodes get banned

This creates a serious dilemma: How do you scale your mining operation without triggering network protection mechanisms?

Understanding Public and Private IP Addresses in Your DMZ Setup

Network addressing plays a crucial role in properly configuring your GRIDNET Core DMZ architecture. Let’s understand the distinction between public and private IP addresses and how they affect your setup.

IP Address Types

Private IP addresses are used within local networks and typically fall into these ranges:

192.168.0.0 to 192.168.255.255
172.16.0.0 to 172.31.255.255
10.0.0.0 to 10.255.255.255

Public IP addresses, on the other hand, are globally routable over the internet and must be unique worldwide. In our example, 203.0.113.10 represents a public IP address.

Checking Your Network Configuration

GRIDNET OS provides the ifconfig command to inspect your network configuration. Here’s how to interpret the output:

$ ifconfig
 
[Auto-Detected settings]:
Local IP: 192.168.1.1 Public IP: 203.0.113.10
NAT: Your node is openly accessible.

This header section immediately tells you:

Your node’s position in the local network (192.168.1.1)
Your public internet presence (203.0.113.10)
NAT status and accessibility

The command also shows detailed interface information:

[Virtual Interfaces]:
lo:          # Loopback interface for local communications
eth0:        # Primary network interface  used for communication with external world.- usually it has your public IP address assigned. That interface is used for QR codes and the internal web-server.
eth1:        # a virtual network interface having private IP address assigned.

Note: you may run ifconfig -help to see a detailed built-in MAN page with all the settings.

DMZ Configuration Implications

For our DMZ architecture, this dual-addressing has important implications:

DMZ Node:

Accessible externally via its public IP (203.0.113.10)
Available to internal miners via local IP (192.168.1.1)

Mining Nodes:

Must connect to DMZ using local IP: net -boot 192.168.1.1 -only
Faster, more reliable local network communication
Reduces unnecessary routing through external network

This dual-addressing setup provides both security and efficiency: external nodes connect through the public IP, while your mining nodes benefit from direct local network speeds and security.

Remember to regularly check your network configuration with ifconfig to ensure both your public and private networking remain properly configured. The command’s output provides valuable information about your node’s network status and can help diagnose connectivity issues.

The DMZ Node Solution

GRIDNET Core’s developers anticipated this challenge and implemented an elegant solution through the -boot -only command combination. This feature allows operators to create what security professionals call a DMZ (demilitarized zone) architecture. Let’s visualize this:

This diagram shows:

DMZ Node Configuration:

Public IP: 203.0.113.10 Private IP: 192.168.1.1 (pay attention that nodes in private sub-net connect to DMZ node through its private IP address)
Both UDT and QUIC enabled for maximum compatibility
Acts as bootstrap node for internal network

Protected Miners:

Internal IPs: 192.168.1.101-103
Restricted to DMZ node only
No external connections allowed

Configuration Flow:

Step-by-step command sequence
System verification steps
Network isolation verification

How It Works

The DMZ architecture creates a secure, hierarchical network structure:

The DMZ Node

Acts as a sentinel at the network boundary
Maintains connections with the public GRIDNET network
Handles all external communication
Filters and forwards essential data to internal miners

Protected Mining Nodes

Connect exclusively to the DMZ node
Never expose themselves to the public network
Focus purely on mining operations
Maintain optimal security posture

Configuration Steps in Detail

Setting up your DMZ architecture requires careful configuration of both the DMZ node and protected miners. Let’s walk through each step, ensuring optimal network stability and security.

DMZ Node Configuration

The DMZ node requires specific setup to serve as your network’s gateway:

# 1. Enable QUIC system (recommended default)
net -quicSystem on

# 2. Allow connections from all nodes
net -all

# 3. Optional: Enable UDT if behind NAT
net -udtSystem on   # Only if NAT traversal is required

A note about UDT: While GRIDNET Core maintains the UDT subsystem, it’s disabled by default for good reasons. UDT offers excellent NAT traversal capabilities and can increase connectivity in challenging network environments, but it comes with stability trade-offs. Consider enabling UDT only if you’re operating behind NAT and experiencing connectivity issues with QUIC alone. The QUIC protocol offers superior stability and is the recommended choice for most deployments.

Protected Miner Configuration

For each mining node in your protected network:

# Restrict connections to DMZ node only
net -boot 192.168.1.1 -only

This single command achieves multiple security objectives:

Restricts the miner to communicate only with your DMZ node
Prevents external network exposure
Maintains a stable, controlled connection path

Verification Steps

After configuring both DMZ and mining nodes, verify the setup:

# Check system status
net -info

# Verify connections
net -connections

# Monitor for warnings
# Use Event View (CTRL+W) for real-time monitoring

The DMZ node should show multiple external connections while each mining node should display a single, stable connection to the DMZ node. If you’ve enabled UDT for NAT traversal, monitor its stability through the Event View, and be prepared to adjust your configuration if needed.

Remember: Your DMZ node acts as the sentinel for your entire mining operation. Its correct configuration is crucial for both security and performance. Always prioritize QUIC for its stability, and consider UDT only as a fallback option when network conditions require its NAT traversal capabilities.

This architecture isn’t just about avoiding bans—it’s a comprehensive security solution that provides multiple benefits:

Security Benefits

Reduced Attack Surface

Only one node exposed to public network
Internal nodes protected from direct attacks
Controlled information flow
Enhanced monitoring capabilities

Network Optimization

Centralized chain synchronization
Reduced external bandwidth requirements
Optimized internal communication
Better control over network resources

Operational Advantages

Simplified troubleshooting
Centralized management
Easier network monitoring
Improved scalability

GRIDNET Core DMZ Setup Verification Guide

1. DMZ Node Verification

First, verify the DMZ node’s configuration:

# Check network subsystem status
net -info

Expected output:
[ Network Sub-systems Status ]
[ UDT System ]: enabled
[ UDT Synchronization ]: enabled
[ QUIC System ]: enabled
[ QUIC Synchronization ]: enabled

Check network subsystem status

net -info

Expected output:

[ Network Sub-systems Status ]
[ UDT System ]: enabled
[ UDT Synchronization ]: enabled
[ QUIC System ]: enabled
[ QUIC Synchronization ]: enabled

Display comprehensive connection report

net -connections

Expected output should show:

[ Comprehensive Connection Report ]
- External connections from public network
- Inbound connections from mining nodes (192.168.1.101-103)

note, you can also use firewall command to see status of the internal security sub-systems.

DMZ Node Test:

# Verify proper two-way communication
net -info
net -connections

Should show:
- Active connections with public network
- Active connections with mining nodes
- No connection warnings or errors

Mining Node Test:

# On each mining node
net -connections

Should show:
- Single stable connection to DMZ
- No pending external connection attempts
- No connection warnings

Troubleshooting Commands

If issues are detected:

Reset problematic connections:

net -all // restore connections with all nodes
net -boot 192.168.1.1 -only // restore connectivity only with a select node

Verify DMZ node availability:

# From mining nodes
net -connect 203.0.113.10 // enforces connection attempt with select node

Check complete system state:

net -info

Protocol Management and System States

System Configuration States

When managing your DMZ architecture, it’s important to understand that some configuration changes require a Core restart to take effect. The system uses a pending state mechanism to track these changes:

# Check current state including pending changes
net -info

Possible states:
[ UDT System ]: enabled/disabled/pending
[ QUIC System ]: enabled/disabled/pending

Protocol Control Commands

Full protocol control is available through these commands:

Transport Layer Control:

# UDT System Control
net -udtSystem on    # Enable UDT transport
net -udtSystem off   # Disable UDT transport

# QUIC System Control
net -quicSystem on   # Enable QUIC transport
net -quicSystem off  # Disable QUIC transport

Synchronization Control:

# UDT Sync Control
net -udtSync on      # Enable UDT synchronization
net -udtSync off     # Disable UDT synchronization

# QUIC Sync Control
net -quicSync on     # Enable QUIC synchronization
net -quicSync off    # Disable QUIC synchronization

DMZ Node Connection Management

When establishing connections, you can specify the protocol:

# Force QUIC connection
net -connect 203.0.113.10 -quic

# Force UDT connection
net -connect 203.0.113.10 -udt

# Default (QUIC) connection
net -connect 203.0.113.10

Implementation Notes

State Changes:

Core will notify when restart is required
Pending changes are visible in status reports
Multiple changes can be queued before restart

Protocol Coherence:

Disabling a transport system automatically disables its synchronization
Enabling synchronization requires corresponding transport system
At least one protocol must remain enabled

Example verification sequence:

# 1. Check current state
net -info

# 2. Make changes
net -udtSystem on
net -quicSync off

# 3. Verify pending changes
net -info
# Look for "pending" status

# 4. Restart Core when convenient
# 5. Verify final state
net -info

Final Words: Vigilance in Network Security

In the ever-evolving landscape of blockchain networks, security isn’t just about setting up defenses - it’s about maintaining awareness. GRIDNET Core’s Event View (accessible via CTRL+W) serves as your mission control center, providing real-time insights into network activities and potential threats. While the DMZ architecture significantly enhances your mining operation’s security, it’s the Core’s sophisticated monitoring and alert system that completes the security picture. The system works tirelessly, analyzing connection patterns, detecting suspicious activities, and identifying potential collusion attempts, keeping you informed every step of the way.

Think of GRIDNET Core as not just a piece of software, but as your vigilant partner in maintaining network integrity. Whether it’s warning about suspicious connection patterns from specific IPs or raising alerts about potential DDoS attacks, the system’s proactive approach to security demonstrates the developers’ commitment to creating a truly resilient network. This combination of architectural security through DMZ configuration and real-time monitoring capabilities makes GRIDNET Core stand out in its approach to network defense.

Remember, in the world of blockchain, security isn’t a destination - it’s a journey. By leveraging these tools and maintaining vigilance through regular monitoring of the Event View, you’re not just protecting your mining operation; you’re contributing to the overall resilience of the GRIDNET ecosystem. After all, our network’s strength lies not just in its code, but in the community of operators who understand that eternal vigilance is the price of security. Stay informed, stay secure, and keep ooerating.