diff --git a/SHX_NETWORK.md b/SHX_NETWORK.md new file mode 100644 index 0000000..5ffad73 --- /dev/null +++ b/SHX_NETWORK.md @@ -0,0 +1,2309 @@ +# SHX Network Infrastructure + +## Обзор сети + +Данный проект описывает сетевую инфраструктуру с двумя провайдерами интернет-соединения и множественными GRE туннелями для обеспечения отказоустойчивости и географического распределения. + +## Архитектура сети + +### Основная схема (обновлено) + +```mermaid +graph TB + subgraph "Шлюз (Gateway)" + GW[Основной шлюз] + end + + subgraph "Провайдеры" + MTS[МТС] + RTK[Ростелеком] + end + + subgraph "GRE Туннели" + subgraph "Ростелеком (RTK)" + RTK1[MSK-VPSVILLE-RTK] + RTK2[MSK-IHOR-RTK] + RTK3[SWE-HIPHOST-RTK] + end + + subgraph "МТС (MTS)" + MTS1[MSK-VPSVILLE-MTS] + MTS2[MSK-IHOR-MTS] + MTS3[SWE-HIPHOST-MTS] + end + end + + subgraph "Удаленные узлы" + VPSVILLE[VPSVILLE] + IHOR[IHOR] + HIPHOST["HIPHOST
SWE"] + end + + GW --> MTS + GW --> RTK + + MTS --> MTS1 + MTS --> MTS2 + MTS --> MTS3 + + RTK --> RTK1 + RTK --> RTK2 + RTK --> RTK3 + + MTS1 --> VPSVILLE + MTS2 --> IHOR + MTS3 --> HIPHOST + + RTK1 --> VPSVILLE + RTK2 --> IHOR + RTK3 --> HIPHOST + + %% Новое: GRE SWE-HIPHOST от всех МСК серверов + VPSVILLE -- GRE SWE-HIPHOST --> HIPHOST + IHOR -- GRE SWE-HIPHOST --> HIPHOST + + style GW fill:#e1f5fe + style MTS fill:#ffebee + style RTK fill:#e8f5e8 + style VPSVILLE fill:#fff3e0 + style IHOR fill:#fff3e0 + style HIPHOST fill:#fff3e0 +``` + +### Детальная схема туннелей (обновлено) + +```mermaid +graph LR + subgraph "Шлюз" + GW[Gateway] + end + + subgraph "Провайдер МТС" + MTS_ISP[МТС ISP] + end + + subgraph "Провайдер Ростелеком" + RTK_ISP[Ростелеком ISP] + end + + subgraph "GRE Туннели" + subgraph "Москва - VPSVILLE" + MTS_VPS[MSK-VPSVILLE-MTS
GRE Tunnel] + RTK_VPS[MSK-VPSVILLE-RTK
GRE Tunnel] + end + + subgraph "Москва - IHOR" + MTS_IHOR[MSK-IHOR-MTS
GRE Tunnel] + RTK_IHOR[MSK-IHOR-RTK
GRE Tunnel] + end + + subgraph "Швеция - HIPHOST" + MTS_HIP[SWE-HIPHOST-MTS
GRE Tunnel] + RTK_HIP[SWE-HIPHOST-RTK
GRE Tunnel] + end + end + + subgraph "Удаленные серверы" + VPS[VPSVILLE Server
Москва] + IHR[IHOR Server
Москва] + HIP["HIPHOST
SWE"] + end + + GW --> MTS_ISP + GW --> RTK_ISP + + MTS_ISP --> MTS_VPS + MTS_ISP --> MTS_IHOR + MTS_ISP --> MTS_HIP + + RTK_ISP --> RTK_VPS + RTK_ISP --> RTK_IHOR + RTK_ISP --> RTK_HIP + + MTS_VPS --> VPS + MTS_IHOR --> IHR + MTS_HIP --> HIP + + RTK_VPS --> VPS + RTK_IHOR --> IHR + RTK_HIP --> HIP + + %% Новое: GRE SWE-HIPHOST от всех МСК серверов + VPS -- GRE SWE-HIPHOST --> HIP + IHR -- GRE SWE-HIPHOST --> HIP + + style GW fill:#2196f3,stroke:#1976d2,stroke-width:2px,color:#fff + style MTS_ISP fill:#f44336,stroke:#d32f2f,stroke-width:2px,color:#fff + style RTK_ISP fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff + style VPS fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff + style IHR fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff + style HIP fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff +``` + +### Схема европейского трафика (новая) + +```mermaid +graph TD + subgraph "Москва" + VPSVILLE_MSK[VPSVILLE
Москва] + IHOR_MSK[IHOR
Москва] + end + subgraph "Швеция" + HIPHOST_SWE["HIPHOST
SWE"] + end + + VPSVILLE_MSK -- GRE SWE-HIPHOST --> HIPHOST_SWE + IHOR_MSK -- GRE SWE-HIPHOST --> HIPHOST_SWE + + HIPHOST_SWE -- "Европейский интернет" --> EU[EU Resources] + + classDef eu fill:#e3f2fd,stroke:#1976d2,stroke-width:2px; + class EU eu; +``` + +### Схема связывания московских серверов через OSPF (новая) + +```mermaid +graph TB + subgraph "Москва - VPSVILLE" + VPSVILLE[VPSVILLE
msk.vpsville.rt.shx.su] + end + + subgraph "Москва - IHOR" + IHOR[IHOR
msk.ihor.rt.shx.su] + end + + subgraph "Домашний шлюз" + HOME[HOME
home.rt.shx.su] + end + + %% GRE туннели от домашнего шлюза (только клиентские подключения) + HOME -- "GRE MSK-VPSVILLE-RTK
10.100.2.0/30" --> VPSVILLE + HOME -- "GRE MSK-VPSVILLE-MTS
10.100.1.0/30" --> VPSVILLE + HOME -- "GRE MSK-IHOR-RTK
10.100.4.0/30" --> IHOR + HOME -- "GRE MSK-IHOR-MTS
10.100.3.0/30" --> IHOR + + %% GRE туннель между московскими серверами (независимо от HOME) + VPSVILLE -- "GRE MSK-VPSVILLE-IHOR
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
Приоритет 1] + VPS_RTK[MSK-VPSVILLE-RTK
Приоритет 2] + end + + subgraph "IHOR" + IHR_MTS[MSK-IHOR-MTS
Приоритет 1] + IHR_RTK[MSK-IHOR-RTK
Приоритет 2] + end + + subgraph "HIPHOST" + HIP_MTS[SWE-HIPHOST-MTS
Приоритет 1] + HIP_RTK[SWE-HIPHOST-RTK
Приоритет 2] + end + end + + GW --> MTS + GW --> RTK + + MTS --> VPS_MTS + MTS --> IHR_MTS + MTS --> HIP_MTS + + RTK --> VPS_RTK + RTK --> IHR_RTK + RTK --> HIP_RTK + + VPS_MTS -.->|Failover| VPS_RTK + IHR_MTS -.->|Failover| IHR_RTK + HIP_MTS -.->|Failover| HIP_RTK + + %% Новое: Европейский трафик через SWE-HIPHOST + VPS_MTS -- "EU трафик" --> HIP_MTS + VPS_RTK -- "EU трафик" --> HIP_RTK + IHR_MTS -- "EU трафик" --> HIP_MTS + IHR_RTK -- "EU трафик" --> HIP_RTK + + style GW fill:#2196f3,stroke:#1976d2,stroke-width:3px,color:#fff + style MTS fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff + style RTK fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff +``` + +## Конфигурация туннелей + +### Туннели от 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= local-address= +/ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS +/ip route add dst-address=10.100.1.2/32 gateway=gre-MSK-VPSVILLE-MTS +``` + +- `` — внешний IP удалённого сервера +- `` — ваш внешний IP +- Аналогично для остальных туннелей, меняя адресацию по таблице выше + +--- + +--- + +## OSPF: Оптимальная настройка для GRE туннелей + +В данной архитектуре используется OSPF для динамической маршрутизации между всеми GRE туннелями. Основной провайдер — Ростелеком, резервный — МТС. Для HomeLab (например, 192.168.111.0/24) весь трафик направляется через МТС с помощью policy routing (route-table=MTS). + +### Рекомендации по настройке + +1. **OSPF cost** + - Для GRE туннелей через Ростелеком (основной) выставить меньший cost (например, 10) + - Для GRE туннелей через МТС (резервный) — больший cost (например, 100) + - Это обеспечит приоритет Ростелекома для всего трафика, кроме HomeLab + +2. **Policy Based Routing (PBR) для HomeLab** + - Для HomeLab (например, 192.168.111.0/24) настроить policy routing: + - Весь исходящий трафик с HomeLab отправлять в route-table=MTS + - В этой таблице основной маршрут — через МТС (резервный провайдер) + +3. **OSPF Instance и Area** + - Использовать одну OSPF instance для всех туннелей (если нет особых требований) + - Все GRE-интерфейсы добавить в одну area (обычно 0.0.0.0) + +### Пример конфигурации OSPF на RouterOS + +```shell +# 1. Настройка OSPF instance +/routing ospf instance +set [ find default=yes ] router-id=10.100.0.1 + +# 2. Добавление GRE-интерфейсов в OSPF с разным cost +# Ростелеком (основной провайдер) - низкий 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= routing-table=MTS +/ip firewall mangle +add chain=prerouting src-address=192.168.111.0/24 action=mark-routing new-routing-mark=MTS + +# — адрес следующего хопа через МТС (например, 10.100.1.2) +``` + +#### Логика работы +- OSPF сам будет выбирать основной маршрут через Ростелеком (основной провайдер, cost=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= local-address= +/ip address add address=10.100.2.1/30 interface=gre-MSK-VPSVILLE-RTK +# Аналогично для остальных туннелей по таблице адресации +``` + +--- + +## Актуальные рекомендации для RouterOS 7.14+ + +- Используйте `/routing rule` для Policy Based Routing вместо mangle. +- OSPF интерфейсы и cost настраиваются через `interface-template`. +- Все GRE туннели должны быть добавлены в OSPF через interface-template для корректного анонса маршрутов. +- OSPF автоматически поддерживает failover между туннелями: если один туннель падает, маршрут исчезает из таблицы. +- Для отдельных сегментов (например, HomeLab или MSK) используйте отдельные routing table и routing rule для выбора нужного провайдера/туннеля. + +--- + +## Пример failover для route-table=MSK (RouterOS 7.14+) + +```shell +# 1. Routing rule для сегмента MSK +/routing rule +add src-address=192.168.222.0/24 action=lookup table=MSK + +# 2. OSPF сам добавит маршруты через gre-MSK-VPSVILLE и gre-MSK-IHOR в таблицу MSK +# Если хотите вручную: +/ip route +add dst-address=0.0.0.0/0 gateway=10.100.1.2 routing-table=MSK distance=1 +add dst-address=0.0.0.0/0 gateway=10.100.3.2 routing-table=MSK distance=2 +``` + +--- + +--- + +## Масштабирование сети с GRE и OSPF + +Схема с GRE-туннелями и OSPF идеально подходит для масштабируемых и отказоустойчивых сетей. + +### Преимущества +- **Лёгкое добавление новых туннелей:** для нового хоста создаётся GRE-интерфейс, выделяется /30 подсеть, добавляется в OSPF — маршруты распространяются автоматически. +- **Быстрая замена хоста:** при замене сервера/маршрутизатора достаточно повторить настройки GRE и OSPF — сеть быстро перестроится без ручных правок на других устройствах. +- **Гибкая топология:** можно строить как “звезду”, так и “mesh” — OSPF сам выберет оптимальные маршруты и обеспечит резервирование. +- **Автоматический failover:** при недоступности туннеля или хоста OSPF убирает маршруты, трафик идёт по резервным путям. +- **Масштабируемость:** количество туннелей ограничено только ресурсами оборудования, добавление новых площадок не требует изменений на старых. + +### Рекомендации +- Для каждого нового туннеля используйте отдельную /30 подсеть из выделенного диапазона (например, 10.100.x.0/30). +- Все GRE-интерфейсы сразу добавляйте в OSPF через interface-template. +- Используйте шаблоны и автоматизацию для быстрой настройки новых точек. +- Документируйте назначение каждой подсети и туннеля (см. таблицу выше). + +### Пример добавления нового GRE туннеля и OSPF (RouterOS 7.14+) + +```shell +/interface gre add name=gre-NEW-SITE remote-address= local-address= +/ip address add address=10.100.10.1/30 interface=gre-NEW-SITE + +/routing ospf interface-template +add interfaces=gre-NEW-SITE cost=10 area=backbone +``` + +--- + +--- + +## Европейский трафик через GRE SWE-HIPHOST + +У всех московских серверов настроен GRE-туннель на SWE-HIPHOST. Обычно через этот туннель направляется европейский трафик для оптимизации маршрутов и повышения скорости доступа к европейским ресурсам. + +### Как это реализовано +- Все GRE-туннели SWE-HIPHOST добавлены в OSPF через interface-template. +- OSPF обеспечивает резервирование и автоматический failover для туннеля SWE-HIPHOST. +- Policy Based Routing (PBR) позволяет направлять трафик, предназначенный для Европы, через отдельную таблицу маршрутизации (EU), где основной маршрут — через GRE SWE-HIPHOST. + +### Пример конфигурации (RouterOS 7.14+) + +```shell +# 1. Создаём таблицу маршрутизации для Европы +/routing table +add name=EU fib + +# 2. Routing rule для европейского трафика (пример: по dst-address) +/routing rule +add dst-address= action=lookup table=EU + +# 3. В таблице EU маршрут по умолчанию через GRE SWE-HIPHOST +/ip route +add dst-address=0.0.0.0/0 gateway=10.100.5.2 routing-table=EU distance=1 + +# 4. GRE SWE-HIPHOST добавлен в OSPF +/routing ospf interface-template +add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # Основной канал +add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # Резервный канал +``` +- `` — список европейских подсетей или диапазонов (можно использовать address-list и mangle для сложных случаев). + +### Преимущества +- **Оптимизация маршрутов:** Европейский трафик идёт по кратчайшему пути через SWE-HIPHOST. +- **Резервирование:** OSPF обеспечивает автоматический failover при недоступности туннеля. +- **Гибкость:** Можно легко расширять список европейских подсетей или добавить резервные маршруты. + +--- + +--- + +## Рекомендации по неймингу CHR серверов + +Грамотный нейминг серверов и шлюзов облегчает сопровождение, масштабирование и диагностику сети. + +### Рекомендуемая структура имени + +Если у вас несколько хостеров/площадок в одном городе или стране, рекомендуется использовать следующий формат: + +``` +<город>.<площадка>.<роль>.<домен> +``` + +- **<город>** — код города или страны (например, msk, swe) +- **<площадка>** — название хостера или дата-центра (например, vpsville, ihor, hiphost) +- **<роль>** — rt (router), gw (gateway), srv (server) и т.д. +- **<домен>** — основной домен вашей инфраструктуры + +#### Пример: +- `msk.vpsville.rt.shx.su` — роутер в Москве, площадка VPSVILLE +- `msk.ihor.rt.shx.su` — роутер в Москве, площадка IHOR +- `swe.hiphost.rt.shx.su` — роутер в Швеции, площадка HIPHOST +- `home.rt.shx.su` — домашний роутер + +### Схема именования серверов + +| Локация | Имя сервера | DNS имя | Роль | Описание | +|---------|-------------|---------|------|----------| +| Домашний | home-gw | home.rt.shx.su | 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= local-address= +/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= local-address= +/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
msk.vpsville.rt.shx.su] + IHOR[MSK-IHOR
msk.ihor.rt.shx.su] + end + + subgraph "Швеция" + HIPHOST[SWE-HIPHOST
swe.hiphost.rt.shx.su] + end + + subgraph "Домашний шлюз" + HOME[HOME
home.rt.shx.su] + end + + %% GRE туннели от HOME к московским серверам + HOME -- "GRE MSK-VPSVILLE-RTK
10.100.2.0/30" --> VPSVILLE + HOME -- "GRE MSK-VPSVILLE-MTS
10.100.1.0/30" --> VPSVILLE + HOME -- "GRE MSK-IHOR-RTK
10.100.4.0/30" --> IHOR + HOME -- "GRE MSK-IHOR-MTS
10.100.3.0/30" --> IHOR + + %% GRE туннели от московских серверов к SWE-HIPHOST + VPSVILLE -- "GRE SWE-HIPHOST
10.200.1.0/30" --> HIPHOST + IHOR -- "GRE SWE-HIPHOST
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= local-address= +/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= local-address= +/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= local-address= +/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= local-address= +/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= local-address= +/ip address add address=10.200.1.2/30 interface=gre-SWE-HIPHOST + +/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= +/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= local-address= +/ip address add address=/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= local-address= +/ip address add address=/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 +# Заменить , , на соответствующие значения +/interface gre add name=gre-SWE-HIPHOST remote-address= local-address= +/ip address add address=/30 interface=gre-SWE-HIPHOST +/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone +``` + +#### Шаблон для всех серверов с туннелем gre-MSK-VPSVILLE-IHOR: + +```shell +# Заменить , , на соответствующие значения +/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= +/ip address add address=/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= local-address= +/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= local-address= +/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= local-address= +/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= local-address= +/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= local-address= +/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= local-address= +/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 +``` + +--- \ No newline at end of file diff --git a/frontend/src/ServerManager.jsx b/frontend/src/ServerManager.jsx index 517daf5..32e8599 100644 --- a/frontend/src/ServerManager.jsx +++ b/frontend/src/ServerManager.jsx @@ -65,6 +65,14 @@ function ServerManager() { version: 'v4.rsc' }); + // Состояние для мониторинга сети + const [networkStatus, setNetworkStatus] = useState({}); + const [monitoringEnabled, setMonitoringEnabled] = useState(false); + + // Состояние для модального окна добавления сервера + const [addServerModalOpen, setAddServerModalOpen] = useState(false); + const [customProvider, setCustomProvider] = useState(''); + useEffect(() => { fetchServers(); }, []); @@ -106,6 +114,44 @@ function ServerManager() { setNewServer({ ip: '', dns: '', country: '', provider: '', tunnel: 'GRE' }); }; + // Функции для модального окна добавления сервера + const handleOpenAddServerModal = () => { + setAddServerModalOpen(true); + }; + + const handleCloseAddServerModal = () => { + setAddServerModalOpen(false); + setNewServer({ ip: '', dns: '', country: '', provider: '', tunnel: 'GRE' }); + setCustomProvider(''); + setError(''); + }; + + const handleAddServerFromModal = () => { + if (!newServer.ip.trim() || !newServer.dns.trim() || !newServer.country.trim() || !newServer.provider.trim() || !newServer.tunnel.trim()) { + setError('Все поля должны быть заполнены.'); + return; + } + + // Проверяем, если выбран "Другой" провайдер, то customProvider должен быть заполнен + if (newServer.provider === 'Другой' && !customProvider.trim()) { + setError('Пожалуйста, введите название провайдера.'); + return; + } + + setError(''); + + // Используем customProvider если выбран "Другой" + const finalProvider = newServer.provider === 'Другой' ? customProvider : newServer.provider; + const serverToAdd = { ...newServer, provider: finalProvider }; + + setServers([...servers, serverToAdd]); + setNewServer({ ip: '', dns: '', country: '', provider: '', tunnel: 'GRE' }); + setCustomProvider(''); + setAddServerModalOpen(false); + setSuccess('Сервер успешно добавлен!'); + setTimeout(() => setSuccess(''), 3000); + }; + const handleEdit = (server) => { setEditModalServer({ ...server }); setEditModalOpen(true); @@ -354,68 +400,20 @@ function ServerManager() {

