Автор Тема: Несколько подсетей через один интерфейс  (Прочитано 1146 раз)

Оффлайн Mr.Madguy

  • Давно тут
  • **
  • Сообщений: 249
Нужно настроить 3 подсети через один интерфейс. Две из них с доступом интернет и хотелось бы использовать вторую подсеть в качестве резервного канала интернета. Для этого нужно прописать маршрутизатор из второй подсети в качестве шлюза. В Windows мне это сделать удалось. А как это сделать в Linux? На месте шлюзов других подсетей появляются рыжие прямоугольники и настройки не сохраняются.

Оффлайн Александр Ерещенко

  • Завсегдатай
  • *
  • Сообщений: 1 153
Как именно вы настроили это в винде?
По идее, делать надо аналогично.
Если не секретно :) , то можно вывод команд в виндовой консоли:
ipconfig /all
route print *

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

Оффлайн Mr.Madguy

  • Давно тут
  • **
  • Сообщений: 249
В Windows в дополнительных настройках соединения есть список шлюзов. В route print отображаются строки типа 0.0.0.0 0.0.0.0 <ip шлюза>. Я уже понял, что как обычно волшебные GUI в Linux не позволяют это сделать. Есть настройка статических маршрутов, но там нельзя ввести default или 0.0.0.0, как в Windows. Это приходится делать через ip route add default via <ip шлюза> proto static. Проблема в том, что после перезагрузки все пропадает. В /etc/network/interfaces ничего нет. Работает все через NetworkNanager. А там не понятно, как это добавить. Пытался добавить руками в конфигрукции к строке address2, как это сделано с address1, но ничего не поменялось. Маршрут в routel не добавился.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
хотелось бы использовать вторую подсеть в качестве резервного канала интернета. Для этого нужно прописать маршрутизатор из второй подсети в качестве шлюза.
Боюсь, будет совсем не то, что Вы ожидаете: двух шлюзов в нормальном варианте быть не может от слова совсем. То, что с этим делает Windows, это её личные творческие неудачи. Хотя добавить и два можно, и три можно. Только, вероятно, не через GUI-свистелки.

Оффлайн Mr.Madguy

  • Давно тут
  • **
  • Сообщений: 249
Боюсь, будет совсем не то, что Вы ожидаете: двух шлюзов в нормальном варианте быть не может от слова совсем. То, что с этим делает Windows, это её личные творческие неудачи. Хотя добавить и два можно, и три можно. Только, вероятно, не через GUI-свистелки.
Ну а как обычно происходит с несколькими сетевыми интерфейсами? Наверное так же, как и с несколькими DNS. Если один не предоставляет маршрутизацию до заданного узла, то используется другой. Какой лучше с этим справляется - у того метрика выше. И в следующий раз обращение будет именно к нему.

Понимаете. Вот как это реализовать без данной возможности? Ставить вторую сетевую карту и подключать второй сетевой провод от того же свича, просто чтобы настроить второй интерфейс с другим IP и шлюзом? Я об этом уже давно думал, т.к. считал, что сделать это можно было только так. Но в душе теплилась надежда, что эту проблему можно как то решить программным методом. Ведь в конечном итоге протокол IP же реализован программно. Вот была оказия. Надо было смотреть с компьютера камеры из другой подсети без потери доступа к интернету. И оказалось, что в Windows это настроить проще простого. В боевых условиях конечно не тестил, т.е. основной канал еще не отказывал, но я думаю, что все будет работать как надо.

Я понимаю, что несколько подсетей без роутеров - звучит как неправильная топология сети. Но иногда это нужно. Большинство компьютеров работают в основной сети, в которой используется динамическая адресация через железки провайдера, к которым нет доступа. Любое другое оборудование должно находится в других подсетях, но с использованием уже существующего железа первой сети.
« Последнее редактирование: 27.10.2021 20:12:34 от Mr.Madguy »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Боюсь, будет совсем не то, что Вы ожидаете: двух шлюзов в нормальном варианте быть не может от слова совсем. То, что с этим делает Windows, это её личные творческие неудачи. Хотя добавить и два можно, и три можно. Только, вероятно, не через GUI-свистелки.
Ну а как обычно происходит с несколькими сетевыми интерфейсами? Наверное так же, как и с несколькими DNS.
С DNS и близко ничего общего нет.
Если один не предоставляет маршрутизацию до заданного узла, то используется другой. Какой лучше с этим справляется - у того метрика выше. И в следующий раз обращение будет именно к нему.
А с чего Вы взяли, что это будет работать именно так?

