infra/shx-network
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
84f4398dcba29d4c849e6ab9ea1a255e5fe154fb
shx-network/README.md
T
denozord 84f4398dcb update
2025-07-11 07:14:17 +07:00

2309 lines
104 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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;
```
### Схема связывания московских серверов через OSPF (новая)
```mermaid
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
```
### Схема отказоустойчивости (обновлено)
```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
```
## Конфигурация туннелей
### Туннели от HOME к удаленным серверам
| Провайдер | Туннель | Назначение | Локация | Статус | Приоритет | Подсеть | HOME IP | Remote IP |
|-----------|---------|------------|---------|--------|-----------|---------|---------|-----------|
| **Ростелеком (RTK)** | MSK-VPSVILLE-RTK | Основной канал VPSVILLE | Москва | Активен | 1 (основной) | 10.100.2.0/30 | 10.100.2.1 | 10.100.2.2 |
| **Ростелеком (RTK)** | MSK-IHOR-RTK | Основной канал IHOR | Москва | Активен | 1 (основной) | 10.100.4.0/30 | 10.100.4.1 | 10.100.4.2 |
| **Ростелеком (RTK)** | SWE-HIPHOST-RTK | Основной канал HIPHOST | Швеция | Активен | 1 (основной) | 10.100.6.0/30 | 10.100.6.1 | 10.100.6.2 |
| **МТС (MTS)** | MSK-VPSVILLE-MTS | Резервный канал VPSVILLE | Москва | Активен | 2 (резервный) | 10.100.1.0/30 | 10.100.1.1 | 10.100.1.2 |
| **МТС (MTS)** | MSK-IHOR-MTS | Резервный канал IHOR | Москва | Активен | 2 (резервный) | 10.100.3.0/30 | 10.100.3.1 | 10.100.3.2 |
| **МТС (MTS)** | SWE-HIPHOST-MTS | Резервный канал HIPHOST | Швеция | Активен | 2 (резервный) | 10.100.5.0/30 | 10.100.5.1 | 10.100.5.2 |
## Преимущества архитектуры
| Преимущество | Описание | Практическое применение |
|--------------|----------|-------------------------|
| **Отказоустойчивость** | Два независимых провайдера обеспечивают непрерывность работы | Автоматический failover при отказе одного провайдера |
| **Географическое распределение** | Серверы в разных локациях (Москва, Швеция) | Оптимизация маршрутов и снижение задержек |
| **Балансировка нагрузки** | Возможность распределения трафика между провайдерами | Эффективное использование каналов |
| **Масштабируемость** | Легкое добавление новых туннелей и серверов | Простое расширение инфраструктуры |
## Мониторинг
| Компонент | Метод мониторинга | Цель |
|-----------|-------------------|------|
| **GRE туннели** | Отслеживание состояния всех GRE туннелей | Контроль связности |
| **Пропускная способность** | Мониторинг каналов | Оптимизация производительности |
| **Failover** | Автоматическое переключение при отказе основного канала | Обеспечение непрерывности |
| **Логирование** | События и статистика | Диагностика и анализ |
## Технические детали
| Параметр | Значение | Описание |
|----------|----------|----------|
| **Протокол** | GRE (Generic Routing Encapsulation) | Основной протокол туннелирования |
| **Шифрование** | IPSec (опционально) | Дополнительная защита трафика |
| **Мониторинг** | Keepalive пакеты | Контроль состояния туннелей |
| **Failover** | Автоматическое переключение при потере связи | Обеспечение отказоустойчивости |
---
## Рекомендации по адресации GRE туннелей
Для GRE туннелей рекомендуется использовать отдельный диапазон, например, `10.100.0.0/16`, чтобы избежать конфликтов с домашней сетью (`192.168.0.0/16`). Для каждого туннеля выделяется отдельная /30 подсеть (две точки).
### Полная схема адресации GRE туннелей
| Тип туннеля | Туннель | Подсеть | HOME IP | Remote IP | Провайдер | Приоритет | Описание |
|-------------|---------|---------|---------|-----------|-----------|-----------|----------|
| **HOME → Remote** | MSK-VPSVILLE-MTS | 10.100.1.0/30 | 10.100.1.1 | 10.100.1.2 | МТС | 2 (резервный) | Резервный канал VPSVILLE |
| **HOME → Remote** | MSK-VPSVILLE-RTK | 10.100.2.0/30 | 10.100.2.1 | 10.100.2.2 | Ростелеком | 1 (основной) | Основной канал VPSVILLE |
| **HOME → Remote** | MSK-IHOR-MTS | 10.100.3.0/30 | 10.100.3.1 | 10.100.3.2 | МТС | 2 (резервный) | Резервный канал IHOR |
| **HOME → Remote** | MSK-IHOR-RTK | 10.100.4.0/30 | 10.100.4.1 | 10.100.4.2 | Ростелеком | 1 (основной) | Основной канал IHOR |
| **HOME → Remote** | SWE-HIPHOST-MTS | 10.100.5.0/30 | 10.100.5.1 | 10.100.5.2 | МТС | 2 (резервный) | Резервный канал HIPHOST |
| **HOME → Remote** | SWE-HIPHOST-RTK | 10.100.6.0/30 | 10.100.6.1 | 10.100.6.2 | Ростелеком | 1 (основной) | Основной канал HIPHOST |
**Принцип**: Домашний шлюз всегда получает первый IP (.1), удаленные серверы - второй (.2)
### Принцип адресации GRE туннелей
**Правило**: Домашний шлюз всегда получает первый IP (.1), удаленные серверы - второй (.2)
**Преимущества такого подхода:**
- **Логическая последовательность**: HOME - точка входа в сеть, логично дать ему первый IP
- **Консистентность**: Все туннели от HOME имеют одинаковую схему адресации
- **Упрощение конфигурации**: Легче запомнить и настроить (HOME всегда .1)
- **Масштабируемость**: При добавлении новых туннелей схема остается понятной
- **Устранение путаницы**: Нет вопросов "кто где" - HOME всегда .1, серверы всегда .2
**Пример конфигурации на HOME:**
```shell
# Все GRE туннели на HOME получают .1 адрес
/ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS
/ip address add address=10.100.2.1/30 interface=gre-MSK-VPSVILLE-RTK
/ip address add address=10.100.3.1/30 interface=gre-MSK-IHOR-MTS
/ip address add address=10.100.4.1/30 interface=gre-MSK-IHOR-RTK
```
**Пример конфигурации на серверах:**
```shell
# Все серверы получают .2 адрес в своих туннелях
/ip address add address=10.100.1.2/30 interface=gre-MSK-VPSVILLE-MTS
/ip address add address=10.100.2.2/30 interface=gre-MSK-VPSVILLE-RTK
```
### Безопасность и маршрутизация на 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
# Ростелеком (основной провайдер) - низкий 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
# МТС (резервный провайдер) - высокий cost
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=10).
- Если основной канал падает, трафик автоматически пойдёт через МТС (резервный провайдер, cost=100).
- Для 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
# Ростелеком (основной провайдер) - низкий 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
# МТС (резервный провайдер) - высокий cost
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 # HomeLab трафик через МТС (резервный)
# 2. Routing rules для выбора таблицы по источнику
/routing rule
add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС (резервный)
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 | Gateway | Домашний роутер |
| Москва IHOR | msk-ihor-gw | msk.ihor.rt.shx.su | Router | Роутер IHOR, Москва |
| Москва VPSVILLE | msk-vpsville-gw | msk.vpsville.rt.shx.su | Router | Роутер VPSVILLE, Москва |
| Швеция HIPHOST | swe-hiphost-gw | swe.hiphost.rt.shx.su | Router | Роутер 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 между хостерами
| Туннель | Подсеть | Сервер A | IP A | Сервер B | IP B | Описание |
|---------|---------|----------|------|----------|------|----------|
| gre-MSK-VPSVILLE-IHOR | 10.200.0.0/30 | MSK-VPSVILLE | 10.200.0.1 | MSK-IHOR | 10.200.0.2 | VPSVILLE ↔ IHOR |
| gre-SWE-HIPHOST | 10.200.1.0/30 | MSK-VPSVILLE | 10.200.1.1 | SWE-HIPHOST | 10.200.1.2 | VPSVILLE ↔ SWE |
| gre-SWE-HIPHOST | 10.200.2.0/30 | MSK-IHOR | 10.200.2.1 | SWE-HIPHOST | 10.200.2.2 | IHOR ↔ SWE |
- Для новых туннелей просто берите следующую свободную /30 из диапазона.
- Такой подход облегчает масштабирование и поддержку сети.
---
## Связывание московских серверов через OSPF
Для обеспечения отказоустойчивости и оптимизации маршрутов все московские серверы связаны через OSPF. Это обеспечивает автоматический failover между площадками и оптимальный выбор маршрутов.
### Преимущества связывания московских серверов
1. **Автоматический failover между московскими площадками**
- Если VPSVILLE недоступен, трафик автоматически пойдет через IHOR
- Если IHOR недоступен, трафик пойдет через VPSVILLE
2. **Оптимизация маршрутов**
- OSPF автоматически выберет кратчайший путь
- Можно настроить разные cost для разных провайдеров
3. **Масштабируемость**
- Легко добавлять новые московские площадки
- Автоматическое распространение маршрутов
### Конфигурация GRE туннеля между московскими серверами
#### На VPSVILLE (msk.vpsville.rt.shx.su):
```shell
# Создание 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):
```shell
# Создание 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):
```shell
# HOME не создает GRE туннели между серверами
# HOME только подключается к серверам по GRE и получает маршруты через OSPF
# OSPF настроен для получения маршрутов от серверов
/routing ospf interface-template
# Ростелеком (основной провайдер) - низкий cost
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone
add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone
# МТС (резервный провайдер) - высокий cost
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 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 # HomeLab → МТС (резервный)
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
### Мониторинг связей
```shell
# Проверка состояния GRE туннелей
/interface gre print
# Проверка OSPF соседей
/routing ospf neighbor print
# Проверка маршрутов
/ip route print
```
---
## OSPF и дублирование маршрутов
При использовании OSPF между серверами может происходить дублирование маршрутов в таблице маршрутизации. Это нормальное поведение, но важно понимать, как это контролировать.
### Как работает дублирование маршрутов
1. **OSPF анонсирует маршруты**: Каждый сервер анонсирует свои сети через OSPF
2. **Множественные пути**: HOME может получить маршрут до одной сети через разные серверы
3. **Distance и cost**: OSPF использует cost для выбора оптимального пути, но может создавать резервные маршруты
### Пример дублирования маршрутов
```shell
# На HOME может быть несколько маршрутов до одной сети:
/ip route print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC, r - RIP, m - MODEM, b - BGP, o - OSPF, M - MME, B - BLACKHOLE, U - UNREACHABLE, F - FIB, v - VPLS, V - VRF, l - LISP, a - BFD, M - MME, t - TTLS, I - IDE, W - WINBOX, X - XAUTH, g - 7GRE, S - SNAT
Columns: DST-ADDRESS, GATEWAY, DISTANCE
# DST-ADDRESS GATEWAY DISTANCE
0 A s 0.0.0.0/0 10.100.2.2 1 # Через VPSVILLE-RTK (основной)
1 A s 0.0.0.0/0 10.100.4.2 1 # Через IHOR-RTK (основной)
2 A s 0.0.0.0/0 10.100.1.2 2 # Через VPSVILLE-MTS (резервный)
3 A s 0.0.0.0/0 10.100.3.2 2 # Через IHOR-MTS (резервный)
```
### Контроль дублирования через OSPF cost
```shell
# Настройка разных cost для приоритизации маршрутов
/routing ospf interface-template
# Ростелеком (основной провайдер) - низкий cost
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone
add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone
# МТС (резервный провайдер) - высокий cost
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone
add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone
```
### Использование route tables для разделения трафика
```shell
# Создание отдельных таблиц маршрутизации
/routing table
add name=MSK fib # Основной трафик через Ростелеком
add name=MTS fib # HomeLab трафик через МТС (резервный)
# Routing rules для выбора таблицы
/routing rule
add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС (резервный)
add src-address=192.168.222.0/24 action=lookup table=MSK # Основной трафик → Ростелеком
# В каждой таблице будет свой набор маршрутов
# OSPF автоматически добавит маршруты в соответствующие таблицы
```
### Преимущества дублирования маршрутов
1. **Автоматический failover**: Если основной маршрут недоступен, используется резервный
2. **Load balancing**: Можно настроить балансировку нагрузки между маршрутами
3. **Отказоустойчивость**: Сеть продолжает работать даже при отказе части каналов
### Мониторинг дублирования
```shell
# Просмотр всех маршрутов с деталями
/ip route print detail
# Просмотр OSPF маршрутов
/routing ospf route print
# Проверка активных маршрутов
/ip route print where active=yes
```
---
## Настройка OSPF для анонса только 0.0.0.0/0 (RouterOS 7.14+)
Для того чтобы удаленные серверы анонсировали только маршрут по умолчанию (0.0.0.0/0) через OSPF, нужно настроить Redistribute с Out filter. В RouterOS 7.14+ команда `/routing ospf network` больше не используется.
### Конфигурация на удаленных серверах (VPSVILLE, IHOR, HIPHOST)
#### 1. Создание Out filter для OSPF
```shell
# Создание фильтра, который пропускает только 0.0.0.0/0
/routing filter
add name=ospf-out-default-only chain=output protocol=ospf rule="if (dst-address=0.0.0.0/0) { accept } else { reject }"
```
#### 2. Настройка OSPF Redistribute с фильтром (основной способ для RouterOS 7.14+)
```shell
# Настройка OSPF instance для redistribute
/routing ospf instance
set [ find default=yes ] redistribute=connected,static
# Применение фильтра к OSPF
/routing ospf instance
set [ find default=yes ] out-filter=ospf-out-default-only
```
#### 2a. Альтернативный способ без routing filters
```shell
# Настройка OSPF instance только для redistribute connected
/routing ospf instance
set [ find default=yes ] redistribute=connected
# Или только для redistribute static (если 0.0.0.0/0 - статический маршрут)
/routing ospf instance
set [ find default=yes ] redistribute=static
```
#### 3. Альтернативный способ через OSPF networks (RouterOS 6.x)
```shell
# В RouterOS 6.x можно было использовать networks
/routing ospf network
add network=0.0.0.0/0 area=backbone
# В RouterOS 7.14+ эта команда больше не используется
# Вместо неё используется redistribute с фильтрами
```
### Конфигурация на HOME
#### 1. Создание In filter для OSPF (опционально)
```shell
# Фильтр для входящих OSPF маршрутов (если нужна дополнительная фильтрация)
/routing filter
add name=ospf-in-default-only chain=input protocol=ospf rule="if (dst-address=0.0.0.0/0) { accept } else { reject }"
# Применение фильтра к OSPF instance
/routing ospf instance
set [ find default=yes ] in-filter=ospf-in-default-only
```
### Проверка конфигурации
```shell
# Проверка OSPF маршрутов на удаленном сервере
/routing ospf route print
# Проверка OSPF маршрутов на HOME
/routing ospf route print
# Проверка таблицы маршрутизации на HOME
/ip route print where protocol=ospf
```
### Пример полной конфигурации на удаленном сервере (RouterOS 7.14+)
#### Способ 1: С фильтром (если работает)
```shell
# 1. Создание фильтра для анонса только 0.0.0.0/0
/routing filter
add name=ospf-out-default-only chain=output protocol=ospf rule="if (dst-address=0.0.0.0/0) { accept } else { reject }"
# 2. Настройка OSPF instance с redistribute и фильтром
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.2 redistribute=connected,static out-filter=ospf-out-default-only
# 3. Добавление GRE интерфейсов в 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
# 4. Проверка что только 0.0.0.0/0 анонсируется
/routing ospf route print
```
#### Способ 2: Без фильтров (простой)
```shell
# 1. Настройка OSPF instance только для redistribute connected
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.2 redistribute=connected
# 2. Добавление GRE интерфейсов в 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
# 3. Проверка анонсируемых маршрутов
/routing ospf route print
```
#### Способ 3: Только статические маршруты
```shell
# 1. Настройка OSPF instance только для redistribute static
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.2 redistribute=static
# 2. Добавление GRE интерфейсов в 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
# 3. Проверка анонсируемых маршрутов
/routing ospf route print
```
#### Способ 4: Простой статический маршрут (гарантированно работает)
```shell
# 1. Добавление статического маршрута 0.0.0.0/0 через SWE-HIPHOST-MTS
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1
# 2. Настройка OSPF instance для redistribute static
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.2 redistribute=static
# 3. Добавление GRE интерфейсов в OSPF
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone
# 4. Проверка что маршрут анонсируется
/routing ospf route print
```
#### Способ 5: Самый простой - без OSPF
```shell
# Просто добавить статический маршрут на HOME
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 routing-table=EU
# Или для основной таблицы
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1
```
### Логика работы
1. **Удаленный сервер** имеет маршрут по умолчанию (0.0.0.0/0) в своей таблице
2. **Redistribute** анонсирует маршруты через OSPF (с фильтром или без)
3. **HOME** получает маршруты от удаленного сервера
4. **OSPF** выбирает оптимальный путь на основе cost
### Выбор способа настройки OSPF
| Способ | Метод | Преимущества | Недостатки | Рекомендация |
|--------|-------|--------------|------------|--------------|
| **Способ 1** | С фильтром | Точный контроль, только нужные маршруты | Сложнее настройка, может не работать в некоторых версиях | Для опытных |
| **Способ 2** | redistribute=connected | Простая настройка, работает стабильно | Анонсирует все connected маршруты | **Рекомендуемый** |
| **Способ 3** | redistribute=static | Простая настройка, только статические маршруты | Анонсирует все статические маршруты | Если 0.0.0.0/0 статический |
| **Способ 4** | Простой статический маршрут | Гарантированно работает, простой | Нужно вручную добавить маршрут | Самый надежный |
### Преимущества такого подхода
| Преимущество | Описание | Влияние |
|--------------|----------|---------|
| **Чистая таблица маршрутизации** | Только нужные маршруты (при использовании фильтров) | Упрощение диагностики |
| **Контроль трафика** | Можно точно указать, какие маршруты анонсировать | Безопасность и производительность |
| **Безопасность** | Не раскрываются внутренние сети удаленных серверов | Защита от несанкционированного доступа |
| **Производительность** | Меньше маршрутов = быстрее обработка | Оптимизация работы роутера |
| **Простота** | Можно обойтись без сложных фильтров | Легкость настройки и поддержки |
---
## Конкретное решение: Маршрут 0.0.0.0/0 через SWE-HIPHOST-MTS
### На SWE-HIPHOST (удаленный сервер):
#### Способ 1: С фильтрацией AWS metadata (рекомендуемый)
```shell
# 1. Маршрут 0.0.0.0/0 уже есть (получен через DHCP)
# Проверить текущие маршруты:
/ip route print
# 2. Создать фильтр для исключения AWS metadata
/routing filter
add name=ospf-out-no-aws chain=output protocol=ospf rule="if (dst-address=169.254.169.254/32) { reject } else { accept }"
# 3. Настроить OSPF с фильтром
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.5 redistribute=connected out-filter=ospf-out-no-aws
# 4. Добавить GRE интерфейс в OSPF
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone
# 5. Проверить что маршрут анонсируется
/routing ospf route print
```
#### Способ 2: Без фильтрации (если фильтры не работают)
```shell
# 1. Проверить текущие маршруты:
/ip route print
# 2. Настроить OSPF для redistribute connected
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.5 redistribute=connected
# 3. Добавить GRE интерфейс в OSPF
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone
# 4. Проверить что маршрут анонсируется
/routing ospf route print
```
### На HOME:
```shell
# 1. Добавить GRE интерфейс в OSPF
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone
# 2. Проверить получение маршрута
/routing ospf route print
# 3. Проверить таблицу маршрутизации
/ip route print where protocol=ospf
```
### Альтернатива - статический маршрут на HOME:
```shell
# Если OSPF не работает, просто добавить статический маршрут
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1
# Или для отдельной таблицы маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 routing-table=EU
```
---
## Настройка OSPF cost для failover между серверами
Для того чтобы OSPF cost работал и один маршрут заменялся другим в зависимости от cost, нужно настроить OSPF на всех серверах, которые анонсируют маршруты.
### Конфигурация на SWE-HIPHOST (анонсирует маршрут 0.0.0.0/0):
```shell
# 1. Создать фильтр для исключения AWS metadata
/routing filter
add name=ospf-out-no-aws chain=output protocol=ospf rule="if (dst-address=169.254.169.254/32) { reject } else { accept }"
# 2. Настроить OSPF с фильтром и redistribute
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.5 redistribute=connected out-filter=ospf-out-no-aws
# 3. Создать area (если не существует)
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 4. Добавить GRE интерфейсы в OSPF с разным cost
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # Основной канал
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # Резервный канал
# 5. Проверить что маршрут анонсируется
/routing ospf route print
```
### Конфигурация на MSK-VPSVILLE (анонсирует маршрут 0.0.0.0/0):
```shell
# 1. Создать фильтр для исключения AWS metadata (если есть)
/routing filter
add name=ospf-out-no-aws chain=output protocol=ospf rule="if (dst-address=169.254.169.254/32) { reject } else { accept }"
# 2. Настроить OSPF с фильтром и redistribute
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.2 redistribute=connected out-filter=ospf-out-no-aws
# 3. Создать area (если не существует)
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 4. Добавить GRE интерфейсы в OSPF с разным cost
/routing ospf interface-template
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone # Основной канал
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # Резервный канал
# 5. Проверить что маршрут анонсируется
/routing ospf route print
```
### Конфигурация на HOME (получает маршруты):
```shell
# 1. Создать area (если не существует)
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 2. Добавить все GRE интерфейсы в OSPF с соответствующим cost
/routing ospf interface-template
# Ростелеком (основной провайдер) - низкий cost
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
# МТС (резервный провайдер) - высокий cost
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
# 3. Проверить полученные маршруты
/routing ospf route print
# 4. Проверить таблицу маршрутизации
/ip route print where protocol=ospf
```
### Логика работы OSPF cost:
1. **SWE-HIPHOST** анонсирует маршрут 0.0.0.0/0 через оба канала:
- gre-SWE-HIPHOST-RTK (cost=10) - основной
- gre-SWE-HIPHOST-MTS (cost=100) - резервный
2. **MSK-VPSVILLE** анонсирует маршрут 0.0.0.0/0 через оба канала:
- gre-MSK-VPSVILLE-RTK (cost=10) - основной
- gre-MSK-VPSVILLE-MTS (cost=100) - резервный
3. **HOME** получает маршруты от обоих серверов и выбирает оптимальный путь на основе cost
4. **Автоматический failover**: Если основной канал падает, OSPF автоматически переключается на резервный
### Настройка OSPF Area
**Важно**: Все устройства должны использовать одинаковую area для корректной работы OSPF.
#### Вариант 1: Одна area (рекомендуемый для простых сетей)
```shell
# На всех устройствах (HOME, SWE-HIPHOST, MSK-VPSVILLE, MSK-IHOR):
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# Или использовать существующую area:
/routing ospf area print
# Если area уже создана, используйте её имя
```
#### Вариант 2: Создание новой area
```shell
# На всех устройствах создать одинаковую area:
/routing ospf area
add name=main-area instance=default area-id=0.0.0.1
# Затем использовать её в interface-template:
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=main-area
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=main-area
```
#### Проверка area настройки:
```shell
# Проверить существующие area:
/routing ospf area print
# Проверить OSPF соседей:
/routing ospf neighbor print
# Проверить что соседи в одной area:
/routing ospf neighbor print detail
```
---
## Оптимальная схема OSPF Areas для вашей сети
### Рекомендуемая архитектура Areas
Для вашей сети с несколькими локациями и провайдерами рекомендуется использовать **многоуровневую схему areas**:
#### Схема 1: Простая (рекомендуемая для начала)
```
Area 0.0.0.0 (Backbone) - все устройства
├── HOME (home.rt.shx.su)
├── MSK-VPSVILLE (msk.vpsville.rt.shx.su)
├── MSK-IHOR (msk.ihor.rt.shx.su)
└── SWE-HIPHOST (swe.hiphost.rt.shx.su)
```
#### Схема 2: По локациям (для масштабирования)
```
Area 0.0.0.0 (Backbone) - HOME
├── Area 0.0.0.1 (MSK) - московские серверы
│ ├── MSK-VPSVILLE
│ └── MSK-IHOR
└── Area 0.0.0.2 (SWE) - шведский сервер
└── SWE-HIPHOST
```
#### Схема 3: По провайдерам (для изоляции)
```
Area 0.0.0.0 (Backbone) - HOME
├── Area 0.0.0.10 (RTK) - Ростелеком туннели
│ ├── MSK-VPSVILLE-RTK
│ ├── MSK-IHOR-RTK
│ └── SWE-HIPHOST-RTK
└── Area 0.0.0.20 (MTS) - МТС туннели
├── MSK-VPSVILLE-MTS
├── MSK-IHOR-MTS
└── SWE-HIPHOST-MTS
```
### Рекомендация: Начните с простой схемы
Для вашей текущей сети **рекомендую начать с Схемы 1** (одна area):
#### Конфигурация для Схемы 1:
```shell
# На всех устройствах (HOME, MSK-VPSVILLE, MSK-IHOR, SWE-HIPHOST):
# 1. Создать backbone area
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 2. Добавить все GRE интерфейсы в backbone area
/routing ospf interface-template
# Ростелеком (основной провайдер) - низкий cost
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
# МТС (резервный провайдер) - высокий cost
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
```
### Преимущества простой схемы (Area 0.0.0.0):
1. **Простота настройки**: Все устройства в одной area
2. **Быстрая конвергенция**: Нет меж-area маршрутизации
3. **Простота отладки**: Легче диагностировать проблемы
4. **Совместимость**: Работает с любыми версиями RouterOS
### Когда переходить на сложные схемы:
#### Переход на Схему 2 (по локациям) если:
- У вас будет больше московских серверов (5+)
- Нужна изоляция московского трафика
- Планируется добавление других стран
#### Переход на Схему 3 (по провайдерам) если:
- Нужна полная изоляция трафика по провайдерам
- Планируется добавление третьего провайдера
- Требуется сложная политика маршрутизации
### Конфигурация для Схемы 2 (по локациям):
```shell
# На HOME (Area 0.0.0.0 - Backbone):
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
add name=msk-area instance=default area-id=0.0.0.1
add name=swe-area instance=default area-id=0.0.0.2
# На MSK-VPSVILLE и MSK-IHOR (Area 0.0.0.1 - MSK):
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
add name=msk-area instance=default area-id=0.0.0.1
# На SWE-HIPHOST (Area 0.0.0.2 - SWE):
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
add name=swe-area instance=default area-id=0.0.0.2
```
### Конфигурация для Схемы 3 (по провайдерам):
```shell
# На всех устройствах:
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
add name=rtk-area instance=default area-id=0.0.0.10
add name=mts-area instance=default area-id=0.0.0.20
# Ростелеком туннели в rtk-area:
/routing ospf interface-template
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=rtk-area
add interfaces=gre-MSK-IHOR-RTK cost=10 area=rtk-area
add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=rtk-area
# МТС туннели в mts-area:
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=mts-area
add interfaces=gre-MSK-IHOR-MTS cost=100 area=mts-area
add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=mts-area
```
### Проверка конфигурации Areas:
```shell
# Проверить все areas
/routing ospf area print
# Проверить интерфейсы в каждой area
/routing ospf interface-template print
# Проверить соседей и их areas
/routing ospf neighbor print detail
# Проверить маршруты по areas
/routing ospf route print
```
### Рекомендации по выбору Area ID:
| Area ID | Назначение | Описание |
|---------|------------|----------|
| 0.0.0.0 | Backbone area | Основная area (обязательно) |
| 0.0.0.1 | Первая обычная area | Для простых сетей |
| 0.0.0.2 | Вторая обычная area | Для расширенных сетей |
| 0.0.0.10 | Area для Ростелеком | Изоляция трафика Ростелеком |
| 0.0.0.20 | Area для МТС | Изоляция трафика МТС |
| 0.0.0.100 | Area для Москвы | Изоляция московского трафика |
| 0.0.0.200 | Area для Швеции | Изоляция шведского трафика |
### Миграция с простой схемы на сложную:
```shell
# Шаг 1: Добавить новые areas
/routing ospf area
add name=msk-area instance=default area-id=0.0.0.1
# Шаг 2: Изменить area для московских интерфейсов
/routing ospf interface-template
set [ find where interfaces=gre-MSK-VPSVILLE-RTK ] area=msk-area
set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] area=msk-area
# Шаг 3: Проверить что OSPF работает
/routing ospf neighbor print
```
---
## Архитектура: Московские серверы как единый OSPF кластер
### Концепция
Все московские серверы (MSK-VPSVILLE, MSK-IHOR) объединены в единый OSPF кластер. Если на одном из них падает GRE туннель к SWE-HIPHOST, весь трафик автоматически идет через другой сервер.
### Схема архитектуры
```mermaid
graph TB
subgraph "Москва - OSPF кластер"
VPSVILLE[MSK-VPSVILLE<br/>msk.vpsville.rt.shx.su]
IHOR[MSK-IHOR<br/>msk.ihor.rt.shx.su]
end
subgraph "Швеция"
HIPHOST[SWE-HIPHOST<br/>swe.hiphost.rt.shx.su]
end
subgraph "Домашний шлюз"
HOME[HOME<br/>home.rt.shx.su]
end
%% GRE туннели от HOME к московским серверам
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 туннели от московских серверов к SWE-HIPHOST
VPSVILLE -- "GRE SWE-HIPHOST<br/>10.200.1.0/30" --> HIPHOST
IHOR -- "GRE SWE-HIPHOST<br/>10.200.2.0/30" --> HIPHOST
%% 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 HIPHOST fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff
style HOME fill:#e0e0e0,stroke:#9e9e9e,stroke-width:2px,color:#000
```
### Конфигурация на московских серверах
#### На MSK-VPSVILLE (msk.vpsville.rt.shx.su):
```shell
# 1. GRE туннель к SWE-HIPHOST (межсерверный туннель)
/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/ip address add address=10.200.1.1/30 interface=gre-SWE-HIPHOST
# 2. GRE туннель к MSK-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
# 3. OSPF конфигурация
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 4. Добавить все интерфейсы в OSPF
/routing ospf interface-template
# Интерфейсы к HOME
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone
# Интерфейс к SWE-HIPHOST
add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
# Интерфейс к MSK-IHOR
add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone
# 5. Анонсировать маршрут 0.0.0.0/0 через SWE-HIPHOST
/ip route add dst-address=0.0.0.0/0 gateway=10.200.1.2 distance=1
# 6. OSPF redistribute
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.2 redistribute=connected,static
```
#### На MSK-IHOR (msk.ihor.rt.shx.su):
```shell
# 1. GRE туннель к SWE-HIPHOST (межсерверный туннель)
/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<IHOR_WAN_IP>
/ip address add address=10.200.2.1/30 interface=gre-SWE-HIPHOST
# 2. GRE туннель к MSK-VPSVILLE (межсерверный туннель)
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<VPSVILLE_WAN_IP> local-address=<IHOR_WAN_IP>
/ip address add address=10.200.0.2/30 interface=gre-MSK-VPSVILLE-IHOR
# 3. OSPF конфигурация
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 4. Добавить все интерфейсы в OSPF
/routing ospf interface-template
# Интерфейсы к HOME
add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone
add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone
# Интерфейс к SWE-HIPHOST
add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
# Интерфейс к MSK-VPSVILLE
add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone
# 5. Анонсировать маршрут 0.0.0.0/0 через SWE-HIPHOST
/ip route add dst-address=0.0.0.0/0 gateway=10.200.2.2 distance=1
# 6. OSPF redistribute
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.3 redistribute=connected,static
```
### Конфигурация на SWE-HIPHOST (swe.hiphost.rt.shx.su):
```shell
# 1. GRE туннели от московских серверов (межсерверные туннели)
/interface gre add name=gre-SWE-HIPHOST remote-address=<VPSVILLE_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.200.1.2/30 interface=gre-SWE-HIPHOST
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<IHOR_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.200.2.2/30 interface=gre-MSK-VPSVILLE-IHOR
# 2. OSPF конфигурация
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 3. Добавить интерфейсы в OSPF
/routing ospf interface-template
add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
add interfaces=gre-MSK-VPSVILLE-IHOR cost=10 area=backbone
# 4. OSPF redistribute (маршрут 0.0.0.0/0 получен через DHCP)
/routing ospf instance
set [ find default=yes ] router-id=10.100.0.5 redistribute=connected
```
### Конфигурация на HOME (home.rt.shx.su):
```shell
# 1. OSPF конфигурация
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0
# 2. Добавить интерфейсы к московским серверам в OSPF
/routing ospf interface-template
# Ростелеком (основной провайдер) - низкий cost
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone
add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone
# МТС (резервный провайдер) - высокий cost
add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone
add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone
# 3. Policy routing для выбора сервера
/routing rule
add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС
add src-address=192.168.222.0/24 action=lookup table=MSK # Основной трафик → Ростелеком
```
### Межсерверные туннели (OSPF кластер)
| Туннель | Подсеть | Сервер A | IP A | Сервер B | IP B | Описание | OSPF Cost |
|---------|---------|----------|------|----------|------|----------|-----------|
| gre-SWE-HIPHOST | 10.200.1.0/30 | MSK-VPSVILLE | 10.200.1.1 | SWE-HIPHOST | 10.200.1.2 | VPSVILLE ↔ SWE | 10 |
| gre-SWE-HIPHOST | 10.200.2.0/30 | MSK-IHOR | 10.200.2.1 | SWE-HIPHOST | 10.200.2.2 | IHOR ↔ SWE | 10 |
| gre-MSK-VPSVILLE-IHOR | 10.200.0.0/30 | MSK-VPSVILLE | 10.200.0.1 | MSK-IHOR | 10.200.0.2 | VPSVILLE ↔ IHOR | 5 |
**Примечание**: Все межсерверные туннели используют диапазон 10.200.0.0/16, что обеспечивает четкое разделение от туннелей HOME (10.100.0.0/16).
### Единая система именования межсерверных туннелей
Для удобства массовой рассылки статических списков маршрутизации все межсерверные туннели используют единые названия:
#### Принцип именования:
- **gre-SWE-HIPHOST** - все туннели к SWE-HIPHOST (от VPSVILLE и IHOR)
- **gre-MSK-VPSVILLE-IHOR** - все туннели между московскими серверами и к IHOR
#### Преимущества единого именования:
1. **Массовая настройка**: Одинаковые команды для всех серверов
2. **Упрощение скриптов**: Можно использовать шаблоны конфигурации
3. **Единообразие**: Легче поддерживать и документировать
4. **Масштабируемость**: При добавлении новых серверов схема остается понятной
#### Пример массовой рассылки конфигурации:
```shell
# Шаблон для всех серверов с туннелем gre-SWE-HIPHOST
/interface gre add name=gre-SWE-HIPHOST remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/30 interface=gre-SWE-HIPHOST
/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
# Шаблон для всех серверов с туннелем gre-MSK-VPSVILLE-IHOR
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/30 interface=gre-MSK-VPSVILLE-IHOR
/routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone
```
### Логика разделения адресов на диапазоны
#### Диапазон 10.100.0.0/16 - Туннели от HOME
- **Назначение**: Все GRE туннели, которые создает HOME (домашний шлюз)
- **Принцип**: HOME всегда инициирует туннели к удаленным серверам
- **Примеры**:
- MSK-VPSVILLE-RTK (10.100.2.0/30) - HOME → VPSVILLE через Ростелеком
- MSK-VPSVILLE-MTS (10.100.1.0/30) - HOME → VPSVILLE через МТС
- MSK-IHOR-RTK (10.100.4.0/30) - HOME → IHOR через Ростелеком
- MSK-IHOR-MTS (10.100.3.0/30) - HOME → IHOR через МТС
- SWE-HIPHOST-RTK (10.100.6.0/30) - HOME → HIPHOST через Ростелеком
- SWE-HIPHOST-MTS (10.100.5.0/30) - HOME → HIPHOST через МТС
#### Диапазон 10.200.0.0/16 - Межсерверные туннели
- **Назначение**: GRE туннели между серверами (без участия HOME)
- **Принцип**: Серверы создают туннели друг к другу для OSPF связности
- **Примеры**:
- MSK-VPSVILLE ↔ MSK-IHOR (10.200.0.0/30) - связь между московскими серверами
- MSK-VPSVILLE ↔ SWE-HIPHOST (10.200.1.0/30) - связь VPSVILLE → SWE
- MSK-IHOR ↔ SWE-HIPHOST (10.200.2.0/30) - связь IHOR → SWE
### Альтернативный подход: Единый диапазон
Если хотите использовать единый диапазон 10.100.0.0/16 для всех туннелей:
| Туннель | Подсеть | IP (левый сервер) | IP (правый сервер) | Описание |
|--------------------------------|-----------------|-------------------|--------------------|----------|
| MSK-VPSVILLE ↔ SWE-HIPHOST | 10.100.7.0/30 | 10.100.7.1 | 10.100.7.2 | VPSVILLE → SWE |
| MSK-IHOR ↔ SWE-HIPHOST | 10.100.8.0/30 | 10.100.8.1 | 10.100.8.2 | IHOR → SWE |
| MSK-VPSVILLE ↔ MSK-IHOR | 10.100.9.0/30 | 10.100.9.1 | 10.100.9.2 | Межсерверная связь |
### Рекомендация: Единый диапазон
**Рекомендую использовать единый диапазон 10.100.0.0/16** для всех туннелей:
| Тип туннеля | Туннель | Подсеть | Описание |
|-------------|---------|---------|----------|
| **HOME → Remote** | MSK-VPSVILLE-MTS | 10.100.1.0/30 | HOME → VPSVILLE (МТС) |
| **HOME → Remote** | MSK-VPSVILLE-RTK | 10.100.2.0/30 | HOME → VPSVILLE (Ростелеком) |
| **HOME → Remote** | MSK-IHOR-MTS | 10.100.3.0/30 | HOME → IHOR (МТС) |
| **HOME → Remote** | MSK-IHOR-RTK | 10.100.4.0/30 | HOME → IHOR (Ростелеком) |
| **HOME → Remote** | SWE-HIPHOST-MTS | 10.100.5.0/30 | HOME → HIPHOST (МТС) |
| **HOME → Remote** | SWE-HIPHOST-RTK | 10.100.6.0/30 | HOME → HIPHOST (Ростелеком) |
| **Server ↔ Server** | gre-SWE-HIPHOST | 10.100.7.0/30 | VPSVILLE ↔ SWE |
| **Server ↔ Server** | gre-SWE-HIPHOST | 10.100.8.0/30 | IHOR ↔ SWE |
| **Server ↔ Server** | gre-MSK-VPSVILLE-IHOR | 10.100.9.0/30 | VPSVILLE ↔ IHOR |
**Преимущества единого диапазона:**
1. **Простота**: Все туннели в одном диапазоне
2. **Логичность**: Последовательная нумерация
3. **Масштабируемость**: Легко добавлять новые туннели
4. **Документирование**: Проще вести учет адресов
### Логика работы failover
1. **Нормальная работа**:
- HOME получает маршрут 0.0.0.0/0 от MSK-VPSVILLE через OSPF
- MSK-VPSVILLE имеет GRE туннель gre-SWE-HIPHOST к SWE-HIPHOST (10.200.1.0/30)
2. **Отказ GRE туннеля gre-SWE-HIPHOST на MSK-VPSVILLE**:
- MSK-VPSVILLE больше не может достичь SWE-HIPHOST через gre-SWE-HIPHOST
- MSK-VPSVILLE убирает маршрут 0.0.0.0/0 из OSPF
- HOME получает маршрут 0.0.0.0/0 от MSK-IHOR через OSPF
- Весь трафик идет через MSK-IHOR → gre-SWE-HIPHOST → SWE-HIPHOST (10.200.2.0/30)
3. **Автоматическое восстановление**:
- Когда GRE туннель gre-SWE-HIPHOST на MSK-VPSVILLE восстанавливается
- MSK-VPSVILLE снова анонсирует маршрут 0.0.0.0/0
- OSPF выбирает оптимальный путь (обычно через MSK-VPSVILLE)
### Преимущества этой архитектуры
1. **Полная отказоустойчивость**: Если один московский сервер теряет связь с SWE-HIPHOST, трафик идет через другой
2. **Автоматический failover**: OSPF автоматически переключает маршруты
3. **Быстрое восстановление**: При восстановлении связи автоматически возвращается к оптимальному маршруту
4. **Масштабируемость**: Легко добавить третий московский сервер
### Мониторинг failover
```shell
# Проверить OSPF маршруты
/routing ospf route print
# Проверить активные маршруты
/ip route print where active=yes
# Проверить состояние GRE туннелей
/interface gre print
# Проверить OSPF соседей
/routing ospf neighbor print
```
### Массовая рассылка конфигурации
#### Шаблон для всех серверов с туннелем gre-SWE-HIPHOST:
```shell
# Заменить <REMOTE_IP>, <LOCAL_IP>, <TUNNEL_IP> на соответствующие значения
/interface gre add name=gre-SWE-HIPHOST remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/30 interface=gre-SWE-HIPHOST
/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
```
#### Шаблон для всех серверов с туннелем gre-MSK-VPSVILLE-IHOR:
```shell
# Заменить <REMOTE_IP>, <LOCAL_IP>, <TUNNEL_IP> на соответствующие значения
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/30 interface=gre-MSK-VPSVILLE-IHOR
/routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone
```
#### Пример конкретных команд для каждого сервера:
**MSK-VPSVILLE:**
```shell
/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/ip address add address=10.200.1.1/30 interface=gre-SWE-HIPHOST
/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
/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
/routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone
```
**MSK-IHOR:**
```shell
/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<IHOR_WAN_IP>
/ip address add address=10.200.2.1/30 interface=gre-SWE-HIPHOST
/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<VPSVILLE_WAN_IP> local-address=<IHOR_WAN_IP>
/ip address add address=10.200.0.2/30 interface=gre-MSK-VPSVILLE-IHOR
/routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone
```
**SWE-HIPHOST:**
```shell
/interface gre add name=gre-SWE-HIPHOST remote-address=<VPSVILLE_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.200.1.2/30 interface=gre-SWE-HIPHOST
/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<IHOR_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.200.2.2/30 interface=gre-MSK-VPSVILLE-IHOR
/routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=10 area=backbone
```
### Тестирование failover
```shell
# На MSK-VPSVILLE отключить GRE туннель gre-SWE-HIPHOST
/interface gre disable [ find where name=gre-SWE-HIPHOST ]
# Проверить что маршрут исчез из OSPF
/routing ospf route print
# На HOME проверить что маршрут изменился
/ip route print where dst-address=0.0.0.0/0
# Включить туннель обратно
/interface gre enable [ find where name=gre-SWE-HIPHOST ]
# На MSK-IHOR отключить GRE туннель gre-SWE-HIPHOST
/interface gre disable [ find where name=gre-SWE-HIPHOST ]
# Проверить что маршрут исчез из OSPF
/routing ospf route print
# Включить туннель обратно
/interface gre enable [ find where name=gre-SWE-HIPHOST ]
```
### Проверка работы cost:
```shell
# На HOME проверить OSPF маршруты с cost
/routing ospf route print
# Должно показать что-то вроде:
# dst-address=0.0.0.0/0 gateway=10.100.2.2 cost=10 # Основной
# dst-address=0.0.0.0/0 gateway=10.100.5.2 cost=10 # Основной
# dst-address=0.0.0.0/0 gateway=10.100.1.2 cost=100 # Резервный
# dst-address=0.0.0.0/0 gateway=10.100.5.2 cost=100 # Резервный
```
---
## Настройка BFD для OSPF
BFD (Bidirectional Forwarding Detection) обеспечивает быстрое обнаружение недоступности каналов и ускоряет failover OSPF.
### Конфигурация BFD на HOME (RouterOS 7.14+):
```shell
# 1. Настроить BFD параметры для GRE интерфейсов
/routing bfd
add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3
add interface=gre-SWE-HIPHOST-RTK interval=100ms multiplier=3
add interface=gre-MSK-VPSVILLE-MTS interval=100ms multiplier=3
add interface=gre-MSK-VPSVILLE-RTK interval=100ms multiplier=3
add interface=gre-MSK-IHOR-MTS interval=100ms multiplier=3
add interface=gre-MSK-IHOR-RTK interval=100ms multiplier=3
# 2. Включить BFD для OSPF
/routing ospf interface-template
set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes
set [ find where interfaces=gre-SWE-HIPHOST-RTK ] bfd=yes
set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] bfd=yes
set [ find where interfaces=gre-MSK-VPSVILLE-RTK ] bfd=yes
set [ find where interfaces=gre-MSK-IHOR-MTS ] bfd=yes
set [ find where interfaces=gre-MSK-IHOR-RTK ] bfd=yes
```
### Конфигурация BFD на SWE-HIPHOST (RouterOS 7.14+):
```shell
# 1. Настроить BFD параметры для GRE интерфейсов
/routing bfd
add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3
add interface=gre-SWE-HIPHOST-RTK interval=100ms multiplier=3
add interface=gre-SWE-HIPHOST interval=100ms multiplier=3
add interface=gre-MSK-VPSVILLE-IHOR interval=100ms multiplier=3
# 2. Включить BFD для OSPF
/routing ospf interface-template
set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes
set [ find where interfaces=gre-SWE-HIPHOST-RTK ] bfd=yes
set [ find where interfaces=gre-SWE-HIPHOST ] bfd=yes
set [ find where interfaces=gre-MSK-VPSVILLE-IHOR ] bfd=yes
```
### Конфигурация BFD на MSK-VPSVILLE (RouterOS 7.14+):
```shell
# 1. Настроить BFD параметры для GRE интерфейсов
/routing bfd
add interface=gre-MSK-VPSVILLE-MTS interval=100ms multiplier=3
add interface=gre-MSK-VPSVILLE-RTK interval=100ms multiplier=3
add interface=gre-SWE-HIPHOST interval=100ms multiplier=3
add interface=gre-MSK-VPSVILLE-IHOR interval=100ms multiplier=3
# 2. Включить BFD для OSPF
/routing ospf interface-template
set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] bfd=yes
set [ find where interfaces=gre-MSK-VPSVILLE-RTK ] bfd=yes
set [ find where interfaces=gre-SWE-HIPHOST ] bfd=yes
set [ find where interfaces=gre-MSK-VPSVILLE-IHOR ] bfd=yes
```
### Конфигурация BFD на MSK-IHOR (RouterOS 7.14+):
```shell
# 1. Настроить BFD параметры для GRE интерфейсов
/routing bfd
add interface=gre-MSK-IHOR-MTS interval=100ms multiplier=3
add interface=gre-MSK-IHOR-RTK interval=100ms multiplier=3
add interface=gre-SWE-HIPHOST interval=100ms multiplier=3
add interface=gre-MSK-VPSVILLE-IHOR interval=100ms multiplier=3
# 2. Включить BFD для OSPF
/routing ospf interface-template
set [ find where interfaces=gre-MSK-IHOR-MTS ] bfd=yes
set [ find where interfaces=gre-MSK-IHOR-RTK ] bfd=yes
set [ find where interfaces=gre-SWE-HIPHOST ] bfd=yes
set [ find where interfaces=gre-MSK-VPSVILLE-IHOR ] bfd=yes
```
### Параметры BFD:
| Параметр | Значение | Описание |
|----------|----------|----------|
| **interval** | 100ms | Интервал отправки BFD пакетов (быстрое обнаружение) |
| **multiplier** | 3 | Количество пропущенных пакетов для объявления недоступности |
| **Время обнаружения** | 300ms | interval × multiplier = 100ms × 3 = 300ms |
### Полная конфигурация BFD для всех серверов:
| Сервер | GRE интерфейсы с BFD | BFD параметры | OSPF интеграция |
|--------|---------------------|---------------|-----------------|
| **HOME** | gre-SWE-HIPHOST-MTS, gre-SWE-HIPHOST-RTK, gre-MSK-VPSVILLE-MTS, gre-MSK-VPSVILLE-RTK, gre-MSK-IHOR-MTS, gre-MSK-IHOR-RTK | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes |
| **MSK-VPSVILLE** | gre-MSK-VPSVILLE-MTS, gre-MSK-VPSVILLE-RTK, gre-SWE-HIPHOST, gre-MSK-VPSVILLE-IHOR | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes |
| **MSK-IHOR** | gre-MSK-IHOR-MTS, gre-MSK-IHOR-RTK, gre-SWE-HIPHOST, gre-MSK-VPSVILLE-IHOR | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes |
| **SWE-HIPHOST** | gre-SWE-HIPHOST-MTS, gre-SWE-HIPHOST-RTK, gre-SWE-HIPHOST, gre-MSK-VPSVILLE-IHOR | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes |
### Альтернативные настройки BFD:
| Тип обнаружения | Interval | Multiplier | Время обнаружения | Применение |
|----------------|----------|------------|-------------------|------------|
| Быстрое | 50ms | 3 | 150ms | Критичные каналы |
| Стандартное | 200ms | 3 | 600ms | Обычные каналы |
| Медленное | 500ms | 3 | 1.5s | Экономия ресурсов |
### Проверка BFD (RouterOS 7.14+):
```shell
# Проверить статус BFD сессий
/routing bfd print
# Проверить детали BFD сессий
/routing bfd print detail
# Проверить BFD на интерфейсах
/interface gre print
# Проверить OSPF с BFD
/routing ospf interface-template print where bfd=yes
# Проверить BFD логи
/log print where topics~"bfd"
# Проверить BFD статистику
/routing bfd print stats
```
### Преимущества BFD:
1. **Быстрое обнаружение**: 300ms вместо нескольких секунд OSPF
2. **Надежность**: Независимое от OSPF обнаружение недоступности
3. **Гибкость**: Настраиваемые параметры для разных каналов
4. **Совместимость**: Работает с любыми протоколами маршрутизации
---
## Диагностика проблем с BFD
### Проблема: BFD session в статусе "init" и "down"
Если BFD сессия не устанавливается, это может быть связано с несколькими причинами:
#### 1. Проверка базовой связности
```shell
# Проверить что GRE туннель работает
/interface gre print
# Проверить ping через GRE туннель
ping 10.100.5.2 count=5
# Проверить что OSPF соседи установлены
/routing ospf neighbor print
```
#### 2. Проверка BFD конфигурации
```shell
# Проверить BFD сессии
/routing bfd print
# Проверить детали BFD
/routing bfd print detail
# Проверить что BFD включен в OSPF
/routing ospf interface-template print where bfd=yes
```
#### 3. Возможные решения
##### Решение 1: Проверить параметры BFD
```shell
# Убедиться что параметры одинаковые на обеих сторонах
/routing bfd print
# Если параметры разные, исправить:
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=100ms multiplier=3
```
##### Решение 2: Перезапустить BFD сессию
```shell
# Удалить и пересоздать BFD сессию
/routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ]
/routing bfd add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3
```
##### Решение 3: Проверить firewall
```shell
# Проверить что BFD пакеты не блокируются
/ip firewall filter print where protocol=udp
# BFD использует UDP порт 3784, убедиться что он не заблокирован
```
##### Решение 4: Использовать более медленные параметры
```shell
# Попробовать более медленные параметры для стабильности
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3
```
#### 4. Пошаговая диагностика
```shell
# Шаг 1: Проверить GRE туннель
/interface gre print
# Шаг 2: Проверить OSPF соседей
/routing ospf neighbor print
# Шаг 3: Проверить BFD сессии
/routing bfd print
# Шаг 4: Проверить BFD детали
/routing bfd print detail
# Шаг 5: Проверить логи
/log print where topics~"bfd"
```
#### 5. Альтернатива: Отключить BFD временно
```shell
# Если BFD не работает, можно временно отключить
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no
# OSPF будет работать без BFD, но медленнее
```
#### 6. Специфичные проблемы и решения
##### Проблема: BFD не работает на GRE туннелях
Некоторые версии RouterOS могут иметь проблемы с BFD на GRE туннелях. В этом случае:
```shell
# Проверить версию RouterOS
/system resource print
# Если версия < 7.14, BFD может не работать на GRE
# В этом случае лучше отключить BFD
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no
```
##### Проблема: BFD конфликтует с OSPF
```shell
# Проверить OSPF соседей
/routing ospf neighbor print
# Если OSPF работает, но BFD нет - отключить BFD
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no
```
##### Проблема: Неправильные параметры BFD
```shell
# Проверить текущие параметры
/routing bfd print detail
# Установить стандартные параметры
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3
```
#### 7. Рекомендуемая последовательность настройки BFD
```shell
# Шаг 1: Убедиться что OSPF работает
/routing ospf neighbor print
# Шаг 2: Настроить BFD с медленными параметрами
/routing bfd add interface=gre-SWE-HIPHOST-MTS interval=200ms multiplier=3
# Шаг 3: Включить BFD в OSPF
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes
# Шаг 4: Проверить статус
/routing bfd print
# Шаг 5: Если работает, ускорить параметры
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=100ms multiplier=3
```
#### 8. Мониторинг BFD
```shell
# Добавить логирование BFD
/system logging
add topics=bfd
# Проверить логи BFD
/log print where topics~"bfd"
# Мониторинг BFD сессий
:put "BFD Status:"
/routing bfd print
```
#### 9. Быстрая диагностика для вашего случая
Выполните эти команды на обеих сторонах (gateway и сервер):
```shell
# На gateway (HOME):
# 1. Проверить GRE туннель
/interface gre print where name~"SWE-HIPHOST"
# 2. Проверить ping до сервера
ping 10.100.5.2 count=5
# 3. Проверить OSPF соседей
/routing ospf neighbor print
# 4. Проверить BFD сессии
/routing bfd print
# 5. Проверить детали BFD
/routing bfd print detail
# На сервере (SWE-HIPHOST):
# 1. Проверить GRE туннель
/interface gre print where name~"SWE-HIPHOST"
# 2. Проверить ping до gateway
ping 10.100.5.1 count=5
# 3. Проверить OSPF соседей
/routing ospf neighbor print
# 4. Проверить BFD сессии
/routing bfd print
# 5. Проверить детали BFD
/routing bfd print detail
```
#### 10. Быстрое решение
Если диагностика показывает проблемы с BFD:
```shell
# Временно отключить BFD на обеих сторонах
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no
# Удалить BFD сессии
/routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ]
# Проверить что OSPF работает
/routing ospf neighbor print
```
#### 11. Проблема: BFD packets Rx = 0
Если на gateway BFD session показывает `packets Rx = 0`, это означает что BFD пакеты не доходят от сервера до gateway.
##### Диагностика проблемы с BFD пакетами
```shell
# На gateway проверить детали BFD сессии
/routing bfd print detail
# Должно показать что-то вроде:
# packets-tx: 1234
# packets-rx: 0 # ← Проблема здесь
# state: down
```
##### Возможные причины и решения:
###### Причина 1: BFD не настроен на сервере
```shell
# На сервере проверить BFD конфигурацию
/routing bfd print
# Если BFD не настроен, добавить:
/routing bfd add interface=gre-SWE-HIPHOST-MTS interval=200ms multiplier=3
# И включить в OSPF:
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes
```
###### Причина 2: Firewall блокирует BFD пакеты
```shell
# На сервере проверить firewall правила
/ip firewall filter print where protocol=udp
# BFD использует UDP порт 3784, проверить что он не заблокирован
# Добавить правило для разрешения BFD (если нужно):
/ip firewall filter add chain=forward protocol=udp dst-port=3784 action=accept comment="BFD"
```
###### Причина 3: Разные параметры BFD
```shell
# На обеих сторонах проверить параметры BFD
/routing bfd print detail
# Убедиться что interval и multiplier одинаковые
# Если разные - исправить на сервере:
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3
```
###### Причина 4: GRE туннель нестабилен
```shell
# Проверить стабильность GRE туннеля
/interface gre print
# Проверить ping через туннель
ping 10.100.5.2 count=10 interval=100ms
# Если есть потери пакетов, BFD может не работать
```
##### Быстрое решение для диагностики:
```shell
# На сервере временно отключить BFD
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no
/routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ]
# На gateway тоже отключить
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no
/routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ]
# Проверить что OSPF работает без BFD
/routing ospf neighbor print
```
##### Пошаговая настройка BFD заново:
```shell
# Шаг 1: Убедиться что OSPF работает
/routing ospf neighbor print
# Шаг 2: Настроить BFD на сервере с медленными параметрами
/routing bfd add interface=gre-SWE-HIPHOST-MTS interval=500ms multiplier=3
# Шаг 3: Включить BFD в OSPF на сервере
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes
# Шаг 4: Настроить BFD на gateway с теми же параметрами
/routing bfd add interface=gre-SWE-HIPHOST-MTS interval=500ms multiplier=3
# Шаг 5: Включить BFD в OSPF на gateway
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes
# Шаг 6: Проверить статус
/routing bfd print
```
### Пояснение: DHCP маршруты в OSPF
- **DHCP маршруты** считаются как `connected` в RouterOS
- **redistribute=connected** анонсирует все connected маршруты, включая DHCP
- **redistribute=static** анонсирует только статические маршруты
- **DHCP маршрут 0.0.0.0/0** автоматически попадет в OSPF при `redistribute=connected`
- **AWS metadata service (169.254.169.254)** тоже может анонсироваться и мешать
### Проблема с AWS metadata service
AWS автоматически добавляет маршрут к 169.254.169.254 (metadata service), который тоже будет анонсироваться через OSPF при `redistribute=connected`. Это может создавать нежелательные маршруты.
### Проверка DHCP маршрута и AWS metadata:
```shell
# Проверить тип маршрута 0.0.0.0/0
/ip route print where dst-address=0.0.0.0/0
# Проверить AWS metadata маршрут
/ip route print where dst-address=169.254.169.254/32
# Должно показать что-то вроде:
# Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
# Маршрут от DHCP будет помечен как DYNAMIC
# AWS metadata маршрут тоже будет DYNAMIC
```
---
Reference in New Issue View Git Blame Copy Permalink