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

Използвам декстоп Слака 10.1 си и да рутирам нета за съквартиранта със следните команди заложени в /етц/рц.д/рц.лоцал:

Примерен код

iptables -F; iptables -t nat -F; iptables -t mangle -F iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A INPUT -i ppp0 -p TCP --dport 6000 -j DROP iptables -A INPUT -i ppp0 -p UDP --dport 6000 -j DROP iptables -A INPUT -i ppp0 -p TCP --dport 137 -j DROP iptables -A INPUT -i ppp0 -p UDP --dport 137 -j DROP iptables -A INPUT -i ppp0 -p TCP --dport 445 -j DROP iptables -A INPUT -i ppp0 -p UDP --dport 445 -j DROP

Блокирането на портовете очевидно не работи ,така че не му обръщайте внимание, насочете се към Маскарадинга.

Този ред на айпитейбълс работи! Но изведнъж онзи ден престана да рутира- супер станно ми изглежда.

Другия комп не пингва нито днс-а нито някое вуншно айпи освен моето вътрешно и моето външно айпи (провайдера ми дава такова). Ебаси магията..някой има ли обяснение за това чудо?

iptables -t nat -A POSTROUTING -s 1.2.3.0/24 -j MASQUERADE

където 1.2.3.0/24 - адреса на вътрешната ви мрежа.

ще го пробвам, но с моята конфигурация си работеше..нищо не съм пипал - на другото ПЦ настрйките са както трябва и те не са пипани...супер странно е    

Дам и на мен ми се случи същото. Имах си перфектно работеща конфигурация която изведнъж спря да работи. Е, може и аз нещо да съм направил но от тогава пробвах толкова много неща че спирам да мисля че проблема е в моя компютър. Възможно ли е провайдера да блокира маскиране или нещо такова?

ami mislq 4e ne e providera..no namerih tromavo no byrzoreshenie..pusnash si apache-to da raboti kato proxy..no ne tromavo tova reshenie

echo "1" > /proc/sys/net/ipv4/ip_forward

Добре де, то реално възможно ли е въобще провайдера да разбере дали съответната връзка идва от моя комп или е маскирана и съответно да забрани маскираните пакети? Не е ли именно в това идеята на ip masquerading-а пакетите да изглеждат все едно са пратени от маскиращия компютър?
В моя случай само един компютър се конектва през моя така че в момента активно търся грешки в него (все пак е на вин ), но принципния въпрос за провайдера си остава.
Поздрави

TTL спада с единица при преминаването на рутер. За да се избегне това се ползва пач за ядтото pach-o-mat...нещо си там

направи едни ping от рутера към gw-то ти ли въобще и виж каква е стойността на ттл-а

Ми 0 е, сега ще се пробвам с пача на гигаволт и да се надяваме че ще стане. А да речем че ползвам прокси, то може ли да бъде "разкрито" от провайдера. По моето непрофесионално мнение там не би трябвало да намалява ТТЛ, или?

ами външното е динамично при всяко закачане се сменя, това е ИП-то с което се виждам в интернет, а вътрешното ми е от сорта на 10.2.х.х - т.е в локалната. Външните се раздават чрез pppoe протокола. Това за ехо "1" > ...еди какво си, го имам включено. Като се закача с adsl-start  и ми се вдига ppp0 интерфейса който е с външното айпи. Тва е системата в общи линии.

хич не му мисли ами слагай patchomatic-ng от www.netfilter.org и шибвай някакъв по свестен TTL и би трябвало да си готов

Съжалявам, аз съм индианец. Свалих си пача, но пак не става. Ето изрязка от скрипта ми за firewall:

Примерен код

iptables -t mangle -A PREROUTING -i eth1 -j TTL --ttl-inc 1 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

като eth1 ми е вътрешния а eth0 външния интерфейс. Някой да ми подскаже как се прави правилно?

