Linux за българи: Форуми

Значи доставчика ми намали ttl-a на 0 и немога да си шерна нет на другия комп през линукс.Ако някой може да каже как става?Пробвах с  iptables -t mangle -I PREROUTING -i eth0 -j TTL --ttl-inc 1
както ме посъветваха във форума но не стана.Някой да има други идеи?

В твоя случай --ttl-inc 1 трябва да е равно на 2. Моя iptables изглежда по този начин:

Цитат

# Generated by iptables-save v1.3.7 on Thu Jul 19 02:02:01 2007 *mangle :PREROUTING ACCEPT [3:375] :INPUT ACCEPT [3:375] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [3:459] :POSTROUTING ACCEPT [3:459] -A PREROUTING -i eth0 -j TTL --ttl-inc 2 -A POSTROUTING -s 172.16.0.0/255.240.0.0 -o eth0 -j TTL --ttl-set 64 COMMIT

Последният ред е защото има windows-ки машини в мрежата, ако ти нямаш не ти трябва. Повече информация можеш да намериш в тази статия или в различните теми по този въпрос във форума.

Надявам се това да помогне. В кратце:

 # iptables -t mangle -A PREROUTING -i ppp0 -j TTL --ttl-inc 1
# iptables -t mangle -A POSTROUTING -s 192.168.10.0/24 -o ppp0 -j TTL --ttl-inc 1

Замени ppp0 с външния ти интерфейс (ако е небоходимо)

a{6} ме изпревари

# iptables -t mangle -A PREROUTING -i ppp0 -j TTL --ttl-inc 1

Като напиша това и ми дава  Unknown error 4294967295

ванчо ванчо ...

Имаш ли идея какво прави редчето което са ти написали?

Явно не ...

ако нета ти идва с PPPoE тогава се ползва ppp0 ако нета ти идва на eth0 се ползва eth0 aко нета ти идва на eth1 се ползва eth1 ... схвана ли идеята ...

Ако пипаш TTL в PREROUTING трябва да го дигнеш с 2

Извинявам се просто копнах тва дето ми бехте писали иначе пробвах с eth0 тя е с реалното ип.
Просто като прочетох насам натам и разбрах че кърнела не поддържа модула ipt_ttl.ko или нещо такова,и трябва да се прекомпилира.

Секунда така.

1. Модулът, който ти трябва е ipt_TTL.ko, това не е най-важното в случая.

2. С каква дистрибуция си? Много малко съвременни дистрибуции не поддържат въпросния модул в stock ядрата си...

Slackware 11.0 по принцип има файл ipt_ttl.ko.gz във директорията с модулите на кърнела.

Ще трябва някой slack-аджия да се изкаже, но като гледам в ядрото, което се инсталира по подразбиране на Slackware 11 (2.4.33.3), го няма модула ipt_TTL.

Имай предвид, че ipt_ttl и ipt_TTL са два различни модула.

И аз мисля, че го нямаше ... Пачвай с PoM-a

@zeridon - мисля, че и ТТЛ=1 ще мине - имаше една дискусия за това и доколкото си спомням: рутер, който получава пакет с ТТЛ=1 и дестинация следващия хоп на рутера се пропуска.

Значи само да вметна нещо , на стрият ми рутер със Слак 10.2 и iptables - 1.3.5 мисля беше просто нямам спомени коя беше версията и ядро 2.4.33 това :

Примерен код

/usr/sbin/iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1 /usr/sbin/iptables -t mangle -A POSTROUTING -s 192.168.10.20 -o eth0 -j TTL --ttl-set 64

си работеше безпроблемно.
Дори и да е със Слак 11 но пък с базовото ядро не би трябвало да му прави грижи.

"т.е. zeridon е прав - трябва -ttl-inc 2 поне." - цък, и с 1 става. Доставчика ми дава нет с TTL=1
plamen@sempron ~ $ ping -c 3 www.data.bg
PING web.data.bg (195.149.248.130) 56(84) bytes of data.
64 bytes from web.data.bg (195.149.248.130): icmp_seq=1 ttl=1 time=3.64 ms
64 bytes from web.data.bg (195.149.248.130): icmp_seq=2 ttl=1 time=4.00 ms
64 bytes from web.data.bg (195.149.248.130): icmp_seq=3 ttl=1 time=3.98 ms

--- web.data.bg ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 3.643/3.876/4.005/0.165 ms

а правилата са ми:
iptables -t nat -A POSTROUTING -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -o ${OUTSIDE_DEVICE} -j MASQUERADE
iptables -t mangle -A PREROUTING -i ${OUTSIDE_DEVICE} -j TTL --ttl-inc 1
iptables -t mangle -A INPUT -i ${OUTSIDE_DEVICE} -j TTL --ttl-dec 1
iptables -t mangle -A POSTROUTING -o ${OUTSIDE_DEVICE} -j TTL --ttl-inc 1

"А на него му дава с 0." - на неговите думи ли се позоваваш или си го видял на практика?!? Не се правя на голям спец (т.е. може и да греша), но нещо не мога да си го представя. До колкото знам (а и практиката го доказва) пакет с TTL=0 не съществува - иначе защо ще го инкрементирам, за да ми дойде интернета в локалната мрежа? А ако не го направя (при TTL=1 на рутера, т.е. 0 след него) - няма нет във вътрешната мрежа.

А, аз съм сигурен, че съществува
Пробвай

на рутера:

Примерен код

iptables -t mangle -I POSTROUTING -o eth[LAN] -j TTL --set-ttl 0

И не разчитай много на ping-a

Примерен код

iptables -t mangle -I POSTROUTING -p ! icmp -o eth[LAN] -j TTL --set-ttl 0

   

TTL 0 "няма" според спецификацията на IP протокола - обаче ние в България си имаме друга идея по въпроса. А дали съществува на практика - в Мегалан очевидно съществува

http://forums.megalan.bg/index.p....t=13023

Не е ли забавно всичките ICMP echo replies да ти се връщат с ттл=0, както оня пич е пейстнал

Забавното е че линукс-ките и уиндоус-ките мрежови стекове не издропват такива пакети, въпреки че са невалидни според протоколната спецификация.

И поради това, очевидно не е проблем да ти ги намалят до 0. Сега следва по-интересната част - един познат е вързан на тях и ползва 802.11 рутер, чиито фърмуер е с някаква олигофренска ОС от сорта на VxWorks. Рутерът за щастие има някаква опция, която се сетва през уеб интерфейса - "do not change TTL in transit" или нещо от сорта. До известно време това работи, в един момент гореспоменатият провайдър решава мъдро вместо да смъква TTL-а не на 1, а на 0. И фърмуера, понеже коректно си спазва спецификациите, просто издропва тези пакети. Естествено, не можеш да се оплачеш, защото не е коректно, естествено и на първо време идеята не е да лъжеш, че не НАТ-ваш. От друга страна, тоя 802.11 рутер просто си хартисва. А от трета страна, човекът наистина си ползва интернет само на една машина, просто обича да се размотава с нея из апартамента. А, да, и най-забавното е че при това положение има 2 варианта: спират да му режат ТТЛ-а, но ограничението за максимален брой ТСР сесии пада над 2 пъти. Или алтернативно: спират да му режат ТТЛ-а, максималният брой конекции се запазва, но това излиза с някаква приятна сума отгоре на месец.

Ей, забавно нещо са нашенските ISP-та наистина