LINUX.ORG.RU
ФорумAdmin

зачем нужна default route?

 , ,


1

2

Зачем нужна default route в таблице main?

Описание ситуации:

  • удаляю default route в таблице main
  • добавляю такую же default route, но в таблицу 100, туда же роутинг на локалку.
  • маркирую исходящие пакеты в mangle\OUTPUT mark 1
  • добавляю правило: ip rule add fwmark 1 lookup 100
  • пинг гугла - Network is unreachable, гмм ок!
  • добавляю неправильный шлюз в таблицу main
  • пинг гугла - внезапно - пошел! естественно через таблицу 100, в которой правильный шлюз

Смотрю netfilter packet flow : написано, что решение о роутинге принимается после mangle\OUTPUT, то есть после моей маркировки. И мой пакет должен пойти в таблицу 100, а там шлюз есть.

Вопрос – фейковый шлюз в таблице main нужен просто чтоб был?

Ниже тестовый скрипт для проверки в Virtualbox, с одним сетевым интерфейсом типа NAT:

ip ro del default
ip ro del default
ip ro del default
ip ru add fwmark 1 tab 100
ip ro rep default via 10.0.2.2 tab 100
iptables -t mangle -I OUTPUT  -j MARK --set-mark 1

ping 8.8.8.8 -c2
# fail!

# add fake Gateway to the main Routing table
ip ro rep default via 10.0.2.100
ping 8.8.8.8 -c2
# success!!
★★★★★

На уровне предположения, из-за того что не известно какой исходящий адрес забиндить. Насколько я помню на правила iptables при bind не смотрят. Посмотрите что говорит ip ro get 8.8.8.8. Если было бы правило ip ru add from $LOCALIP lookup 100 тогда бы заработало.

Кастану vel он точно правду расскажет.

anc ★★★★★ ()

imho, routing decision принимается ДО того, как промаркированный пакет матчится с кастомными правилами маршрутизации. Соответственно, без default route оно работать и не будет.

Anoxemian ★★★★★ ()

При отправке исходящего пакета, если явно не задан исходящий адрес, ядро пытается его определить исходя из маршрутизации.
Это делается ещё ДО прохождения firewall-а и маркировок, т.к. окончательно пакет у нас ещё не сформирован.
Следовательно маршрутизацию проходит недопакет, у которого есть конкретный адрес получателя, а в качестве исходящего адреса у него 0.0.0.0. Поэтому для него могут сработать только те ip rule, которые не содержат условий по fwmark и конкретному src.
А уже дальше сформированный пакет проходит firewall, может быть промаркирован и снова перемаршрутизирован. При чём при повторной маршрутизации исходящий адрес уже не меняется (даже если маршрут содержит src x.x.x.x), измениться может только исходящий интерфейс и маршрутизатор.

Поэтому у вас правило, отправляющее в таблицу 100, и не срабатывает. Пакет запрыгивает в main, а там нет правила для него - неизвестно куда и как его отправлять.

spirit ★★★★★ ()
Ответ на: комментарий от anc

Если было бы правило ip ru add from $LOCALIP lookup 100 тогда бы заработало.

Не должно было заработать. spirit написал правильно, что все правила (rule) с ″from″ и ″fwmark″ не рассматриваются, соединение как-бы с адреса 0.0.0.0, а не $LOCALIP. Вобще как-то инфа не гуглится, как именно выбирается src-адрес. Если у маршрута не указан ″src″, то всегда ли берётся первый адрес с исходящего интерфейса с подходящим scope?

mky ★★★★★ ()
Ответ на: комментарий от mky

Простите, когда вызывается bind без указания конкретного интерфейса||адреса то выбирается на основании таблиц маршрутов где так же участвуют и правила. Но вот в марки никто не лезет ибо это затратно для каждой операции. Представьте что у вас 100500 правил в netfilter, на каждый ping пересмотреть?
И таки все норм робит без defgw в main но с ip ru которую я указал выше.
PS А то простите получаеться. «все не в ногу, только прапорщик в ногу» (с) . У всех работает только вот у прапорщика не работает.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)

До mangle output локально сгенерированный пакет без хоть сколь-нибудь корректного маршрута по умолчанию просто не добирается - сперва маршрутизация, потом raw output, а mangle output ещё позже: https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

С маршрутом через доступный шлюз или интерфейс пакет проходит через решение о маршрутизации, и дальше уже работают правила iptables. Если в примере сделать маршрут по умолчанию через недоступный адрес, ну условно говоря 172.16.0.1, с вероятностью 99% пакеты точно так же будут выбрасываться, потому что как попасть на 172.16.0.1 система не знает.

