1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

Head Office (Tokyo):
├─ Network: 192.168.1.0/24
├─ Gateway: 192.168.1.1
├─ DHCP Range: 192.168.1.100-200
├─ Servers: 192.168.1.10-50
└─ Employee PCs: 120 units

Osaka Branch:
├─ Network: 192.168.1.0/24  ← Same!
├─ Gateway: 192.168.1.1     ← Same!
├─ DHCP Range: 192.168.1.100-200  ← Same!
├─ Servers: 192.168.1.10-50    ← Same!
└─ Employee PCs: 80 units

Nagoya Branch:
├─ Network: 192.168.1.0/24  ← Same!
├─ Gateway: 192.168.1.1     ← Same!
├─ DHCP Range: 192.168.1.100-200  ← Same!
├─ Servers: 192.168.1.10-50    ← Same!
└─ Employee PCs: 45 units

Fukuoka Branch:
├─ Network: 192.168.1.0/24  ← Same!
├─ Gateway: 192.168.1.1     ← Same!
├─ DHCP Range: 192.168.1.100-200  ← Same!
├─ Servers: 192.168.1.10-50    ← Same!
└─ Employee PCs: 30 units

Sapporo Branch:
├─ Network: 192.168.1.0/24  ← Same!
├─ Gateway: 192.168.1.1     ← Same!
├─ DHCP Range: 192.168.1.100-200  ← Same!
├─ Servers: 192.168.1.10-50    ← Same!
└─ Employee PCs: 25 units

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

                 [Internet]
                       ↓
            [Head Office Main Firewall]
                       ↓
              [Head Office LAN: 192.168.1.0/24]
                       ↓
           ┌─────────[VPN Hub]─────────┐
           ↓                          ↓
    [Osaka Branch VPN]              [Nagoya Branch VPN]
    192.168.1.0/24            192.168.1.0/24
           ↓                          ↓
    [Fukuoka Branch VPN]              [Sapporo Branch VPN]
    192.168.1.0/24            192.168.1.0/24

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Head office VPN server configuration
# /etc/openvpn/server.conf
port 1194
proto udp
dev tun
server 192.168.1.0 255.255.255.0  # Same segment as head office

# Osaka branch VPN configuration  
# /etc/openvpn/client.conf
remote tokyo-vpn.company.com 1194
dev tun

1
2
3
4
5

# Connection test from Osaka branch
ping 192.168.1.10  # Head office server
# PING 192.168.1.10: 56 data bytes
# 64 bytes from 192.168.1.10: icmp_seq=0 ttl=64 time=15.2 ms
# 64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=14.8 ms

1
2
3
4
5
6

Osaka Branch IT Staff: "Something strange is happening"
Me: "What's wrong?"
Osaka Branch IT Staff: "Sometimes we can access head office file server, sometimes we can't"
Me: "Is the VPN connection stable?"
Osaka Branch IT Staff: "The connection is stable, but sometimes Osaka's file server appears instead"
Me: "Huh?"

1
2
3
4
5
6

# Head office routing table
route -n
Destination     Gateway         Genmask         Iface
192.168.1.0     0.0.0.0         255.255.255.0   eth0     # Local
192.168.1.0     10.8.0.6        255.255.255.0   tun0     # VPN (Osaka)
192.168.1.0     10.8.0.10       255.255.255.0   tun0     # VPN (Nagoya)

1
2
3
4
5
6
7

# Access to 192.168.1.10 (file server)
tcpdump -i any host 192.168.1.10

# Results:
# 09:15:23 Osaka PC → 192.168.1.10 → Osaka file server
# 09:15:45 Osaka PC → 192.168.1.10 → Head office file server  
# 09:16:12 Osaka PC → 192.168.1.10 → Nagoya file server

1
2
3
4
5
6
7

Routing table hell:
Destination     Gateway         Iface      Priority
192.168.1.0     0.0.0.0        eth0       0        # Head office local
192.168.1.0     10.8.0.6       tun0       0        # Osaka VPN  
192.168.1.0     10.8.0.10      tun0       0        # Nagoya VPN
192.168.1.0     10.8.0.14      tun0       0        # Fukuoka VPN
192.168.1.0     10.8.0.18      tun0       0        # Sapporo VPN

1
2
3

"Thought I saved a file, but it was saved to Nagoya branch server"
"Tried to access accounting data, but Fukuoka's data appeared"
"Can't find printer (referencing Sapporo printer)"

1
2
3

"Customer database showing Osaka inventory data instead"  
"Mail server connection intermittent"
"Company chat mixing with people from other branches"

1
2

"Important proposal document being simultaneously edited by head office person, causing conflicts"
"Timecard system mixing employee data from other branches"

1
2