У Вас есть интерфейс, есть марштут на роутер в сети на интерфейсе. Маршрут жив, пока жив интерфейс. С чего бы начинать использовать другой маршрут? Где и как это описано? Ну пропал IP роутера из ARP-таблицы, и что теперь? Вообще можно попробовать проверить, может это и правда в ядре в какой-то момент так сделали, но в общем случае, вроде бы, такое стандартами не описано.
Ставить вторую сетевую карту и подключать второй сетевой провод от того же свича, просто чтобы настроить второй интерфейс с другим IP и шлюзом?
Это ничего не изменит: принципиальной разницы тут нет, один и тот же интерфаейс, или разные. Если только не иметь ввиду проблему "линк пропал".
Я понимаю, что несколько подсетей без роутеров - звучит как неправильная топология сети.
Вот несколько разных сетей на одном физичесом интерфейсе - это, как раз, сколько угодно. Вот только default gw - один.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Но есть разные другие штуки. Например ECMP. Когда одинаковые маршруты есть, и они могут использоваться с балансировкой нгрузки. Но это другая история. Опять же, есть маршрутизация по политикам, может быть более одной таблицы маршрутизации, и там могут быть разные default gw.

Оффлайн Mr.Madguy

  • Давно тут
  • **
  • Сообщений: 249
Ну раз в Windows есть список шлюзов, значит это работает. Кто сказал, что из точки А в точку Б должен быть только один маршрут? А в Linux не знаю. Попробую создать любой статический маршрут и посмотреть, как он будет выглядеть в конфиге NetworkManager, а потом попробую его подправить под свои нужды.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Попробую создать любой статический маршрут и посмотреть, как он будет выглядеть в конфиге NetworkManager, а потом попробую его подправить под свои нужды.
Не факт, что он вообще будет выглядеть в конфиге NetworkManager: NM конфигурит ядро, а не наоборот.

Вообще, на самом деле, если у Вас статика, и непростая, я бы посоветовал отключить NM для статического интерфейса (или интерфейсов) и перейти на etcnet.
« Последнее редактирование: 27.10.2021 20:36:16 от asy »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Ну раз в Windows есть список шлюзов, значит это работает.
И да, это совершенно не значит, что оно работает предсказуемо.

Оффлайн Александр Ерещенко

  • Завсегдатай
  • *
  • Сообщений: 1 153
Ну раз в Windows есть список шлюзов, значит это работает.
А вы проверяли? :)
Как я понял у вас приблизительно такая физическая топология:
1) компьютер с тремя адресами (ip1, ip2, ip3) на одном интерфейсе, при этом указаны два шлюза по умолчанию, напр. def1 и def2
2) интерфейс компа соединён кабелем с коммутатором (свичём), к которому также подключены два роутера с внутренними адресами def1 и def2 (интерфейсы WAN у них, например inet1 и inet2)

Теперь проводим эксперимент под виндовс.
1) трассируем с компьютера какой-нибудь далёкий адрес, напр. 8.8.8.8
запоминаем, через какой роутер пошёл маршрут. Например, пусть это будет def1
2) отключаем кабель от роутера def1 к коммутатору. И смотрим, каким маршрутом пойдёт трассировка
3) подключаем кабель обратно и проверяем трассировку снова.
4) если переключение с роутера def1 на def2 проходило нормально автоматически, то действительно как-то это работало (проверка arp?)
Тогда делаем ещё эксперимент - отключаем кабель WAN у роутера def1 и ещё раз запускаем трассировку. Переключится ли автоматически?

Оффлайн Mr.Madguy

  • Давно тут
  • **
  • Сообщений: 249
