# SHX Network Infrastructure ## Обзор сети Данный проект описывает сетевую инфраструктуру с двумя провайдерами интернет-соединения и множественными GRE туннелями для обеспечения отказоустойчивости и географического распределения. ## Архитектура сети ### Основная схема (обновлено) ```mermaid 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
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 ``` ### Детальная схема туннелей (обновлено) ```mermaid 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
GRE Tunnel] RTK_VPS[MSK-VPSVILLE-RTK
GRE Tunnel] end subgraph "Москва - IHOR" MTS_IHOR[MSK-IHOR-MTS
GRE Tunnel] RTK_IHOR[MSK-IHOR-RTK
GRE Tunnel] end subgraph "Швеция - HIPHOST" MTS_HIP[SWE-HIPHOST-MTS
GRE Tunnel] RTK_HIP[SWE-HIPHOST-RTK
GRE Tunnel] end end subgraph "Удаленные серверы" VPS[VPSVILLE Server
Москва] IHR[IHOR Server
Москва] HIP["HIPHOST
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 ``` ### Схема европейского трафика (новая) ```mermaid graph TD subgraph "Москва" VPSVILLE_MSK[VPSVILLE
Москва] IHOR_MSK[IHOR
Москва] end subgraph "Швеция" HIPHOST_SWE["HIPHOST
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; ``` ### Схема отказоустойчивости (обновлено) ```mermaid graph TB subgraph "Основной путь" GW[Gateway] MTS[MТС - Основной] RTK[Ростелеком - Резервный] end subgraph "Туннели по приоритету" subgraph "VPSVILLE" VPS_MTS[MSK-VPSVILLE-MTS
Приоритет 1] VPS_RTK[MSK-VPSVILLE-RTK
Приоритет 2] end subgraph "IHOR" IHR_MTS[MSK-IHOR-MTS
Приоритет 1] IHR_RTK[MSK-IHOR-RTK
Приоритет 2] end subgraph "HIPHOST" HIP_MTS[SWE-HIPHOST-MTS
Приоритет 1] HIP_RTK[SWE-HIPHOST-RTK
Приоритет 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 ```shell /interface gre add name=gre-MSK-VPSVILLE-MTS remote-address= local-address= /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 ``` - `` — внешний 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 ```shell # 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= routing-table=MTS /ip firewall mangle add chain=prerouting src-address=192.168.111.0/24 action=mark-routing new-routing-mark=MTS # — адрес следующего хопа через МТС (например, 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 ```shell # 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+) ```shell # 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+) ```shell # 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 туннели (пример) ```shell /interface gre add name=gre-MSK-VPSVILLE-RTK remote-address= local-address= /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+) ```shell # 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+) ```shell /interface gre add name=gre-NEW-SITE remote-address= local-address= /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+) ```shell # 1. Создаём таблицу маршрутизации для Европы /routing table add name=EU fib # 2. Routing rule для европейского трафика (пример: по dst-address) /routing rule add dst-address= 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 ``` - `` — список европейских подсетей или диапазонов (можно использовать 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 из диапазона. - Такой подход облегчает масштабирование и поддержку сети. ---