"Inventory management system contaminated with Fukuoka products"
"Employee list in attendance system completely messed up"

1
2
3
4
5
6
7
8
9

Previously (independent sites):
Head office: [192.168.1.10] → Head office file server ✓
Osaka: [192.168.1.10] → Osaka file server ✓
Nagoya: [192.168.1.10] → Nagoya file server ✓

After VPN integration:
All sites: [192.168.1.10] → ???Which server???
        ↓Randomly distributed
    Head office OR Osaka OR Nagoya OR Fukuoka OR Sapporo

1
2
3
4
5

# Linux kernel routing decision
# When multiple routes to same destination exist:
1. Decide by metric value (priority)
2. If same metric, load balance (Round Robin)
3. Result: Different server connection each access

1
2
3
4
5
6
7
8

# Stop all branch VPNs
systemctl stop openvpn@client-osaka
systemctl stop openvpn@client-nagoya  
systemctl stop openvpn@client-fukuoka
systemctl stop openvpn@client-sapporo

# Completely block inter-site communication
iptables -A FORWARD -s 10.8.0.0/24 -j DROP

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Subject: [EMERGENCY] VPN Integration Project Temporary Suspension Notice

All employees,

Serious network communication problems occurred due to VPN integration started today.
To ensure data integrity, we are implementing the following measures:

1. Emergency stop of all inter-site VPN connections
2. Continue business operations with each site's local network only
3. Temporarily stop inter-site data synchronization
4. Estimated 72 hours to recovery

We apologize for the inconvenience.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- Customer database duplication check
SELECT customer_id, COUNT(*) 
FROM customers 
GROUP BY customer_id 
HAVING COUNT(*) > 1;