Альтернатива - ip ru a from all lookup 100, но это в целом не будет отличаться от работы системы с обычной таблицей маршрутизации. Собственно, а какой практический смысл в такой конфигурации?

koi-sama ()
Ответ на: комментарий от anc

Сейчас проверил. Не работает. Как правило:

ip ru add from $LOCALIP lookup 100

может помочь в выборе src-ip адреса, если этого адреса нет? 0.0.0.0 не совпадает с $LOCALIP.

Представьте что у вас 100500 правил в netfilter, на каждый ping пересмотреть?

Да не особо сложно. Просматриваются же 100500 маршрутов. И определять src-адрес нужно только при установлении соединения (первый пакет), а не для каждого пакета. Только смысла нет пытаться через просмотр правил маркировки пакета определять его src-адрес. Это у ТС вырожденный случай, а обычно маркировка завязана на src-адрес или CONNMARK, а их в тот момент нет.

mky ★★★★★ ()
Ответ на: комментарий от koi-sama

Собственно, а какой практический смысл в такой конфигурации?

Защита от черезмерно умного софта, который правит main таблицу маршрутизации. Нужно редко, но, ИМХО, лучше, чем, допустим, прописывать default в виде двух маршрутом (0.0.0.0/1 и 127.0.0.0/1).

mky ★★★★★ ()
Ответ на: комментарий от koi-sama

а mangle output ещё позже

точняк, я не в ту routing decision смотрел. Надо было смотреть, где route decision Output.

А после mangle Output уже нарисовано «reroute check», вот оно по идее и обрабатывает ip rule fwmark.

Теперь ясно!

Bers666 ★★★★★ ()
Последнее исправление: Bers666 (всего исправлений: 2)
Ответ на: комментарий от spirit

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

Вот это и было открытием , что 2 раза ядро смотрит в таблицу маршрутизации. Собственно, на картинке так и есть.
Спасибо всем ответившим.

Bers666 ★★★★★ ()
Ответ на: комментарий от mky

Сейчас проверил. Не работает.

Не знаю что именно вы проверяли но вот у меня в проде работает давно и в разных точках. Это стандартная схема когда у вас более одного прова, в таблицу main не добавлять defroute.

anc ★★★★★ ()
Ответ на: комментарий от anc

в таблицу main не добавлять defroute

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

что именно вы проверяли но вот у меня в проде работает

При чём тут продакшен, несколько провайдеров, куча интерфейсов. Это всё проверяется на десктопе, с одной сетёвкой. Удалил default route и ping 8.8.8.8 перестал работать:
(ping: connect: Network is unreachable).

Добавл это правило:

ip rule add from $LOCALIP lookup 100

добавил default route в таблицу 100. Всё одно ping не работает.
Работает только ping -I $LOCALIP 8.8.8.8.

mky ★★★★★ ()
Ответ на: комментарий от mky

О, нашёл я тот топик, где vel вам объяснял. Маршрутизация маркированных iptables пакетов.

Там ведь чётко написано, что:

3) (настоятельно рекомендуется) нужно просмотреть таблицу с DGW которая определяла маршрут если нет предпочтений.

2070: from all lookup 12

Если вы удаляет default route из main, у вас обязательно должно быть правило ″from all″, а не ″from $LOCALIP″, указывающее на таблицу с default route.

mky ★★★★★ ()
Ответ на: комментарий от mky

Да, действительно, чего это я. :( Виноват. Посыпаю голову пеплом. У меня же много правил вида «from all». Я же сам приводил свои правила хоть и с сокращенном виде на этом форуме и не раз.
ЗЫ Насчет той темы я в курсе, у меня даже закладка на ответ vel которую я привожу в части main.

anc ★★★★★ ()
Ответ на: комментарий от anc

Ну и хорошо :) Жаль, что во всяких howto, в том числе и LARTC про это не пишут, информация о том, что маршут выбирается дважды есть диаграммах и т.д. Но информация о том, что первый раз таблица просматривается для пакета с src 0.0.0.0 прячится в глубинах форумов...

mky ★★★★★ ()
Ответ на: комментарий от mky

Как раз благодаря ответу vel, я привел постепенно все системы в порядок, точнее гораздо более лаконичный вариант. А то ранее куча марков за марками и марками погоняет :) И любое изменение было более затратно по времени (это не забыть, это не забыть и т.д.) не сказать что не реализуемо, все работало, но больше времени тратишь на изменения.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)