infra/shx-network
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
13 Commits 1 Branch 0 Tags
fc11a6a674d044964f67a0b860e1d3a88bc7766c
T
Clone
Open with VS Code Open with VSCodium Open with Intellij IDEA
Download ZIP Download TAR.GZ Download BUNDLE
denozord fc11a6a674 update
2025-07-10 11:27:03 +07:00
README.md
update
2025-07-10 11:27:03 +07:00

README.md

SHX Network Infrastructure

Обзор сети

Данный проект описывает сетевую инфраструктуру с двумя провайдерами интернет-соединения и множественными GRE туннелями для обеспечения отказоустойчивости и географического распределения.

Архитектура сети

Основная схема (обновлено)

graph TB
    subgraph "Шлюз (Gateway)"
        GW[Основной шлюз]
    end
    
    subgraph "Провайдеры"
        MTS[МТС]
        RTK[Ростелеком]
    end
    
    subgraph "GRE Туннели"
        subgraph "Ростелеком (RTK)"
            RTK1[MSK-VPSVILLE-RTK]
            RTK2[MSK-IHOR-RTK]
            RTK3[SWE-HIPHOST-RTK]
        end
        
        subgraph "МТС (MTS)"
            MTS1[MSK-VPSVILLE-MTS]
            MTS2[MSK-IHOR-MTS]
            MTS3[SWE-HIPHOST-MTS]
        end
    end
    
    subgraph "Удаленные узлы"
        VPSVILLE[VPSVILLE]
        IHOR[IHOR]
        HIPHOST["HIPHOST<br/>SWE"]
    end
    
    GW --> MTS
    GW --> RTK
    
    MTS --> MTS1
    MTS --> MTS2
    MTS --> MTS3
    
    RTK --> RTK1
    RTK --> RTK2
    RTK --> RTK3
    
    MTS1 --> VPSVILLE
    MTS2 --> IHOR
    MTS3 --> HIPHOST
    
    RTK1 --> VPSVILLE
    RTK2 --> IHOR
    RTK3 --> HIPHOST
    
    %% Новое: GRE SWE-HIPHOST от всех МСК серверов
    VPSVILLE -- GRE SWE-HIPHOST --> HIPHOST
    IHOR -- GRE SWE-HIPHOST --> HIPHOST
    
    style GW fill:#e1f5fe
    style MTS fill:#ffebee
    style RTK fill:#e8f5e8
    style VPSVILLE fill:#fff3e0
    style IHOR fill:#fff3e0
    style HIPHOST fill:#fff3e0

Детальная схема туннелей (обновлено)

graph LR
    subgraph "Шлюз"
        GW[Gateway]
    end
    
    subgraph "Провайдер МТС"
        MTS_ISP[МТС ISP]
    end
    
    subgraph "Провайдер Ростелеком"
        RTK_ISP[Ростелеком ISP]
    end
    
    subgraph "GRE Туннели"
        subgraph "Москва - VPSVILLE"
            MTS_VPS[MSK-VPSVILLE-MTS<br/>GRE Tunnel]
            RTK_VPS[MSK-VPSVILLE-RTK<br/>GRE Tunnel]
        end
        
        subgraph "Москва - IHOR"
            MTS_IHOR[MSK-IHOR-MTS<br/>GRE Tunnel]
            RTK_IHOR[MSK-IHOR-RTK<br/>GRE Tunnel]
        end
        
        subgraph "Швеция - HIPHOST"
            MTS_HIP[SWE-HIPHOST-MTS<br/>GRE Tunnel]
            RTK_HIP[SWE-HIPHOST-RTK<br/>GRE Tunnel]
        end
    end
    
    subgraph "Удаленные серверы"
        VPS[VPSVILLE Server<br/>Москва]
        IHR[IHOR Server<br/>Москва]
        HIP["HIPHOST<br/>SWE"]
    end
    
    GW --> MTS_ISP
    GW --> RTK_ISP
    
    MTS_ISP --> MTS_VPS
    MTS_ISP --> MTS_IHOR
    MTS_ISP --> MTS_HIP
    
    RTK_ISP --> RTK_VPS
    RTK_ISP --> RTK_IHOR
    RTK_ISP --> RTK_HIP
    
    MTS_VPS --> VPS
    MTS_IHOR --> IHR
    MTS_HIP --> HIP
    
    RTK_VPS --> VPS
    RTK_IHOR --> IHR
    RTK_HIP --> HIP
    
    %% Новое: GRE SWE-HIPHOST от всех МСК серверов
    VPS -- GRE SWE-HIPHOST --> HIP
    IHR -- GRE SWE-HIPHOST --> HIP
    
    style GW fill:#2196f3,stroke:#1976d2,stroke-width:2px,color:#fff
    style MTS_ISP fill:#f44336,stroke:#d32f2f,stroke-width:2px,color:#fff
    style RTK_ISP fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff
    style VPS fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff
    style IHR fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff
    style HIP fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff

