Pull to refresh

Comments 10

Вы конечно молодец, что запостили очередной конспект LARTC, но надеюсь ваш личный опыт выходит за рамки чистой теории и конспектирований. Скажите достаточно ли такой конфигурафии для заруливания всех пакетов приходящих на интерфейс eth1 на гейт 1.2.3.4 если нет, то почему, если да то почему:

echo «123 testtable» >> /etc/iproute2/rt_tables
ip rule add iif eth1 table testtable
ip route add default via 1.2.3.4 table testtable proto static


а также, как на практике убедиться(интересует минимальный набор команд), что ядро было собрано с необходимыми опциями в случае, если на целевой железке стоит очень специфичный Linux без исходников

1. Этого будет достаточно для заруливания всех IP-пакетов, приходящих на eth1, причем в Ethernet-фрейме, содержащем этот IP-пакет в качестве MAC-адреса получателя должен стоять MAC-адрес нашего eth1. Почему только эти пакеты? Потому что только эти пакеты роутятся по определению. Почему будут роутиться? Потому что прописаны такие правила, и они как ни странно работают. Можно поставить эксперимент:

На C3 делаем ip route add default via 192.168.12.1.
На C2 делаем ip route add default via 192.168.11.1 table 123 proto static и ip rule add iif eth0 table 123 (синтаксис не принципиален, работает также как и ip rule add iif eth0 lookup 123).
Генерируем трафик с C3 на любые адреса, кроме 192.168.12.0/24. Запускаем tcpdump на C1 и наблюдаем эти пакеты.
2. Очень просто:
# ip rule
RTNETLINK answers: Operation not supported
Dump terminated


Если есть /proc/config.gz, то zcat /proc/config.gz | grep CONFIG_IP_ADVANCED_ROUTER и zcat /proc/config.gz | grep CONFIG_IP_MULTIPLE_TABLES.
Спасибо. Приятно встретить не только теоретиков
Так как железка специфичная и линукс там соответствующий и очень обрезанный, то /proc/config.gz там нет.
А подозрения, что даже после успешного ввода ip rule всё может работать не так, как надо — есть
Спасибо за статью, многое из уже используемого стало понятным :)

Вопрос по условию from для table: там должны быть только IP локального хоста или могут быть любые, которые проходят через ядро (комп работает как шлюз NAT, например)?
Любые, которые проходят через ядро.
Из статьи:
Теперь рассмотрим простой пример. У нас есть некий шлюз, на него приходят пакеты с IP 192.168.1.20. Пакеты с этого IP нужно отправлять на шлюз 10.1.0.1...
После пятого перечитывания этого абзаца и задал вопрос, т. к. решил (при третьем перечитывании), что 192.168.1.20 — это IP локального интерфейса :)
Спасибо за пост, теперь все встало по полочкам, как в аптеке.
А как идеологически верно сохранять данные правила, чтобы после перезагрузки они работали?
Пока прописываю в post-up скрипты для интерфейсов.
Все от системы зависит, ИМХО. В Debian официальной вики рекомендуется писать в /etc/network/interfaces (post-up записи).
Sign up to leave a comment.

Articles