Results:
Head office DB: 2,347 duplicate records (other sites' data contamination)
Osaka DB: 1,892 duplicate records
Nagoya DB: 1,234 duplicate records  
Fukuoka DB: 897 duplicate records
Sapporo DB: 654 duplicate records

1
2
3
4
5

# Inter-site file contamination investigation
find /shared -name "*.docx" -exec grep -l "Osaka" {} \; | wc -l
# Head office server with Osaka-specific files: 156 files
# Osaka server with head office files: 203 files
# Nagoya server with other sites' files: 89 files

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Failed design:
  Problem: All sites using same IP address range
  Cause: Lack of understanding of IP address conflicts
  Result: Routing conflicts & data contamination

New design principles:
  1. Hierarchical IP address system
  2. Complete site separation
  3. Ensure future scalability
  4. Management ease

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Hierarchical design: 10.{site}.{department}.{host}

Site code definition:
├─ Head Office (Tokyo): 10.1.x.x/16
├─ Osaka Branch: 10.2.x.x/16  
├─ Nagoya Branch: 10.3.x.x/16
├─ Fukuoka Branch: 10.4.x.x/16
└─ Sapporo Branch: 10.5.x.x/16

Department code (common across sites):
├─ General departments: x.1.x/24
├─ Accounting department: x.2.x/24
├─ Development department: x.3.x/24
├─ Servers: x.99.x/24
└─ Network equipment: x.254.x/24

Examples:
Head office accounting: 10.1.2.0/24
Osaka development: 10.2.3.0/24  
Nagoya servers: 10.3.99.0/24

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Phase_1_Design:
  Duration: "24 hours"
  Target: "Head office & Osaka branch"
  Method: "Weekend work forced switchover"
  
  Head office migration:
    From: 192.168.1.0/24
    To: 10.1.0.0/16
    
  Osaka migration:
    From: 192.168.1.0/24
    To: 10.2.0.0/16

Phase_2_Implementation:
  Duration: "24 hours"  
  Target: "Nagoya & Fukuoka branches"
  
Phase_3_Final:
  Duration: "24 hours"
  Target: "Sapporo branch & all-site VPN connection"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 1. DHCP server configuration change
# /etc/dhcp/dhcpd.conf
subnet 10.1.1.0 netmask 255.255.255.0 {
    range 10.1.1.100 10.1.1.200;
    option routers 10.1.1.1;
    option domain-name-servers 10.1.1.2;
}

# 2. Server static IP change
# File server: 192.168.1.10 → 10.1.99.10
# Mail server: 192.168.1.11 → 10.1.99.11  
# DB server: 192.168.1.12 → 10.1.99.12

# 3. Client PC restart (DHCP automatic acquisition)
for pc in tokyo-pc-{001..120}; do
    ssh admin@$pc "sudo reboot"
done

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Remote work (coordination with Osaka local IT staff)
# DHCP configuration change
subnet 10.2.1.0 netmask 255.255.255.0 {
    range 10.2.1.100 10.2.1.200;
    option routers 10.2.1.1;
    option domain-name-servers 10.2.1.2;
}

# Server IP change
# File server: 192.168.1.10 → 10.2.99.10
# Print server: 192.168.1.11 → 10.2.99.11

1
2
3
4
5
6
7
8
9

# Head office→Osaka access test
ping 10.2.99.10  # Osaka file server
# PING 10.2.99.10: 56 data bytes  
# 64 bytes from 10.2.99.10: icmp_seq=0 ttl=64 time=16.3 ms

# Osaka→Head office access test  
ping 10.1.99.10  # Head office file server
# PING 10.1.99.10: 56 data bytes
# 64 bytes from 10.1.99.10: icmp_seq=0 ttl=64 time=15.8 ms

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Migration results:
Nagoya Branch:
  - Old: 192.168.1.0/24 
  - New: 10.3.0.0/16 ✓

Fukuoka Branch:
  - Old: 192.168.1.0/24
  - New: 10.4.0.0/16 ✓

Sapporo Branch:  
  - Old: 192.168.1.0/24
  - New: 10.5.0.0/16 ✓

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Head office VPN server configuration
# /etc/openvpn/server.conf
server 172.16.0.0 255.255.0.0  # VPN segment (conflict avoidance)

# Routing configuration
push "route 10.1.0.0 255.255.0.0"  # Route to head office
push "route 10.2.0.0 255.255.0.0"  # Route to Osaka  
push "route 10.3.0.0 255.255.0.0"  # Route to Nagoya
push "route 10.4.0.0 255.255.0.0"  # Route to Fukuoka
push "route 10.5.0.0 255.255.0.0"  # Route to Sapporo

# Access control from each site
iptables -A FORWARD -s 10.2.0.0/16 -d 10.1.99.0/24 -j ACCEPT  # Osaka→Head office servers
iptables -A FORWARD -s 10.3.0.0/16 -d 10.1.99.0/24 -j ACCEPT  # Nagoya→Head office servers

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Test from Osaka branch
ping 10.1.99.10  # Head office file server ✓
ping 10.3.99.10  # Nagoya file server ✓
ping 10.4.99.10  # Fukuoka file server ✓  
ping 10.5.99.10  # Sapporo file server ✓

# File sharing test
mount -t cifs //10.1.99.10/shared /mnt/tokyo-share ✓
mount -t cifs //10.3.99.10/shared /mnt/nagoya-share ✓

# Database connection test
mysql -h 10.1.99.12 -u osaka_user -p company_db ✓

1
2
3
4
5
6
7

route -n
Destination     Gateway         Genmask         Iface
10.1.0.0        172.16.0.1      255.255.0.0     tun0    # Head office
10.2.0.0        0.0.0.0         255.255.0.0     eth0    # Osaka (self)
10.3.0.0        172.16.0.1      255.255.0.0     tun0    # Nagoya
10.4.0.0        172.16.0.1      255.255.0.0     tun0    # Fukuoka  
10.5.0.0        172.16.0.1      255.255.0.0     tun0    # Sapporo

1
2
3
4
5

Head office: "Can clearly access all sites' file servers"
Osaka: "Customer data contamination resolved, safe access"
Nagoya: "Printers also recognize correct site ones"
Fukuoka: "Inventory system working normally, can also reference other sites' data"
Sapporo: "Attendance system stable, company-wide integration features also working"

1
2
3
4
5
6
7
8
9

# Site-based access control rules
# Accounting system accessible only from head office and Osaka
iptables -A FORWARD -s 10.1.2.0/24 -d 10.1.99.13 -j ACCEPT  # Head office accounting→Accounting server
iptables -A FORWARD -s 10.2.2.0/24 -d 10.1.99.13 -j ACCEPT  # Osaka accounting→Accounting server
iptables -A FORWARD -s 0.0.0.0/0 -d 10.1.99.13 -j DROP      # Others denied

# Development environment accessible only to development departments
iptables -A FORWARD -s 10.1.3.0/24 -d 10.1.99.15 -j ACCEPT  # Head office dev→Dev server
iptables -A FORWARD -s 10.2.3.0/24 -d 10.1.99.15 -j ACCEPT  # Osaka dev→Dev server

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Network monitoring script
def analyze_traffic():
    traffic_by_location = {
        'Head Office': monitor_subnet('10.1.0.0/16'),
        'Osaka': monitor_subnet('10.2.0.0/16'),
        'Nagoya': monitor_subnet('10.3.0.0/16'),
        'Fukuoka': monitor_subnet('10.4.0.0/16'),
        'Sapporo': monitor_subnet('10.5.0.0/16')
    }
    
    for location, traffic in traffic_by_location.items():
        print(f"{location}: {traffic['bandwidth']}Mbps, {traffic['connections']} connections")

1
2
3
4
5
6
7
8
9

Before (overlap era):
  Failure occurs: "192.168.1.10 failure"
  Impact scope: "Unknown (all sites possible)"
  Recovery work: "All sites investigation needed"

After (hierarchical):
  Failure occurs: "10.2.99.10 failure"  
  Impact scope: "Osaka branch only"
  Recovery work: "Focus on Osaka branch"

1
2
3

"192.168.1.0 is default so it's safe"
"Everyone uses it so no problem"  
"It's a standard address so it can't be wrong"

1
2
3

"Design considering future scalability is necessary"
"Conflict avoidance is the top priority"
"Hierarchical system design is important"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Large enterprise recommended design:
  Format: "10.{region}.{dept}.{host}"
  
  Benefits:
    - Scalability: 256 regions × 256 departments = 65,536 segments
    - Easy understanding: Site & department visible from IP address
    - Management efficiency: Systematic routing & firewall configuration
    - Failure isolation: Instantly identify impact scope

Medium enterprise recommended design:
  Format: "172.16.{site}.{subnet}"
  Range: 172.16.0.0/12
  
  Benefits:  
    - Appropriate scale: 16 sites × 256 segments = 4,096 segments
    - Distinction from home use: Clearly separate from 192.168.x.x
    - Easy future cloud integration

Small enterprise recommended design:
  Format: "192.168.{dept}.{host}"
  
  Benefits:
    - Simple: Easy to understand
    - Department separation: Basic segmentation
    - Low cost: Can handle with existing equipment

1
2

Network_Address: "x.x.x.0"
Broadcast_Address: "x.x.x.255"

1
2
3
4
5
6
7
8

Gateway: "x.x.x.1"
DNS_Primary: "x.x.x.2"
DNS_Secondary: "x.x.x.3"
Network_Equipment: "x.x.x.4-9"
DHCP_Pool: "x.x.x.10-99"
Servers: "x.x.x.100-199"  
Printers_IoT: "x.x.x.200-230"
Management: "x.x.x.240-254"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Analysis_Checklist:
  Current_Scale:
    - Number of sites: ?
    - Number of departments: ?  
    - Number of employees: ?
    - Number of devices: ?
    
  Future_Growth:
    - Number of sites in 5 years: ?
    - Number of employees in 10 years: ?
    - IoT device deployment plan: ?
    - Cloud integration plan: ?
    
  Technical_Requirements:
    - VPN integration necessity: ?
    - Security requirements: ?
    - Existing system constraints: ?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

def select_ip_range(total_sites, total_subnets, total_hosts):
    """
    Optimal IP address range selection based on requirements
    """
    if total_hosts > 1_000_000:
        return "10.0.0.0/8"  # Large enterprise, multi-site
    elif total_hosts > 50_000:
        return "172.16.0.0/12"  # Medium enterprise
    else:
        return "192.168.0.0/16"  # Small enterprise
        
# Usage example
recommendation = select_ip_range(
    total_sites=5,
    total_subnets=20, 
    total_hosts=500
)
print(f"Recommended: {recommendation}")  # Recommended: 172.16.0.0/12

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Implementation_Template:
  Large_Enterprise:
    Format: "10.{region}.{dept}.{host}"
    Example: "10.1.2.100 = Tokyo, Accounting Dept, Host 100"
    
  Medium_Enterprise:
    Format: "172.16.{site}.{subnet}"
    Example: "172.16.1.100 = Head Office, Server Segment"
    
  Small_Enterprise:  
    Format: "192.168.{dept}.{host}"
    Example: "192.168.1.100 = General Dept, Host 100"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Phase_Migration_Strategy:
  Phase_1:
    Duration: "1 week"
    Scope: "Low importance, small impact"
    Target: ["Test environment", "Some sites"]
    
  Phase_2:
    Duration: "2 weeks"  
    Scope: "Medium importance, partial impact"
    Target: ["Development environment", "Non-critical sites"]
    
  Phase_3:
    Duration: "1 week"
    Scope: "High importance, company-wide impact" 
    Target: ["Production environment", "Main sites"]

Rollback_Plan:
  Trigger: "30% or more malfunction"
  Time_Limit: "Complete recovery within 4 hours"
  Backup: "Complete configuration backup mandatory"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Next_Generation_IP_Design:
  Software_Defined_Networking:
    - Dynamic IP address allocation
    - Automatic segmentation by purpose
    - AI optimization
    
  Zero_Trust_Integration:
    - IP address + Identity integrated management
    - Risk-based access control
    - Continuous permission optimization
    
  Cloud_Native_Approach:
    - Multi-cloud IP address management  
    - Container-compatible address design
    - Serverless environment integration