iptables > PREROUTING TTL

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

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

Перелогинься, палишся.

Как это? Палишся ?!

Влом твою историю смотреть. Логин смотри.

вот и я так подумал НО в примере (см. последние строки) считают иначе почемуто ... это меня и смутило

а ничо что при таком раскладе у тебя traceroute отвалится? :-)

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

при таком раскладе у тебя traceroute отвалится? :-)

а разве он уже не отвалился если у прова фильтрация по ttl?

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

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

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

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

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

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

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

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

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

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

Пакет идёт из локальной сети в Интернет. Попадает на локальный интерфейс маршрутизатора, потом в цепочку 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

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

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

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

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

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

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

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