iptables -t mangle -A OUTPUT -o eth0 -j TTL --ttl-set 64

Поради хардуерни проблеми чак сега можах да тествам дали след поправката на TTL интернета ми работи и какво да ви кажа, все още не бачка! Вече почвам да се отчайвам, ето ми го файъруол скрипта:

Примерен код

#set policy iptables -P INPUT  ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP #correct TTL iptables -t mangle -A OUTPUT -o eth0 -j TTL --ttl-set 64 #allow communication through the loopback interface iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #allow communication through eth1 iptables -A INPUT -i eth1 -j ACCEPT iptables -A OUTPUT -o eth1 -j ACCEPT #allow forwarding from and partly to eth1 iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT #set masquerading iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Останалото са само правила за забраняване и разрешаване на връзки към ftp, ssh и тн.
/proc/sys/net/ipv4/ip_forward също си е 1.
Някакви идеи?

ПС: Сори че толкова нагло си присвоих темата ти, int13...

Опитай дали има връзка без 'firewall'.
Румен

Ами провери дали въобще излизат пакети от ppp0 интерфейса навън, когато правиш някакви заявки от NAT-натата машина. Това става с командата:
tcpdump -n -i ppp0 host адреса_на_ppp0_интерфейса
Адресът може да се види с ifconfig ppp0
Преди да пуснеш дъмпа, на клиентската машина пускаш да върви пинг до някакъв IP адрес, който предварително знаеш (не по име, защото явно няма да имаш DNS резолвинг). Ако от дъмпа виждаш пингове от адреса на ppp0 интерфейса към този адрес, значи че маскирането ти работи и наистина е възможно доставчика ти да прави проблеми (малко вероятно). Ако не виждаш да излизат пакети от адреса на ppp0 интерфейса към адреса, който пингваш - проблема е при теб. Чак след този тест трябва да се впускаш в patch-o-matic-ване и т.н. BTW с обикновен модем ли си или ползваш PPPoE, PPTP или нещо такова?
P.S. За да си сигурен, че пакетите от клиентската машина идват до рутера ти, можеш да пуснеш един дъмп и на вътрешния интерфейс на рутера: tcpdump -n -i eth1 host адреса_на_клиентския_комп
Въобще, ползването на tcpdump е задължително за мрежовия администратор.
Best wishes!
Alex

Със следната команда:

Цитат

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

пакетите се рутират до етх0 ( върху която карта се закача ппп0 интерфейса чрез протокола pppoe) , но не излизат през ппп0. Защо? Нямам обяснение

PS: пинг до гейтуея ми връща стойности на ттл=48 ,това говори ли нещо?

А кой ти е default gateway-а след като стартираш adsl-start - би трябвало да е IP адрес, който се рутира през ppp0, а не през eth0

Default gateway си се определя от pppoe-то (там си бродкаства пакечтета и си се оправят някакси, не разбирам много), въпроса е че като дам tcpdump -i eth0 host вътрешната_машина виждам че вътрешната машина се опитва да пинга външно ай пи(аз съм пуснал да го прави), но пакетите си остават в eth0.Като дам tcpdump -i ppp0 host вътрешната_машина, никакви пингове към гоогле(в случая) не се виждат. От там правя заключение ,че пинговете си остават в eth0 и не се рутират до ppp0, защо е така, при положение ,че командата за НАТ-вано рутиране е правилна- а именно:

Цитат

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

и

Цитат

echo "1" > /proc/sys/net/ipv4/ip_forward

