Как объединить двух провайдеров, увеличив скорость интернета?

#windows #маршрутизация #router

Есть два интернет провайдера.
Как можно при скачивании, например, торрентов, использовать сразу двух провайдеров?  

Либо как-то прописать айпи-адреса. Если один, то подключиться к одному провайдеру,
а если другой - то к другому. Ну либо как-то по другому.
Можно ли прописать в роутере? Либо ставить две сетевых карты? (Конечно, лучше в роутере,
чтоб с каждым компом не заморачиваться).

Спасибо.
    

Ответы

Ответ 1

Распределение нагрузки с лёгкостью можно реализовать на базе Mikrotik
Вся суть процесса сводится к настройке 2х каналов интернета,настройки NAT, удалить
шлюз по умолчанию, и назначить в качестве шлюзов эти 2 канала в зависимости от пропускной
способности.

192.168.1.249 - 1шлюз
192.168.222.1 - 2шлюз

вариант для балансировки 50/50   

 ip route add dst-address=0.0.0.0/0 gateway=192.168.1.249,192.168.222.1 


Предположим, что у первого провайдера скорость доступа в два раза выше чем у второго,
тогда 2/3 исходящих запросов надо направить на первого, а оставшиеся 1/3 на второго.

 ip route add dst-address=0.0.0.0/0
gateway=192.168.1.249,192.168.1.249,192.168.222.1


Полное описание процесса настройки

Более развёрнуто о способах балансировки нагрузки

ПС. Однако всякого рода Http, Https, ftp и тому подобный трафик нужно будет маркировать
и направлять ручками (или возможно используя скрипты)) на определённый канал дабы исключить
вариант смены IP при обновлении страниц к примеру


Ответ 2

Для того, чтобы вы могли одновременно работать через двух провайдеров, вам надо,
чтобы ваш белый ip маршрутизировался обоими провайдерами. Это возможно только в случае
PI-адресов, но сейчас IPv4 такие адреса вы не получите. Только IPv6. 

Варианты с маршрутизацией на железке проблемны тем, что для  сервера в инете у вас
будет то ip от одного провайдера, то ip от другого. И большинство серверов будет полагать,
что это разные клиенты и требовать заново авторизации, установления сессии и т.д.


Ответ 3

Сомневаюсь, что рядовые роутеры спомобны на такое.
Подключите 2 роутера в одну сеть. На втором роутере отключите раздачу DHCP. На клиентских
ПК укажите либо 2 шлюза с одинаковыми приоритетами, либо одной половине клиентов укажите
один шлюз, а второй половине - другой.


Ответ 4

В "продвинутых" роутерах возможно разделить трафик между двумя провайдерами. 

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

Малой кровью можно обойтись, если на одном из WAN-интерфейсов не указывать шлюза
по умолчанию, а в настройке маршрутизации прописАть через него маршрут(ы) в половину
Инета (адрес/маска, делить на глазок). Тогда всё, что попадает под указанные подсети,
пойдёт через второго прова, а остальное через того, чей остался дефолтный шлюз. Желательно
при этом трафик на узлы одного провайдера не пускать через шлюз другого.

А вот вариант, когда трафик сессии идёт то через одного, то через другого провайдера
(или через обоих одновременно) невозможен - потому как для этого нужна соотв. договорённость
и настройка синхронизации между ними, а зачем ИМ это надо?

iptables https перенаправление на nodejs (правило)

#linux #nodejs #iptables #маршрутизация

Здравствуйте! подскажите как указать правило для iptables перенаправлять все https
запросы на nodejs?

для http сделано так

iptables

sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:3000


nodejs

app.route('/*').get(function(req, res) {
  logreq(req);
  //res.send("");
});

function logreq(req){

  var method  = req.method
    , len = 10 - +method.length
    , met = new Array(len).join(" ");

  console.log("\n \033[32m ",me+met,"\033[42m\033[0m",
              "\033[33m hostname: \033[42m\033[0m",req.headers.host,
              "\033[32m Pathname: \033[42m\033[0m",req.url)
};

var server = app.listen(3000, '127.0.0.1', function(){

});

    

Ответы

Ответ 1