Схема европейского трафика (новая)

graph TD
    subgraph "Москва"
        VPSVILLE_MSK[VPSVILLE<br/>Москва]
        IHOR_MSK[IHOR<br/>Москва]
    end
    subgraph "Швеция"
        HIPHOST_SWE["HIPHOST<br/>SWE"]
    end
    
    VPSVILLE_MSK -- GRE SWE-HIPHOST --> HIPHOST_SWE
    IHOR_MSK -- GRE SWE-HIPHOST --> HIPHOST_SWE
    
    HIPHOST_SWE -- "Европейский интернет" --> EU[EU Resources]
    
    classDef eu fill:#e3f2fd,stroke:#1976d2,stroke-width:2px;
    class EU eu;

Схема связывания московских серверов через OSPF (новая)

graph TB
    subgraph "Москва - VPSVILLE"
        VPSVILLE[VPSVILLE<br/>msk.vpsville.rt.shx.su]
    end
    
    subgraph "Москва - IHOR"
        IHOR[IHOR<br/>msk.ihor.rt.shx.su]
    end
    
    subgraph "Домашний шлюз"
        HOME[HOME<br/>home.rt.shx.su]
    end
    
    %% GRE туннели от домашнего шлюза (только клиентские подключения)
    HOME -- "GRE MSK-VPSVILLE-RTK<br/>10.100.2.0/30" --> VPSVILLE
    HOME -- "GRE MSK-VPSVILLE-MTS<br/>10.100.1.0/30" --> VPSVILLE
    HOME -- "GRE MSK-IHOR-RTK<br/>10.100.4.0/30" --> IHOR
    HOME -- "GRE MSK-IHOR-MTS<br/>10.100.3.0/30" --> IHOR
    
    %% GRE туннель между московскими серверами (независимо от HOME)
    VPSVILLE -- "GRE MSK-VPSVILLE-IHOR<br/>10.200.0.0/30" --> IHOR
    
    %% OSPF связи только между серверами
    VPSVILLE -. "OSPF" .- IHOR
    
    %% HOME только получает маршруты от серверов
    VPSVILLE -. "OSPF маршруты" .- HOME
    IHOR -. "OSPF маршруты" .- HOME
    
    style VPSVILLE fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff
    style IHOR fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff
    style HOME fill:#e0e0e0,stroke:#9e9e9e,stroke-width:2px,color:#000

Схема отказоустойчивости (обновлено)

graph TB
    subgraph "Основной путь"
        GW[Gateway]
        MTS[MТС - Основной]
        RTK[Ростелеком - Резервный]
    end
    
    subgraph "Туннели по приоритету"
        subgraph "VPSVILLE"
            VPS_MTS[MSK-VPSVILLE-MTS<br/>Приоритет 1]
            VPS_RTK[MSK-VPSVILLE-RTK<br/>Приоритет 2]
        end
        
        subgraph "IHOR"
            IHR_MTS[MSK-IHOR-MTS<br/>Приоритет 1]
            IHR_RTK[MSK-IHOR-RTK<br/>Приоритет 2]
        end
        
        subgraph "HIPHOST"
            HIP_MTS[SWE-HIPHOST-MTS<br/>Приоритет 1]
            HIP_RTK[SWE-HIPHOST-RTK<br/>Приоритет 2]
        end
    end
    
    GW --> MTS
    GW --> RTK
    
    MTS --> VPS_MTS
    MTS --> IHR_MTS
    MTS --> HIP_MTS
    
    RTK --> VPS_RTK
    RTK --> IHR_RTK
    RTK --> HIP_RTK
    
    VPS_MTS -.->|Failover| VPS_RTK
    IHR_MTS -.->|Failover| IHR_RTK
    HIP_MTS -.->|Failover| HIP_RTK
    
    %% Новое: Европейский трафик через SWE-HIPHOST
    VPS_MTS -- "EU трафик" --> HIP_MTS
    VPS_RTK -- "EU трафик" --> HIP_RTK
    IHR_MTS -- "EU трафик" --> HIP_MTS
    IHR_RTK -- "EU трафик" --> HIP_RTK
    
    style GW fill:#2196f3,stroke:#1976d2,stroke-width:3px,color:#fff
    style MTS fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff
    style RTK fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff

Конфигурация туннелей

Ростелеком (RTK)

Туннель Назначение Локация Статус
MSK-VPSVILLE-RTK Основной канал VPSVILLE Москва Активен
MSK-IHOR-RTK Основной канал IHOR Москва Активен
SWE-HIPHOST-RTK Основной канал HIPHOST Швеция Активен

МТС (MTS)

Туннель Назначение Локация Статус
MSK-VPSVILLE-MTS Резервный канал VPSVILLE Москва Активен
MSK-IHOR-MTS Резервный канал IHOR Москва Активен
SWE-HIPHOST-MTS Резервный канал HIPHOST Швеция Активен

Преимущества архитектуры

  1. Отказоустойчивость: Два независимых провайдера обеспечивают непрерывность работы
  2. Географическое распределение: Серверы в разных локациях (Москва, Швеция)
  3. Балансировка нагрузки: Возможность распределения трафика между провайдерами
  4. Масштабируемость: Легкое добавление новых туннелей и серверов

Мониторинг

  • Отслеживание состояния всех GRE туннелей
  • Мониторинг пропускной способности каналов
  • Автоматическое переключение при отказе основного канала
  • Логирование событий и статистики

Технические детали

  • Протокол: GRE (Generic Routing Encapsulation)
  • Шифрование: IPSec (опционально)
  • Мониторинг: Keepalive пакеты
  • Failover: Автоматическое переключение при потере связи

Рекомендации по адресации GRE туннелей

Для GRE туннелей рекомендуется использовать отдельный диапазон, например, 10.100.0.0/16, чтобы избежать конфликтов с домашней сетью (192.168.0.0/16). Для каждого туннеля выделяется отдельная /30 подсеть (две точки).

Пример распределения адресов для GRE туннелей

Туннель Подсеть Gateway (ваш) Remote (удалённый)
MSK-VPSVILLE-MTS 10.100.1.0/30 10.100.1.1 10.100.1.2
MSK-VPSVILLE-RTK 10.100.2.0/30 10.100.2.1 10.100.2.2
MSK-IHOR-MTS 10.100.3.0/30 10.100.3.1 10.100.3.2
MSK-IHOR-RTK 10.100.4.0/30 10.100.4.1 10.100.4.2
SWE-HIPHOST-MTS 10.100.5.0/30 10.100.5.1 10.100.5.2
SWE-HIPHOST-RTK 10.100.6.0/30 10.100.6.1 10.100.6.2
  • Первый IP в /30 — ваш шлюз (CHR), второй — удалённая сторона.
  • Такой подход обеспечивает прозрачность, масштабируемость и минимизирует конфликты.

Безопасность и маршрутизация на RouterOS

  • Использование диапазона 10.100.0.0/16 для GRE туннелей безопасно, если ваша домашняя сеть — 192.168.0.0/16.
  • Диапазоны не пересекаются, маршрутизация не сломается.
  • На CHR (RouterOS) это стандартная практика: GRE туннели выносят в отдельный диапазон, чтобы не было конфликтов с LAN.
  • Для GRE-интерфейсов прописывайте адресацию только из этого диапазона.
  • В маршрутах на CHR не должно быть статических маршрутов, которые бы направляли 10.100.0.0/16 в локальную сеть.

Пример маршрутизации на RouterOS

  • Для каждого GRE-интерфейса будет автоматически создан маршрут для /30 подсети.
  • Например, если GRE-интерфейс имеет адрес 10.100.1.1/30, а удалённый — 10.100.1.2, то маршрут до 10.100.1.2 будет через этот GRE-интерфейс.
  • Основная домашняя сеть (192.168.0.0/16) никак не пересекается с этими маршрутами.

Пример конфигурации GRE туннеля на RouterOS