Пълна мистерия!!!! ((

Ъъм, аз по принцип нямам ppp0, това се е отнасяло до int13. А редовете съм взаимствл от едно howto на tldp.org и на мене лично ми се струват напълно логични. Както и да е де, с "iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j MASQUERADE" пак не става.
Според теб как трябва да изглежда реда с ттл?
Поздрави

Да, моя грешка, извинявай
единственото, което ми хрумва е да има някое policy из mangle и nat останало на DROP, но ми се вижда малко вероятно

Ми останалите редове общо взето са във формата

Примерен код

iptables -A INPUT -p tcp --dport *нещо си* -j ACCEPT

и завършват с едно голямо

Примерен код

iptables -A INPUT -m state --state NEW, INVALID -j DROP

Споменах ли вече че започвам да се отчайвам?

Огледай резултата от
iptables -L -t nat -n
iptables -L -t mangle -n

Така и не разбрах каква ти е дистрибуцията, но аз примерно ползвам RedHat  базирани (основно Fedora), там имаш възможност да запазиш някаква конфигурация на iptables и тя да се зарежда при boot. Идеята ми е, че ако имаш нещо подобно, това ще се наслагва на твоя скрипт.

Успех и не бързай да се отчайваш, пробвай почина на царя и гледай позитивно - имаш реалната възможност да си поблъскаш главата с интересен проблем, дори и  да не го решиш си струва да се напънеш, а ако го решиш е много сладко.

Дистрибуцията ми е Debian unstable, аз в началото на скрипта има още няколко реда които аз от удобство изпуснах да поствам, а именно:

Примерен код

iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -Z

Това би трябвало да очисти всякакви остатъци от правила, или?

а за моя случай, някой няма л да помогне? (((

Отново поради харуерни причини (клиентския компютър беше разглобен) чак сега последвах съвета на alex_c с tcpdump и стигнах до очудващия поне за мене извод че пакетите си се рутират към целта, но по пътя обратно си остават в рутиращия компютър, което ми е напълно необяснимо.

int13: Сори отново че така ти използвам темата, но мисля че решението на проблема ни е сходно, моето рутиране спря също толкова внезапно като твойто.
vlad73: Никъде няма DROP.

да прав си сходно е..но не мисля че е в ттл-ите проблема т ис какъв кернел си? Аз съм с 2.4.29 на слак 10.1.

2.6.12 на Debian unstable. И аз не мисля че е от ттл, но и си нямам ни най-малката идея от какво може да е. Възможно ли е все пак провайдера да ме преебава някакси? Нещо да изменя хедъра на пакетите така че рутера да не може да разбере че са от конекшъна към другия компютър или нещо такова. Уффф

Аз съм идиот.
След дълго време на незанимаване с този проблем изведнъж прозрях каква е причината да нямам рутиране - всичките пакети които получавам имат ттл 0 и затова не се и рутират обратно към клиентския компютър, а умират в рутера. Та моята е мисъл е да увеличавам ттл-а на всички пакети за клиента с едно, така че все пак да стигат до него. А въпроса ми е, как точно трябва да изглежда командата.
Пробвах "iptables -t mangle -A INPUT -i eth0 -j TTL -ttl-inc 1". Така като пингвам от рутера ми се изписва че ттл е 1 (а не 0 както беше преди...). Пинговете от другия компютър обаче все още умират с "ICMP time exceeded in-transit"  

Не го прави с ttl-inc!
Документацията на iptables казва:

Цитат

--ttl-inc value               Increment the TTL value `value' times.

Което означава, че ако напишеш ttl-inc 1 ще стане "увеличи ТТЛ един път"!
Аз го правя така:

Примерен код

iptables -t mangle -A INPUT -j TTL --ttl-set 64

Това кара всички пакети, които влизат да имат TTL = 64, което си е нормално. За изходните вериги също препоръчвам да сложиш едно ttl-set 64 , за да изглежда всичко все едно идва от рутера (всъщност не съм гледал как излизат отзад)

моля прочетете :

http://hardtrance.blogspot.com/2005/05/ttl-nat.html
и
http://hardtrance.blogspot.com/2005....ko.html

Боже, не мога да повярвам, работи!
Златния ред беше:

Цитат

iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 2

Направо ме е яд че не намерих блога ти по-рано...
А и, хъм, благодаря на всички които направиха това възможно.