LINUX.ORG.RU
ФорумAdmin

iptables > PREROUTING TTL


0

1

СХЕМА ПРОХОЖДЕНИЯ ЦЕПОЧЕК

про жадных провайдеров слышали все. про проверки по ttl думаю тоже. имеем примерно такую цепочку: =PC=iptables=provider=INET

ну узле provider стоит гейт с проверкой по ttl на узле iptables стоит наш гейт к которму есть доступ есть команда iptables -t mangle -A PREROUTING -i $EXTERNAL -j TTL --ttl-set 64 соответственно глядя на рисунок со схемой прохождения цепочек в iptables мне не оч понятно почему мы правим ttl в цепочке PREROUTING ведь не наш гейт проверяет ttl в провайдерский. тогда не логичнее было бы править ttl в цепочке POSTROUTING ?

iptables -t mangle -A PREROUTING -i $EXTERNAL -j TTL --ttl-set 64

Зачем вам вообще менять TTL на трафике который приходит на внешний интерфейс?

Если я вас правильно понял то вам скорее нужно так

iptables -t mangle -A POSTROUTING -o $EXTERNAL -j TTL --ttl-set 64

pyatak123
()

А по русски? Извини, нечитабельно.

Andreitsch
()
Ответ на: комментарий от Pinkbyte

Походу если не сделать такого хака, то чуваку вообще ничего будет не сделать)

pyatak123
()
Ответ на: комментарий от bravlin

Ну можно найти и другие примеры, где TTL меняют в POSTROUTING, или можно менять TTL в PREROUTING, но для локального интерфейса, а не для интерфейса к провайдеру. ИМХО, в вашем примере ошибка.

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

- исходящие - пакет приходит из локальной сетки на локальный интерфейс cкручивается ttl на единицу но включается наше правило и возращяет ttl в исходное состояние тогда пакет по нату прокидывается на внешний интерфейс и тут сново скручивается ttl на единицу и дальше он уходит к провайдерскому гейту.

- входящие - пакет приходит на внешний инт. нашего гейта и скручивает ttl на единицу идёт по нату и скручивает его ещё на единицу но т.к. наше правило закреплено за цепочкой PREROUTING на лоальном интерфейсе то в данном случае оно не срабатывает т.к. при входящих соединениях локальный интерфейс подпадает под цепочку POSTROUTING а не PREROUTING.

я правельно рассуждаю ? или iptables работает по другому принципу.

bravlin
() автор топика
Ответ на: комментарий от bravlin

Не совсем, ты ранее приводил схему, на которой сказано что routing на хосте выполняется один раз, а ttl декрементируется на этапе рутинга. TTl изымается тока на рутере на этапе рутинга, а не на нате и не где нибудь еще.

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

в последнем сообщении я описывал вариант который предложил mky.

pyatak123, а можно более популярным языком ? а то маны и без того запутанные лишней путаницы в голове не хочется.

bravlin
() автор топика
Ответ на: комментарий от bravlin

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

исходящие - пакет приходит из локальной сетки на локальный интерфейс cкручивается ttl на единицу но включается наше правило и возращяет ttl в исходное состояние тогда пакет по нату прокидывается на внешний интерфейс и тут сново скручивается ttl на единицу и дальше он уходит к провайдерскому гейту.

Что бы ты не думал, что TTL снимается несколько раз на одном хосте, только один раз, только на этапе рутинга. Т.е пришел пакет прошел цепочку PREROUTING, далее он маршрутизируется и декрементируется TTL, потом проходит цепочку POSTROUTING.

pyatak123
()
Ответ на: комментарий от bravlin

Пакет идёт из локальной сети в Интернет. Попадает на локальный интерфейс маршрутизатора, потом в цепочку PREROUTING таблицы mangle, здесь мы ставим TTL на единицу больше, чем надо, допустим 65:

iptables -I PREROUTING -i eth-ЛОКАЛЬНЫЙ -j TTL --ttl-set 65

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

Пакет идёт из Интернета в локальную сеть. Здесь, в принципе, не важно, что делается с TTL, всё одно локальный хост примет пакеты с любым TTL, он ведь не провайдер. Но вышеприведённое правило в PREROUTING не сработает, и TTL просто будет уменьшен один раз и всё.

Решение не очень красивое, лучше выставлять TTL в POSTROUTING'е, возможно, что это решение возникло из примера:

iptables -t mangle -I PREROUTING -j TTL --ttl-inc 1

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

есть такой нюанс : tracert\traceroute основан на TTL, и первым запрос который кидает трейсерт имеет TTL 1. соответственно на первом же узле пакет возращяется с ответом. второй запрос имет TTL 2 и т.д. возращяя названия узлов.

так вот есле мы будет на внутреннем интерфейсе в postrouting'е пользовать --ttl-set <значение> то наши трасера будут улетать соответствено на предлагаемые 64 хопа (для никсов) и 128 хопов (для виндов). поэтому я думаю вариант с --ttl-set отпадает.

bravlin
() автор топика
Ответ на: комментарий от bravlin

А сейчас работает traceroute, если провайдер режет по ttl?

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

у прова может не фильтрация, а просто по договору: «Если мы увидим что у вас там больше 1 компа(читай - пропалим TTL) - вам копец!»

Pinkbyte ★★★★★
()

Уменьшай ttl на postrouting`е и проблем не будет, знаю по себе, разумеется если в сети не еще маршрутизаторов, в этом случае уменьшай по —S <host>

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

edyard, зачем уменьшать-то ttl ?

получается нужно скрыть 2 вещи:

1. разницу в дефолтных ttl (64 для никсов и 128 для винды)

iptables -t mangle -A PREROUTING -i eth1(локальный) -j TTL --ttl-set 64
все будут никсами

2. скрученую единицу при прохождении пакетами нашего гейта

iptables -t mangle -A PREROUTING -i eth1(локальный) -j TTL --ttl-inc 1

или одним правилом

iptables -t mangle -A PREROUTING -i eth1(локальный) -j TTL --ttl-set 65

!!! тоесть как не крути роутинг из локальной сети работать не будет ?

bravlin
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.