Ну надо попробовать конечно. Но пока что в теории мне кажется, что все это выглядит так. Внутри сети проблем нет. Оно будет работать и без шлюза, т.к. можно посылать широковещательные ARP запросы. Если же у нас подсеть со статической адресацией, то можно просто прописать статический маршрут типа 192.168.1.0/24 через 192.168.1.1. Другое дело Интернет. Обращение туда может произойти за любым адресом. Т.е. по сути там адресация типа 0.0.0.0/0, которая в Linux называется, как я понимаю, default. За этим любым адресом всегда нужно обращаться к шлюзу. И есть всего два варианта его отказа. Либо он вообще не работает. Тут все очевидно. Либо нет подключения к интернету. И тогда он просто не вернет маршрутизацию. Другое дело, когда соединение уже установлено. Тут остается только надеяться, что ОС на самом деле опрашивает оба шлюза и хранит оба маршрута на случай, если один из них оборвется. И что ОС будет пытаться использовать рабочий маршрут или даже оба сразу. Очень хочется надеяться, что работать оно будет точно так же, как и в случае с физическими интерфейсами. Там, насколько я понял, при отключении интерфейса соответствующие маршруты просто пропадают из таблицы маршрутизации.

Даже может и не надо 100% надежности, чтобы соединения не обрывались. Пусть хотя бы автоматически переключается в случае отказа одного из маршрутов. Т.е. при повторной попытке установить соединение, чтобы обращение происходило к другому шлюзу. Несколько секунд потери связи не критичны.
« Последнее редактирование: 28.10.2021 15:03:42 от Mr.Madguy »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Другое дело Интернет. Обращение туда может произойти за любым адресом. Т.е. по сути там адресация типа 0.0.0.0/0, которая в Linux называется, как я понимаю, default.
В целом верно, нюанс в терминах. Правильно говорить про TCP/IP, а не про отдельно взятый случай "Интернет", хоть он и большой. Для IP пакета выбирается самый подходящий маршрут из имеющийся таблицы маршрутизации, затем пакет отправляется на тот маршрутизатор. И так далее. У обычного компьютера вся таблица сводится к маршруту по умолчанию, но маршрутов для разных подсетей может быть и больше. У разных маршрутов разные приоритеты, наибольший приоритет имеют более специфичные, для двух одинаковых вес может различаться от способа получения и/или вручную заданного веса (метрики).
Тут остается только надеяться, что ОС на самом деле опрашивает оба шлюза и хранит оба маршрута на случай, если один из них оборвется. И что ОС будет пытаться использовать рабочий маршрут или даже оба сразу.
В том и дело, что не надо надеяться, надо знать, как это должно работать, то есть как документировано. Два маршрута с одинаковой метрикой будут использованы одновременно только в специальных случаях.
Очень хочется надеяться, что работать оно будет точно так же, как и в случае с физическими интерфейсами. Там, насколько я понял, при отключении интерфейса соответствующие маршруты просто пропадают из таблицы маршрутизации.
С какой радости, если интерфейс не падает?

В нормальной жизни это всё решается динамической маршрутизацией (OSPF, IS-IS, RIP внутри автономной системы, BGP между автономными системами).

Обычному пользователю остаётся только что-то пингать и менять маршруты скриптом.

Оффлайн rits

  • Завсегдатай
  • *
  • Сообщений: 1 031
  • ITS
Ну надо попробовать конечно. Но пока что в теории мне кажется, что все это выглядит так. Внутри сети проблем нет. Оно будет работать и без шлюза, т.к. можно посылать широковещательные ARP запросы. Если же у нас подсеть со статической адресацией, то можно просто прописать статический маршрут типа 192.168.1.0/24 через 192.168.1.1. Другое дело Интернет. Обращение туда может произойти за любым адресом. Т.е. по сути там адресация типа 0.0.0.0/0, которая в Linux называется, как я понимаю, default. За этим любым адресом всегда нужно обращаться к шлюзу. И есть всего два варианта его отказа. Либо он вообще не работает. Тут все очевидно. Либо нет подключения к интернету. И тогда он просто не вернет маршрутизацию. Другое дело, когда соединение уже установлено. Тут остается только надеяться, что ОС на самом деле опрашивает оба шлюза и хранит оба маршрута на случай, если один из них оборвется. И что ОС будет пытаться использовать рабочий маршрут или даже оба сразу. Очень хочется надеяться, что работать оно будет точно так же, как и в случае с физическими интерфейсами. Там, насколько я понял, при отключении интерфейса соответствующие маршруты просто пропадают из таблицы маршрутизации.