/interface gre add name=gre-MSK-VPSVILLE-MTS remote-address=<REMOTE_IP> local-address=<YOUR_WAN_IP>
/ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS
/ip route add dst-address=10.100.1.2/32 gateway=gre-MSK-VPSVILLE-MTS
  • <REMOTE_IP> — внешний IP удалённого сервера
  • <YOUR_WAN_IP> — ваш внешний IP
  • Аналогично для остальных туннелей, меняя адресацию по таблице выше

OSPF: Оптимальная настройка для GRE туннелей

В данной архитектуре используется OSPF для динамической маршрутизации между всеми GRE туннелями. Основной провайдер — Ростелеком, резервный — МТС. Для HomeLab (например, 192.168.111.0/24) весь трафик направляется через МТС с помощью policy routing (route-table=MTS).

Рекомендации по настройке

  1. OSPF cost

    • Для GRE туннелей через Ростелеком выставить меньший cost (например, 10)
    • Для GRE туннелей через МТС — больший cost (например, 100)
    • Это обеспечит приоритет Ростелекома для всего трафика, кроме HomeLab

  2. Policy Based Routing (PBR) для HomeLab

    • Для HomeLab (например, 192.168.111.0/24) настроить policy routing:
      • Весь исходящий трафик с HomeLab отправлять в route-table=MTS
      • В этой таблице основной маршрут — через МТС

  3. OSPF Instance и Area

    • Использовать одну OSPF instance для всех туннелей (если нет особых требований)
    • Все GRE-интерфейсы добавить в одну area (обычно 0.0.0.0)

Пример конфигурации OSPF на RouterOS

# 1. Настройка OSPF instance
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.1

# 2. Добавление GRE-интерфейсов в OSPF с разным cost
/routing ospf interface
add interface=gre-MSK-VPSVILLE-RTK cost=10 network-type=point-to-point
add interface=gre-MSK-IHOR-RTK cost=10 network-type=point-to-point
add interface=gre-SWE-HIPHOST-RTK cost=10 network-type=point-to-point

add interface=gre-MSK-VPSVILLE-MTS cost=100 network-type=point-to-point
add interface=gre-MSK-IHOR-MTS cost=100 network-type=point-to-point
add interface=gre-SWE-HIPHOST-MTS cost=100 network-type=point-to-point

# 3. Добавление сетей в OSPF
/routing ospf network
add network=10.100.0.0/16 area=backbone

# 4. Policy Based Routing для HomeLab
/ip route
add dst-address=0.0.0.0/0 gateway=<MTS-GW> routing-table=MTS
/ip firewall mangle
add chain=prerouting src-address=192.168.111.0/24 action=mark-routing new-routing-mark=MTS

# <MTS-GW> — адрес следующего хопа через МТС (например, 10.100.1.2)

Логика работы

  • OSPF сам будет выбирать основной маршрут через Ростелеком (cost ниже).
  • Если основной канал падает, трафик автоматически пойдёт через МТС.
  • Для HomeLab весь трафик всегда идёт через МТС, независимо от состояния каналов, благодаря policy routing.

Failover между московскими туннелями (route-table=MSK)

Для клиентов/серверов, использующих отдельную таблицу маршрутизации MSK, реализован автоматический failover между московскими GRE туннелями. Если один из туннелей (MSK-VPSVILLE или MSK-IHOR) падает, весь трафик автоматически идёт через оставшийся рабочий туннель.

Как это работает

  • OSPF анонсирует маршруты через оба московских туннеля.
  • Если один туннель недоступен, маршрут через него исчезает из таблицы MSK.
  • Policy Based Routing (PBR) направляет трафик нужных клиентов в таблицу MSK.
  • В таблице MSK всегда есть маршрут через рабочий туннель.

Пример конфигурации на RouterOS

# 1. Маркируем трафик для route-table=MSK
/ip firewall mangle
add chain=prerouting src-address=192.168.222.0/24 action=mark-routing new-routing-mark=MSK

# 2. В таблице MSK маршруты через оба московских туннеля
/ip route
# OSPF сам добавит маршруты через gre-MSK-VPSVILLE и gre-MSK-IHOR, если они живы
# Если хотите вручную:
add dst-address=0.0.0.0/0 gateway=10.100.1.2 routing-table=MSK distance=1
add dst-address=0.0.0.0/0 gateway=10.100.3.2 routing-table=MSK distance=2