- Добавить новый сервер + Управление серверами

-
{ e.preventDefault(); handleAddServer(); }}> -
- - setNewServer({ ...newServer, ip: e.target.value })} - /> -
-
- - setNewServer({ ...newServer, dns: e.target.value })} - /> -
-
- - setNewServer({ ...newServer, country: e.target.value })} - /> -
-
- - setNewServer({ ...newServer, provider: e.target.value })} - /> -
-
- - setNewServer({ ...newServer, tunnel: e.target.value })} - /> -
-
- -
-
+
+ +
@@ -547,6 +545,8 @@ function ServerManager() { )} + Основной шлюз + Статус Ссылка Действия @@ -559,6 +559,14 @@ function ServerManager() { {countryToFlag(server.country)} {server.country} {server.provider} {server.tunnel} + + + {server.provider} + + + + Онлайн + + +
+ {error && ( +
+ {error} +
+ )} +
+
+ + handleChange('ip', e.target.value)} + required + /> +
+
+ + handleChange('dns', e.target.value)} + required + /> +
+
+ + +
+
+ + + {newServer.provider === 'Другой' && ( + onCustomProviderChange(e.target.value)} + /> + )} +
+
+ + +
+
+
+
+ + +
+ + + + ); +} + export default ServerManager; \ No newline at end of file