617 lines
29 KiB
Markdown
617 lines
29 KiB
Markdown
# 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<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
|
||
```
|
||
|
||
### Детальная схема туннелей (обновлено)
|
||
|
||
```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<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
|
||
```
|
||
|
||
### Схема европейского трафика (новая)
|
||
|
||
```mermaid
|
||
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;
|
||
```
|
||
|
||
### Схема отказоустойчивости (обновлено)
|
||
|
||
```mermaid
|
||
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
|
||
|
||
```shell
|
||
/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
|
||
|
||
```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=<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
|
||
|
||
```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=<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+)
|
||
|
||
```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=<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+)
|
||
|
||
```shell
|
||
# 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 из диапазона.
|
||
- Такой подход облегчает масштабирование и поддержку сети.
|
||
|
||
--- |