# 3. OSPF интерфейсы для московских туннелей
/routing ospf interface
add interface=gre-MSK-VPSVILLE-RTK cost=10 network-type=point-to-point
add interface=gre-MSK-IHOR-RTK cost=10 network-type=point-to-point
add interface=gre-MSK-VPSVILLE-MTS cost=100 network-type=point-to-point
add interface=gre-MSK-IHOR-MTS cost=100 network-type=point-to-point
  • OSPF будет держать маршруты только через живые туннели.
  • Если оба туннеля живы — оба маршрута в таблице, основной с меньшим distance.
  • Если один туннель падает — маршрут через него исчезает, трафик идёт через оставшийся.

Примеры конфигурации для RouterOS 7.14+

OSPF (RouterOS 7.14+)

# 1. Создание OSPF instance и area
/routing ospf instance
add name=default router-id=10.100.0.1

/routing ospf area
add name=backbone instance=default area-id=0.0.0.0

# 2. Добавление GRE-интерфейсов с нужным cost
/routing ospf interface-template
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone
add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone
add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone

add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone
add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone

Policy Based Routing (RouterOS 7.14+)

# 1. Создание таблиц маршрутизации
/routing table
add name=MSK fib
add name=MTS fib

# 2. Routing rules для выбора таблицы по источнику
/routing rule
add src-address=192.168.111.0/24 action=lookup table=MTS
add src-address=192.168.222.0/24 action=lookup table=MSK

# OSPF сам добавит маршруты в эти таблицы, если GRE-интерфейсы участвуют в OSPF

GRE туннели (пример)

/interface gre add name=gre-MSK-VPSVILLE-RTK remote-address=<REMOTE_IP> local-address=<YOUR_WAN_IP>
/ip address add address=10.100.2.1/30 interface=gre-MSK-VPSVILLE-RTK
# Аналогично для остальных туннелей по таблице адресации

Актуальные рекомендации для RouterOS 7.14+

  • Используйте /routing rule для Policy Based Routing вместо mangle.
  • OSPF интерфейсы и cost настраиваются через interface-template.
  • Все GRE туннели должны быть добавлены в OSPF через interface-template для корректного анонса маршрутов.
  • OSPF автоматически поддерживает failover между туннелями: если один туннель падает, маршрут исчезает из таблицы.
  • Для отдельных сегментов (например, HomeLab или MSK) используйте отдельные routing table и routing rule для выбора нужного провайдера/туннеля.

Пример failover для route-table=MSK (RouterOS 7.14+)

# 1. Routing rule для сегмента MSK
/routing rule
add src-address=192.168.222.0/24 action=lookup table=MSK

# 2. OSPF сам добавит маршруты через gre-MSK-VPSVILLE и gre-MSK-IHOR в таблицу MSK
# Если хотите вручную:
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.1.2 routing-table=MSK distance=1
add dst-address=0.0.0.0/0 gateway=10.100.3.2 routing-table=MSK distance=2

Масштабирование сети с GRE и OSPF

Схема с GRE-туннелями и OSPF идеально подходит для масштабируемых и отказоустойчивых сетей.

Преимущества

  • Лёгкое добавление новых туннелей: для нового хоста создаётся GRE-интерфейс, выделяется /30 подсеть, добавляется в OSPF — маршруты распространяются автоматически.
  • Быстрая замена хоста: при замене сервера/маршрутизатора достаточно повторить настройки GRE и OSPF — сеть быстро перестроится без ручных правок на других устройствах.
  • Гибкая топология: можно строить как “звезду”, так и “mesh” — OSPF сам выберет оптимальные маршруты и обеспечит резервирование.
  • Автоматический failover: при недоступности туннеля или хоста OSPF убирает маршруты, трафик идёт по резервным путям.
  • Масштабируемость: количество туннелей ограничено только ресурсами оборудования, добавление новых площадок не требует изменений на старых.

Рекомендации

  • Для каждого нового туннеля используйте отдельную /30 подсеть из выделенного диапазона (например, 10.100.x.0/30).
  • Все GRE-интерфейсы сразу добавляйте в OSPF через interface-template.
  • Используйте шаблоны и автоматизацию для быстрой настройки новых точек.
  • Документируйте назначение каждой подсети и туннеля (см. таблицу выше).

Пример добавления нового GRE туннеля и OSPF (RouterOS 7.14+)

/interface gre add name=gre-NEW-SITE remote-address=<NEW_REMOTE_IP> local-address=<YOUR_WAN_IP>
/ip address add address=10.100.10.1/30 interface=gre-NEW-SITE