Даже может и не надо 100% надежности, чтобы соединения не обрывались. Пусть хотя бы автоматически переключается в случае отказа одного из маршрутов. Т.е. при повторной попытке установить соединение, чтобы обращение происходило к другому шлюзу. Несколько секунд потери связи не критичны.

Я вижу только один вариант решения проблемы резервного канала - это повесить в кронтаб на каждую минуту запуск скрипта на проверку работоспособности канала. У меня одна сетевая в локалку и одна в интернет. В локалке есть еще один резервный шлюз .
Вот скрипт который у меня нет все времени проверить, но сама схема рабочая:
#!/bin/bash
#При пропадании канала у основного провайдера автоматически переключаемся
#на резервного и переодически проверяем наличие канала у первого
#провайдера. Как только интернет появляется у первого провайдера сразу
#переключаемся на него

#=# GW1=IP_шлюза_основного_провайдера
GW1=92.92.92.97

#=# GW2=IP_шлюза_резервного_провайдера
GW2=192.168.8.12

# Interfaces
#iface..=внешний
#iface1=ether0

#iface..=локальный
#iface2=ether1

#=# Удаленный адрес для проверки на доступность
srcinet=77.88.8.8
srcvpn=192.168.0.1
#=# IP1=внешний ip от основного провайдера
IP1=92.92.92.98

# Шлюз установленный по умолчанию
ROUTESTR1=$(ip r s | sed -n "/default via $GW1/p")
ROUTESTR2=$(ip r s | sed -n "/default via $GW2/p")

if [ -z "$ROUTESTR1" ] && [ -z "$ROUTESTR2" ]; then
echo "Проверте наличие правильного роутинга 'ip r s'"
exit 1
fi

# ${ROUTESTR1##*"$GW1"} - Удаление строки до последнего совпадения

# Пинг тест
ping -c 2 $srcinet -W1 &>/dev/null; pinginet=$?
ping -c 2 $IP1 -W1 &>/dev/null; pingip1=$?
ping -c 2 $srcvpn -W1 &>/dev/null; pingvpn=$?

# Отладочная информация
echo "ROUTESTR1 = $ROUTESTR1"
echo "ROUTESTR2 = $ROUTESTR2"
echo "pinginet  = $pinginet"
echo "pingip1   = $pingip1"
echo "pingvpn   = $pingvpn"

# Интернет отсутствует и шлюз резервного провайдера не установлен
if [[ $pinginet != 0 ]] && [[ -z $ROUTESTR2 ]]; then
echo "Перейти на резервный канал ..."
#/sbin/ip route del default via $GW1
#/sbin/ip route add default via $GW2
#ip route flush cache
#/etc/init.d/bind restart >> /dev/null
#ifdown tun0; sleep 5; ifup tun0
fi

# Внешний IP основного провайдера пингуется и шлюз основного провайдера не установлен
if [[ $pingip1 = 0 ]] && [[ -z $ROUTESTR1 ]]; then
echo "Перейти на основной канал ..."
#/sbin/ip route del default via $GW2
#/sbin/ip route add default via $GW1
#ip route flush cache
#/etc/init.d/bind restart >> /dev/null
#ifdown tun0; sleep 5; ifup tun0
fi

# Интернет есть и пинг основного vpn хоста отсутствует
if [[ $pingvpn != 0 ]] && [[ $pinginet = 0 ]]; then
echo "Перезапустить VPN ..."
#ifdown tun0; sleep 5; ifup tun0
fi
Можно еще более простые скрипты написать, все зависит от ситуации. Проверь, тема интересная.

Оффлайн flint1975

  • Завсегдатай
  • *
  • Сообщений: 1 425
    • Email
не рассмотрели вариант, когда требуется разные сервисы повесить на разных провайдеров.
Например есть 2 канала:
1. Кабельный оператор 10 мбит.
2. Мобильный оператор с быстрым каналом, около 70 мбит, но большим пингом 50-90 мс

задача: всех офисных сотрудников пустить в тырнет через мобильный канал, а людей на удаленке пускать внутрь по кабельному каналу.
Допустим внутрь их пускаем по ssh и openvpn,  дополнительно внутренние сервисы телефония (sip) должны ходить через кабель.
Ну и для усложнения: система резервного копирования должна использовать любой доступный канал, с приоритетом более скоростного канала.

Как это спроектировать?