Проблема в том, что nodejs будет слушать порт не по ssl, а подключение будет подразумевать
использование ssl-шифрования. И браузер будет выдавать ошибку ssl, поскольку будет
ждать ssl-handshake, но его не получит. Е

Если вам необходимо слушать именно https, то ознакомьтесь с примером в документации:
https://nodejs.org/api/https.html

Странный роутинг в kohana3

#php #kohana_3 #маршрутизация

Приветствую вас. Столкнулся с очень странной проблемой: kohana3, судя по поведению,
в нетрезвом состоянии, так как при правильно заданном маршруте для роутера выскакивает
ошибочка:
Kohana_HTTP_Exception [ 404 ]: The requested URL signup was not found on this server.

Маршрут написан по мануалу в точности.
Route::set('assest', '',
    array(
        'action' => '(login|signup|logout)'
    ))
    ->defaults(array(
        'controller' => 'Assest'
    ));

.htaccess стандартный, изменения не вносились.
Вот такие вот странности, знает кто, как лечить это?    

Ответы

Ответ 1

Снова моя не внимательность, не обратил внимание на строчку из документации, так
как она написано очень мелким шрифтом, которая гласит, что маршрут должен быть задан
до стандартного :D

Как настроить маршрутизацию для двух сетевых карт с внешними ip?

#ubuntu #сервер #ip #маршрутизация

Имеется сервер с двумя сетевыми картами. В обе карты заходят два внешних IP (разные
подсети и маски).

Как сделать, чтобы извне их можно было пинговать одновременно? 

Прописываю маршрут route add -net 0.0.0.0 netmask 0.0.0.0 gw x.x.x.x dev p1p1, пинг
на первую сетевую идет, на вторую — нет, и наоборот.
    

Ответы

Ответ 1

первое, что я бы порекомендовал — удалить пакет network-manager: он облегчает настройку
сети в тривиальных ситуациях и лишь мешает в нетривиальных.

настройка маршриутизации для разных нетривиальных случае хорошо описана в документе,
известном под названием lartc. есть и переводы на русский, например на opennet. в частности,
про настройку маршрутизации для двух провайдеров написано в разделе 4.2.

есть неплохая (на вид) пошаговая инструкция по настройке балансировки между двумя
провайдерами (тремя несколько разными способами).

Чем отличается мост от коммутатора?

#сеть #потоки_данных #администрирование #маршрутизация #пакет

Хотел бы понять принцип работы коммутатора и чем он отличается от моста. Вопрос возник
ввиду совершенно разных определений на разных сайтах, противоречащих друг другу. 


Правильно ли я понимаю, что коммутатор - это устройство с
несколькими портами, которое в отличие от концентратора может
передавать сигнал на конкретный порт (концентратор может только
повторять на все порты) благодаря таблице маршрутизации?  
Тогда не пойму
как у коммутатора происходит обучение (таблица маршрутизации), ведь
пока на каждый из портов не будут отправлены данные, таблица полностью
не заполнится? Это значит, что пока таблица не заполнится, все
компьютеры сети смогут видеть, что я хотел передать только одному
конкретному компьютеру (это вроде как небезопасно)? 
Правильно ли я
понимаю, что концентратор работает как аналоговое устройство -
сигнал который передали он повторил и все? А коммутатор же как
цифро-аналоговое - он сначала цифровым образом разбил на пакеты инфу,
а потом уже по аналогу (кабелю) отправил в нужный порт (или во все порты, если идет
обучение)?
Чем мост отличается от коммутатора?

    

Ответы

Ответ 1

Да. Только это не совсем таблица маршрутизации;
Почитайте как работает протокол ARP;
Да. Примерно так
Они соединяют сети на разных уровнях. Мост - более сложная железка - может сделать
одну IP сеть с единым адресным пространством из разных сетей (в том числе удаленных
друг от друга)


Мост соединяет сети на втором уровне. Но трафик между "концами" моста может идти
через любые уровни. Мост анализирует сеть и собирает таблицу MACов отмечая какой физической
сети они принадлежат. Получая пакет анализирует адрес получателя. Если этот адрес не
принадлежит сети из которой пришел пакет мост передает его в другой интерфейс. Если
получатель и отправитель находятся в одной сети мост игнорирует пакет. В современных
сетях, наверное, самое распространенное применение в Wi-Fi точках доступа.


Ответ 2