/routing ospf interface-template
add interfaces=gre-NEW-SITE cost=10 area=backbone

Европейский трафик через GRE SWE-HIPHOST

У всех московских серверов настроен GRE-туннель на SWE-HIPHOST. Обычно через этот туннель направляется европейский трафик для оптимизации маршрутов и повышения скорости доступа к европейским ресурсам.

Как это реализовано

  • Все GRE-туннели SWE-HIPHOST добавлены в OSPF через interface-template.
  • OSPF обеспечивает резервирование и автоматический failover для туннеля SWE-HIPHOST.
  • Policy Based Routing (PBR) позволяет направлять трафик, предназначенный для Европы, через отдельную таблицу маршрутизации (EU), где основной маршрут — через GRE SWE-HIPHOST.

Пример конфигурации (RouterOS 7.14+)

# 1. Создаём таблицу маршрутизации для Европы
/routing table
add name=EU fib

# 2. Routing rule для европейского трафика (пример: по dst-address)
/routing rule
add dst-address=<EU_SUBNETS> action=lookup table=EU

# 3. В таблице EU маршрут по умолчанию через GRE SWE-HIPHOST
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.5.2 routing-table=EU distance=1

# 4. GRE SWE-HIPHOST добавлен в OSPF
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone
  • <EU_SUBNETS> — список европейских подсетей или диапазонов (можно использовать address-list и mangle для сложных случаев).

Преимущества

  • Оптимизация маршрутов: Европейский трафик идёт по кратчайшему пути через SWE-HIPHOST.
  • Резервирование: OSPF обеспечивает автоматический failover при недоступности туннеля.
  • Гибкость: Можно легко расширять список европейских подсетей или добавить резервные маршруты.

Рекомендации по неймингу CHR серверов

Грамотный нейминг серверов и шлюзов облегчает сопровождение, масштабирование и диагностику сети.

Рекомендуемая структура имени

Если у вас несколько хостеров/площадок в одном городе или стране, рекомендуется использовать следующий формат:

<город>.<площадка>.<роль>.<домен>
  • <город> — код города или страны (например, msk, swe)
  • <площадка> — название хостера или дата-центра (например, vpsville, ihor, hiphost)
  • <роль> — rt (router), gw (gateway), srv (server) и т.д.
  • <домен> — основной домен вашей инфраструктуры

Пример:

  • msk.vpsville.rt.shx.su — роутер в Москве, площадка VPSVILLE
  • msk.ihor.rt.shx.su — роутер в Москве, площадка IHOR
  • swe.hiphost.rt.shx.su — роутер в Швеции, площадка HIPHOST
  • home.rt.shx.su — домашний роутер

Примеры для вашей сети

Локация Имя сервера DNS имя Описание
Домашний home-gw home.rt.shx.su Домашний роутер
Москва IHOR msk-ihor-gw msk.ihor.rt.shx.su Роутер IHOR, Москва
Москва VPSVILLE msk-vpsville-gw msk.vpsville.rt.shx.su Роутер VPSVILLE, Москва
Швеция HIPHOST swe-hiphost-gw swe.hiphost.rt.shx.su Роутер HIPHOST, Швеция

Рекомендации

  • Используйте короткие, но однозначные аббревиатуры для локаций: msk (Москва), swe (Швеция), home (домашний роутер)
  • Для роли роутера используйте rt (router) вместо gw (gateway)
  • Если есть несколько провайдеров на одной площадке, добавляйте суффикс: msk-ihor-rt-rtk (Москва, IHOR, роутер, Ростелеком)
  • Для серверов без роутерной роли используйте, например, srv (server): msk-ihor-srv

Почему именно такой порядок? Если у вас несколько хостеров в одном городе, такой нейминг позволяет удобно группировать и искать объекты по локации, а внутри — по площадке. Это облегчает навигацию и масштабирование инфраструктуры.

Распределение IP-адресов между GRE туннелями между хостерами

Грамотное распределение IP-адресов между GRE-туннелями между хостерами (site-to-site) обеспечивает прозрачность, масштабируемость и отсутствие конфликтов.

Рекомендации

  • Выделяйте отдельный диапазон для межхостовых туннелей, например, 10.200.0.0/16.
  • Для каждого GRE-туннеля между двумя хостерами используйте отдельную /30 подсеть (2 usable IP).
  • Систематизируйте назначение подсетей (например, по ID площадок или по алфавиту).
  • Документируйте все туннели и адреса в README.

