infra/shx-network
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9 Commits 1 Branch 0 Tags
c234d043faa526cdcd85dbf5e9f37ff49a5aae75
T
Clone
Open with VS Code Open with VSCodium Open with Intellij IDEA
Download ZIP Download TAR.GZ Download BUNDLE
denozord c234d043fa update
2025-07-10 00:36:55 +07:00
README.md
update
2025-07-10 00:36:55 +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;

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

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 при недоступности туннеля.
  • Гибкость: Можно легко расширять список европейских подсетей или добавить резервные маршруты.
Reference in New Issue View Git Blame Copy Permalink
S
Description
No description provided
Readme
394 KiB
Languages
Markdown 100%