The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Сервер с несколькими интерфейсами"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Маршрутизация, NAT / Linux)
Изначальное сообщение [ Отслеживать ]

"Сервер с несколькими интерфейсами"  +/
Сообщение от Harlan (ok), 13-Мрт-20, 08:40 
Находил кучу материалов касающихся нескольких интерфейсов на машине, смотрящих на разных провайдеров, но все они, как правило, касались резервирования каналов, либо балансировки нагрузки. Меня же интересует немного другой момент.

Есть: Сервер с CentOS 8, и четырьмя интерфейсами Ethernet.

enp0: LAN. IPAddress: 192.168.1.1/24
enp1: Provider 1. IPAddress: 10.1.1.110/30 Default Gateway: 10.1.1.109
enp2: Provider 2. IPAddress: 10.2.2.220/28 Gateway: 10.2.2.209
enp3: Provider 3. IPAddress: 10.3.3.30/29 Gateway: 10.3.3.25


На сервере развёрнуты HTTP, FTP. Планируется развернуть OpenVPN (udp mode) для доступа из-вне в локальную сеть. Сама машина роутером не является (транзитный трафик между интерфейсами ethernet запрещён).

Пытаюсь из-вне пропинговать адреса интерфесов сервера.
ping 10.1.1.110 - отправлено 5 пакетов / получено 5 пакетов
ping 10.2.2.220 - отправлено 5 пакетов / получено 0 пакетов
ping 10.3.3.30 - отправлено 5 пакетов / получено 0 пакетов

Сканер запущенный на сервере показал, что пинги на сервер прилетают, но ответы отправляются через enp1 (Default Gateway) с выставленным Source IP 10.1.1.110.
Боюсь, что с OpenVPN может возникнуть такая же ситуация.

Подскажите, пожалуйста, как сделать так, чтобы ответы на пинги (и сессии OpenVPN), отправлялись с того же интерфейса (и с того же IP), на который пришел запрос?

Поможет ли тут Source routing от iproute2?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 13-Мрт-20, 10:08   +/
> Подскажите, пожалуйста, как сделать так, чтобы ответы на пинги (и сессии OpenVPN),
> отправлялись с того же интерфейса (и с того же IP), на
> который пришел запрос?

https://anr-daemon.livejournal.com/1655.html?thread=2679#t2679

Почитай, похоже на твой случай...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Harlan (ok), 13-Мрт-20, 10:29   +/
> https://anr-daemon.livejournal.com/1655.html?thread=2679#t2679
> Почитай, похоже на твой случай...

Спасибо!
Очень похоже на то.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Licha Morada (ok), 13-Мрт-20, 20:39   +/
Вам вверху дали првильную ссылку, но, имхо, там несколько запутанно. Можно обойтись более простыми мерами.

> Пытаюсь из-вне пропинговать адреса интерфесов сервера.
> ping 10.1.1.110 - отправлено 5 пакетов / получено 5 пакетов
> ping 10.2.2.220 - отправлено 5 пакетов / получено 0 пакетов
> ping 10.3.3.30 - отправлено 5 пакетов / получено 0 пакетов
> Сканер запущенный на сервере показал, что пинги на сервер прилетают, но ответы
> отправляются через enp1 (Default Gateway) с выставленным Source IP 10.1.1.110.
> Боюсь, что с OpenVPN может возникнуть такая же ситуация.

Да. Именно так оно и происходит по дефолту.

Дело в том, что:
- Интерфейс для исходящих пакетов зависит от выбранного маршрута, а именно gateway.
- Маршрут зависит от адреса получателя, мы его не контролируем совсем.
- Получатель, когда подключался к нам, сам выбрал по какому (нашему) адресу это делать, и этот адрес может не совпадать с интерфейсом на котором находится gateway который выбиаем мы на основе таблицы маршрутизации.

Важно не путать "исходящий пакет" с "исходящим соединением". Независимо от того, клиент мы (подключаемся к кому-то) или сервер (принимаем подключение), пакеты будут ходить в обе стороны. В даном случае, мы сервер, но фиксить надо поведение исходяих пакетов.


> Подскажите, пожалуйста, как сделать так, чтобы ответы на пинги (и сессии OpenVPN),
> отправлялись с того же интерфейса (и с того же IP), на
> который пришел запрос?

Если коротко, то надо как-то заставить вашу систему выбирать маршрут не только на основе адреса получателя, но и на основе адреса отправителя. Адрес отправителя, очень кстати, будет соответствовать интерфейсу на котором мы приняли подключение с самого начала.