Пример схемы адресации для GRE между хостерами

Туннель Подсеть IP (левый хостер) IP (правый хостер)
msk.vpsville ↔ msk.ihor 10.200.0.0/30 10.200.0.1 10.200.0.2
msk.vpsville ↔ swe.hiphost 10.200.0.4/30 10.200.0.5 10.200.0.6
msk.ihor ↔ swe.hiphost 10.200.0.8/30 10.200.0.9 10.200.0.10
  • Для новых туннелей просто берите следующую свободную /30 из диапазона.
  • Такой подход облегчает масштабирование и поддержку сети.

Связывание московских серверов через OSPF

Для обеспечения отказоустойчивости и оптимизации маршрутов все московские серверы связаны через OSPF. Это обеспечивает автоматический failover между площадками и оптимальный выбор маршрутов.

Преимущества связывания московских серверов

  1. Автоматический failover между московскими площадками

    • Если VPSVILLE недоступен, трафик автоматически пойдет через IHOR
    • Если IHOR недоступен, трафик пойдет через VPSVILLE

  2. Оптимизация маршрутов

    • OSPF автоматически выберет кратчайший путь
    • Можно настроить разные cost для разных провайдеров

  3. Масштабируемость

    • Легко добавлять новые московские площадки
    • Автоматическое распространение маршрутов

Конфигурация GRE туннеля между московскими серверами

На VPSVILLE (msk.vpsville.rt.shx.su):

# Создание GRE туннеля к IHOR
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<IHOR_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/ip address add address=10.200.0.1/30 interface=gre-MSK-VPSVILLE-IHOR

# Добавление в OSPF
/routing ospf interface-template
add interfaces=gre-MSK-VPSVILLE-IHOR cost=10 area=backbone

На IHOR (msk.ihor.rt.shx.su):

# Создание GRE туннеля к VPSVILLE
/interface gre add name=gre-MSK-IHOR-VPSVILLE remote-address=<VPSVILLE_WAN_IP> local-address=<IHOR_WAN_IP>
/ip address add address=10.200.0.2/30 interface=gre-MSK-IHOR-VPSVILLE

# Добавление в OSPF
/routing ospf interface-template
add interfaces=gre-MSK-IHOR-VPSVILLE cost=10 area=backbone

На HOME (home.rt.shx.su):

# HOME не создает GRE туннели между серверами
# HOME только подключается к серверам по GRE и получает маршруты через OSPF

# OSPF настроен для получения маршрутов от серверов
/routing ospf interface-template
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone
add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone
add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone

# Policy routing для выбора нужного сервера/провайдера
/routing rule
add src-address=192.168.111.0/24 action=lookup table=MTS
add src-address=192.168.222.0/24 action=lookup table=MSK

Логика работы OSPF между московскими серверами

  1. Прямая связь между серверами: VPSVILLE ↔ IHOR через GRE туннель 10.200.0.0/30
  2. OSPF анонсирует маршруты: Каждый сервер анонсирует свои сети через OSPF
  3. HOME получает маршруты: HOME получает маршруты от обоих серверов через OSPF
  4. Автоматический failover: Если один сервер недоступен, OSPF убирает маршруты через него
  5. Оптимальные маршруты: OSPF выбирает кратчайший путь между серверами

Роль HOME в архитектуре

  • HOME - конечная точка: Подключается к серверам по GRE, но не участвует в межсерверной маршрутизации
  • Получение маршрутов: HOME получает маршруты от серверов через OSPF
  • Policy routing: HOME использует route tables для выбора нужного сервера/провайдера
  • Отправка трафика: HOME отправляет трафик по правилам маршрутизации

Пример маршрутизации

  • Трафик VPSVILLE → IHOR: Прямо через GRE туннель 10.200.0.0/30 (без участия HOME)
  • Трафик HOME → Интернет: Через VPSVILLE или IHOR согласно route tables
  • Трафик HOME → Европа: Через SWE-HIPHOST согласно policy routing

Мониторинг связей

# Проверка состояния GRE туннелей
/interface gre print

# Проверка OSPF соседей
/routing ospf neighbor print

# Проверка маршрутов
/ip route print
Reference in New Issue View Git Blame Copy Permalink
S
Description
No description provided
Readme
394 KiB
Languages
Markdown 100%