Коммутатор работает на втором уровне модели OSI ( подуровень MAC ), так как анализирует
МАС-адреса внутри пакета 10( рис. .). Естественно, он выполняет и функции первого уровня.

Маршрутизаторы работают на третьем уровне модели OSI, так как они анализируют не
только MAC-адреса пакета, но и IP-адреса, то есть более глубоко проникают в инкапсулированный
пакет 


Задача сегментации сети, т.е. разделения пользователей на группы (сегменты) в соответствии
с их физическим размещением с целью уменьшения количества клиентов, соперничающих за
полосу пропускания, была решена с помощью устройства, называемого мостом (bridge).
Мост был разработан компанией Digital Equipment Corporation (DEC) в начале 1980-х годов
и представлял собой устройство канального уровня модели OSI (обычно двухпортовое),
предназначенное для объединения сегментов сети. В отличие от концентратора, мост не
просто пересылал пакеты данных из одного сегмента в другой, а анализировал и передавал
их только в том случае, если такая передача действительно была необходима, то есть
адрес рабочей станции назначения принадлежал другому сегменту. Таким образом, мост
изолировал трафик одного сегмента от трафика другого, уменьшая домен коллизий и повышая
общую производительность сети.

Однако мосты были эффективны лишь до тех пор, пока количество рабочих станций в сегменте
оставалось относительно невелико. Как только оно увеличивалось, в сетях возникала перегрузка
(переполнение приемных буферов сетевых устройств), которая приводила к потере пакетов.

Увеличение количества устройств, объединяемых в сети, повышение мощности процессоров
рабочих станций, появление мультимедийных приложений и приложений "клиент-сервер" требовали
большей полосы пропускания. В ответ на эти растущие требования фирмой Kalpana в 1990
г. на рынок был выпущен первый коммутатор (switch), получивший название EtherSwitch.

Коммутатор локальной сети

Коммутатор представлял собой многопортовый мост и также функционировал на канальном
уровне модели OSI. Основное отличие коммутатора от моста заключалось в том, что он
мог устанавливать одновременно несколько соединений между разными парами портов. При
передаче пакета через коммутатор в нем создавался отдельный виртуальный (либо реальный,
в зависимости от архитектуры) канал, по которому данные пересылались напрямую от порта-источника
к порту-получателю с максимально возможной для используемой технологии скоростью. Такой
принцип работы получил название "микросегментация". Благодаря микросегментации коммутаторы
получили возможность функционировать в режиме полного дуплекса (full duplex), что позволяло
каждой рабочей станции одновременно передавать и принимать данные, используя всю полосу
пропускания в обоих направлениях. Рабочей станции не приходилось конкурировать за полосу
пропускания с другими устройствами, в результате чего не происходили коллизии и повышалась
производительность сети.

Как роутер определяет путь до ip-адреса назначения?

#администрирование #ip #маршрутизация

Не пойму, как роутер понимает через какие еще маршрутизаторы нужно пройти пакету,
чтобы добраться до требуемого IP-адреса? Т.е., например, отправляется запрос на открытие
html-страницы с домашнего компьютера (через домашний роутер) в Волгограде на сайт,
хостинг которого находится в Мексике. И как этот домашний роутер поймет, через какие
из тясяч промежуточных роутеров нужно пропустить пакет, чтобы добраться до Мексики?
    

Ответы

Ответ 1

В маршрутизации есть понятие "шлюз по умолчанию" (default gateway). Фактически, наличие
его означает следующее: "если не знаешь маршрута к адресу назначения, отправь его на
шлюз по умолчанию".

Кроме маршрута по умолчанию роутер может знать и про конкретные подсети. Например,
домашний роутер обычно знает только свою внутреннюю подсеть, к которой подключены устройства
пользователя. Всё остальное он "кидает" на шлюз провайдера. Домашний роутер может также
знать про внутреннюю сеть провайдера, но обычно на этом его "знания" заканчиваются.

А вот роутеры провайдеров "знают" гораздо больше. Если не вникать во внутреннюю маршрутизацию
сети провайдера, то можно упрощённо сказать, что роутер провайдера знает про все внутренние
подсети провайдера, а также про подсети других провайдеров, к которым у него есть прямые
подключения (так называемый "пиринг"). Как ни странно, у большинства провайдеров тоже
есть шлюз по умолчанию, который ведёт к провайдеру более высокого уровня и масштаба
(так называемый "аплинк", uplink).

Но! На самой вершине сети находятся провайдеры из группы Tier-1. Их роутеры не имеют
шлюза по умолчанию. Они "знают" где находится любой IP-адрес. Провайдеры Tier-1 и обеспечивают
связность сети, т.е. позволяют соединиться между собой любым двум "белым" IP-адресам.
Естественно, что оборудование этих провайдеров не идёт ни в какое сравнение с обычными
домашними "железочками".

Следует добавить, что если мы знаем где находится адрес назначения, т.е. адрес роутера,
за которым он находится, это не означает, что этот целевой роутер единственный. Фактически,
с адресом роутера связывается подсеть, т.е. непрерывная группа адресов (или несколько
групп), которые обслуживает этот роутер (так называемый "префикс"). За этим роутером
может стоять группа других, каждый из которых обслуживает только часть этих адресов.
Например, провайдер может ставить по маршрутизатору на район и иметь один общегородской,
объединяющий районные подсети. Такая структура позволяет агрегировать адреса, уменьшая
число префиксов на уровне аплинков.

Таким образом, когда ваш домашний компьютер в Волгограде хочет получить страницу
с сайта в Мексике, он отправляет пакет на домашний роутер, тот - на маршрутизатор провайдера,
провайдер - своему аплинку и так до тех пор, пока не пакет не доберётся до провайдера,
который знает где находится мексиканский сайт (точнее, знает адрес роутера, за которым
он находится). Далее пакет проходит ещё цепочку маршрутизаторов, за которыми находятся
всё более мелкие подсети и, наконец, добирается до нужного сайта. Аналогичный процесс
происходит и когда сайт отправляет вам ответ.


Ответ 2

как роутер понимает через какие еще маршрутизаторы нужно пройти пакету, чтобы добраться
до требуемого IP-адреса?


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

Как узнать почему меняется таблица маршрутизации Linux

#linux #centos #маршрутизация

Подключил к серверу (centos7) Yota через USB как резервный канал связи. В первые
секунды всё ок, маршрут определяется правильно. Через несколько секунд маршрут по умолчанию
из таблицы маршрутизации пропадает.

При задании маршрута статически в конфиге и/или вручную через ip route ситуация повторяется. 
Адреса/маршруты на остальных картах прописаны статически.

Как узнать почему меняется таблица маршрутизации?
    

Ответы

Ответ 1

команда

ip monitor


по ней в реальном времени выводятся все изменения с IP-адресами, маршрутизацией и т.п.

В данном конкретном случае я увидел, что маршрут по-умолчанию удаляется каждый раз
при попытке создать ppp-соединение (основной способ подключения к интернет) и потом
восстанавливается снова.


Ответ 2

Если запретить менять таблицу маршрутизации для всех процессов через SELinux, то
виновник будет виден в audit.log

ASP.NET Сore 2.0 действие по умолчанию

Сводка недоступна. Нажмите эту ссылку, чтобы открыть запись.

Как блокируют доступ к сайтам? telnet vs. браузер

#http #dns #маршрутизация

При попытке открыть Кинозал.тв в любом браузере перебрасывает на заглушку РосКомНадзора.

Москва, провайдер ОнЛайм, OS X 10.11.2 El Capitan. DNS у меня стоят гугловские. Запрос
браузера идёт по правильному адресу, к CloudFlare – на этот же ip ресолвится имя сайта
и с зарубежных vps'ов. В ответ в браузеры приходит просто редирект на заглушку:



Если же проделать соединение не браузером, а telnet на порт 80, то всё работает как
положено – возвращается html страницы:



Это так же работает, если в telnet отправить все те же HTTP заголовки, что и шлёт
браузер:

GET / HTTP/1.1
Host: kinozal.tv
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101
Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: uid=1234567; pass=XXXXXXXX; __cfduid=abcdefe0171f2defb37070b1428009916; stylet=0
Connection: keep-alive


Хотя заголовок про gzip лучше убрать, а то в терминал валится нечитаемый бинарный
мусор компрессированного контента.

Пока единственная разница, которую нашёл – во времени: в telnet от момента соединения
до отправки заголовков проходит пара секунд, пока я вручную сделаю paste. В браузере
это происходит за миллисекунды. Надо попробовать с curl..

Вопросы: как и где происходит подмена ответа заблокированных серверов; Почему запросы
из telnet обходят этот механизм?

Нашёлся ответ habrahabr.ru/post/249433 в конце ответа после UPD. Вкратце:


  Стоило вам присмотреться к трафику, который приходит на интерфейс от Ростелекома.
Вероятно, DPI подключен параллельно, а не последовательно, и туда приходит только клиентский
трафик. Т.к. DPI стоит явно ближе, чем вебсайт, пакет с Location от DPI приходит быстрее,
чем реальный первый пакет от сайта, а пакет от сайта уже отбрасывается ядром ОС как
ретрансмиссия, поэтому, если вы используете Linux, достаточно одной строки в iptables,
чтобы обойти блокировку:

iptables -A INPUT -p tcp --sport 80 -m string --algo bm --string "http://95.167.13.50/?st"
-j DROP


    

Ответы

Ответ 1

запустил такую команду на двух компьютерах, один из которых находится в рф (провайдер
highlink), другой — в фрг:

$ echo -ne 'GET / HTTP/1.1\r\nHost: kinozal.tv\r\n\r\n' | nc -i 1 kinozal.tv 80


сравнение вывода этих команд (оставлены лишь существенные фрагменты):

$ diff -ruaN kinozal.frg kinozal.rf
--- kinozal.frg 2016-01-22 11:51:53.000000000 +0000
+++ kinozal.rf  2016-01-22 11:51:01.000000000 +0000
@@ -1,13 +1,21 @@
-HTTP/1.1 200 OK
-Date: Fri, 22 Jan 2016 11:51:18 GMT
-Content-Type: text/html; charset=windows-1251
-Transfer-Encoding: chunked
-Connection: keep-alive
-Set-Cookie: __cfduid=df6ffc8c31e9a6f6f2e233c7f44bf81761453463478; expires=Sat, 21-Jan-17
11:51:18 GMT; pa
th=/; domain=.kinozal.tv; HttpOnly
-Server: cloudflare-nginx
-CF-RAY: 268b0bd3e28e2690-FRA
+HTTP/1.1 302 Moved Temporarily
+Server: nginx/1.0.15
+Content-Type: text/html
+Content-Length: 173
+Connection: close
+Location: http://blocking.hl.ru:88

-505
+
+
+
+
302 Found
+
nginx/1.0.15
+
+
+
+------------0b0ac4bb16a6-ARN
+
+f77
 
 
 


дальше в обоих файлах идёт содержимое страницы, отдаваемой сайтом kinozal.tv.



как видно из вывода программы diff:


изменены заголовки ответа сервера, благодаря чему браузер должен повторить запрос,
но уже по адресу http://blocking.hl.ru:88 (доменное имя hl.ru принадлежит тому самому
провайдеру highlink);
после заголовка вставлен ещё один блок html с текстом-заглушкой.




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

ASP.NET WebApi и связаны ресурсы

Доброго времени суток.
Нужна ваша помощь. Есть ASP.NET WebApi приложение в котором нужно представить связь двух ресурсов. Например есть сущность StreetType которая возвращает json:
{ "id":3, "name":"StreetType1", }
и сущность Street
{ "id":1, "name":"Street1", "streettypeid":3 }
Ранее для получения связанных ресурсов использовал OData запрос: http://localhost:3761/api/Street?$expand=StreetType
Но, так как в некоторых сущностей может быть 3 и более связанных ресурсы то писать такие запросы будет сложно ну и не очень красиво.
Было бы неплохо реализовать это следующим образом:
http://localhost:3761/api/Street/ - все Street http://localhost:3761/api/full/Street/ - все Street и связанные ресурсы (в этом случае только StreetType) http://localhost:3761/api/Street/1 - Street с ID = 1 http://localhost:3761/api/full/Street/1 - Street с ID = 1 и связанные ресурсы
Но есть проблема с системой маршрутизации и наследованием атрибутов. Так как все это должно быть реализовано в базовом классе.
Вопрос: Как правильно реализовать представление связанных объектов? Как оформить простой URL например для такого запроса OData: http://localhost:3761/api/City?$expand=CityType,Region

Ответ

Есть небольшая книга по проектированию API интерфейсов автора Brian Mulloy, называется Web API Design Crafting Interfaces that Developers Love. В ней приводятся примеры, как вашу проблему решали крупные корпорации, в частности
Facebook: /joe.smith/friends?fields=id,name,picture Google: ?fields=title,media:group(media:thumbnail) LinkedIn: /people:(id,first-name,last-name,industry)
Можно так же разделять поля сущности на обязательные и дополнительные, где обязательные выгружать всегда, а дополнительные по запросу.
В целом, запрос http://localhost:3761/api/City?$expand=CityType,Region выглядит неправильно, т.к. вы сцепляете разные сущности. Логичнее получать Region отдельным запросом.

Laravel игнорирует метод в контроллере

Есть контроллер: class HomeController extends BaseController { public function index() { return View::make('hello'); } } и при наличии роута: Route::get('/', 'HomeController@index'); появляется ошибка: BadMethodCallException Method [index] does not exist. Команда php artisan routes, возвращает то что нужно: +--------+------------+------+----------------------+----------------+---------------+ | Domain | URI | Name | Action | Before Filters | After Filters | +--------+------------+------+----------------------+----------------+---------------+ | | GET|HEAD / | | HomeController@index | | | +--------+------------+------+----------------------+----------------+---------------+ Версия: Laravel 4.2.11

Ответ

Проблема решена. Вся проблема была в том что в папке vendor/laravel находилась папка laravel полностью дублирующая корневую директорию из-за этого пространства имен спутались и поиск был не в корневой директории а в папке vendor Пригодится кому-нибудь на будущее. :)

iptables https перенаправление на nodejs (правило)

Здравствуйте! подскажите как указать правило для iptables перенаправлять все https запросы на nodejs?
для http сделано так
iptables
sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:3000
nodejs
app.route('/*').get(function(req, res) { logreq(req); //res.send(""); });
function logreq(req){
var method = req.method , len = 10 - +method.length , met = new Array(len).join(" ");
console.log("
\033[32m ",me+met,"\033[42m\033[0m", "\033[33m hostname: \033[42m\033[0m",req.headers.host, "\033[32m Pathname: \033[42m\033[0m",req.url) };
var server = app.listen(3000, '127.0.0.1', function(){
});

Ответ

Проблема в том, что nodejs будет слушать порт не по ssl, а подключение будет подразумевать использование ssl-шифрования. И браузер будет выдавать ошибку ssl, поскольку будет ждать ssl-handshake, но его не получит. Е
Если вам необходимо слушать именно https, то ознакомьтесь с примером в документации: https://nodejs.org/api/https.html

Странный роутинг в kohana3

Приветствую вас. Столкнулся с очень странной проблемой: kohana3, судя по поведению, в нетрезвом состоянии, так как при правильно заданном маршруте для роутера выскакивает ошибочка: Kohana_HTTP_Exception [ 404 ]: The requested URL signup was not found on this server. Маршрут написан по мануалу в точности. Route::set('assest', '', array( 'action' => '(login|signup|logout)' )) ->defaults(array( 'controller' => 'Assest' )); .htaccess стандартный, изменения не вносились. Вот такие вот странности, знает кто, как лечить это?

Ответ

Снова моя не внимательность, не обратил внимание на строчку из документации, так как она написано очень мелким шрифтом, которая гласит, что маршрут должен быть задан до стандартного :D

Как узнать почему меняется таблица маршрутизации Linux

Подключил к серверу (centos7) Yota через USB как резервный канал связи. В первые секунды всё ок, маршрут определяется правильно. Через несколько секунд маршрут по умолчанию из таблицы маршрутизации пропадает.
При задании маршрута статически в конфиге и/или вручную через ip route ситуация повторяется. Адреса/маршруты на остальных картах прописаны статически.
Как узнать почему меняется таблица маршрутизации?

Ответ

команда
ip monitor
по ней в реальном времени выводятся все изменения с IP-адресами, маршрутизацией и т.п.
В данном конкретном случае я увидел, что маршрут по-умолчанию удаляется каждый раз при попытке создать ppp-соединение (основной способ подключения к интернет) и потом восстанавливается снова.