> Поможет ли тут Source routing от iproute2?

Да, именно iproute2. Я знаком с этой технологией под именем Policy Based Routing. Source routing первый раз слышу, но, возможно, исключительно от недостатка эрудиции.
Читайте https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.mult...

Для каждого из ваших enp1-3:
- Создайте новую _дополнительную_ таблицу маршрутизации, со своим default gateway и маршрутом к локалной сети (2 маршрута).
- Создайте правило policy, что к пакетам с конкретнум адресом отправителя надо применять конкретную таблицу.

Вы привели замечательный пример разнообразия интернетов. Смотрите:

> enp1: Provider 1. IPAddress: 10.1.1.110/30 Default Gateway: 10.1.1.109

ip route add 10.1.1.108/30 dev enp1 src 10.1.1.110 table 1011
ip route add default via 10.1.1.109 table 1011
ip rule add from 10.1.1.110 table 1011

> enp2: Provider 2. IPAddress: 10.2.2.220/28 Gateway: 10.2.2.209

ip route add 10.2.2.208/28 dev enp1 src 10.2.2.220 table 1022
ip route add default via 10.2.2.209  table 1022
ip rule add from 10.2.2.220 table 1022

> enp3: Provider 3. IPAddress: 10.3.3.30/29 Gateway: 10.3.3.25

ip route add 10.3.3.24/29 dev enp1 src 10.3.3.30 table 1033
ip route add default vi 10.3.3.25  table 1033
ip rule add from 10.3.3.30 table 1033

(я нигде в масках не ошибся?)

Этого достаточно для того, чтобы отвечать на том-же интерфейсе на который подключился клиент.
Это базовая конфигурация multihomed. На её основе можно достраивать разнообразные усложнения, типа резервирования каналов, балансировку и т.д.
Это proof of concept, оно будет работать, но для продакшена стоит его причесать. Дать осмысленные имена таблицам, автоматизировать добавление правил при включении интерфейса, и убирании их-же при выключении, и т.д.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #8

4. Сообщение от noname (ok), 13-Мрт-20, 23:19   +/

> Подскажите, пожалуйста, как сделать так, чтобы ответы на пинги (и сессии OpenVPN),
> отправлялись с того же интерфейса (и с того же IP), на
> который пришел запрос?

https://access.redhat.com/solutions/53031


Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

5. Сообщение от Licha Morada (ok), 14-Мрт-20, 00:31   +/
>> Подскажите, пожалуйста, как сделать так, чтобы ответы на пинги (и сессии OpenVPN),
>> отправлялись с того же интерфейса (и с того же IP), на
>> который пришел запрос?
> https://access.redhat.com/solutions/53031

Они, редиски, описывают решение проблемы "RHEL ignore packets when the route for outbound traffic differs from the route of incoming traffic". А решение проблемы "How can I route network traffic such that the packets go out via the same interface they came in" по другой ссылке, но туда нельзя, ибо "Subscriber exclusive content". TLDP наше всё.

Но всё равно релевантно, спасибо. После решения роутинга, могут быть грабли с этим "Strict Reverse Path Forwarding".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

6. Сообщение от BABUTemail (ok), 19-Мрт-20, 17:59   +/
господи, как у вас всё сложно! понятно от чего вы такие злые и ненавидите бсдехи ;) на бсдешном pf'е всего две команды достаточно: route-to и reply-to. в данном случае даже достаточно последней. ещё есть сквозные(от l2 к l3) тэги- для особых извращений
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #7

7. Сообщение от Licha Morada (ok), 19-Мрт-20, 18:23   +/
Its Magic.gif
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

8. Сообщение от Harlan (ok), 20-Мрт-20, 08:38   +/
Огромное спасибо!

Именно так и прописал таблицы и правила. А на счёт "Policy Based Routing" и "Source routing", так тут дело не в эрудиции, а в попытке придумать "наукообразный" термин, когда забыл правильный, а рыться лень.

>[оверквотинг удален]
> ip route add default vi 10.3.3.25  table 1033
> ip rule add from 10.3.3.30 table 1033
> (я нигде в масках не ошибся?)
> Этого достаточно для того, чтобы отвечать на том-же интерфейсе на который подключился
> клиент.
> Это базовая конфигурация multihomed. На её основе можно достраивать разнообразные усложнения,
> типа резервирования каналов, балансировку и т.д.
> Это proof of concept, оно будет работать, но для продакшена стоит его
> причесать. Дать осмысленные имена таблицам, автоматизировать добавление правил при включении
> интерфейса, и убирании их-же при выключении, и т.д.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру