Изпечатай

[PAIN1]

Ситуацията е следната, в мрежа съм, аз взимам нет от едно място , приятел от мрежата взима нет от друго място.Моя доставчик има собствен форум, аз давам на този мой приятел от локална мрежа достъп до този форум.До днеска нещата работеха.Но явно доставчика е правил нещо което не мога да разбера и днес не работят.
по подробно :

Примерен код

#!/bin/sh echo -n -e "  Setting firewall rules .. \n" echo 1 > /proc/sys/net/ipv4/ip_forward # Clearing rules /usr/sbin/iptables --flush /usr/sbin/iptables --table nat --flush /usr/sbin/iptables --delete-chain /usr/sbin/iptables --table nat --delete-chain /usr/sbin/iptables --table mangle --flush /usr/sbin/iptables --table mangle --delete-chain /usr/sbin/iptables -P INPUT ACCEPT /usr/sbin/iptables -F INPUT /usr/sbin/iptables -P OUTPUT ACCEPT /usr/sbin/iptables -F OUTPUT /usr/sbin/iptables -P FORWARD DROP /usr/sbin/iptables -F FORWARD echo -e "   FWD: Allow all connections OUT and only existing and related ones IN " #accounting thos ip-ta iptables -A FORWARD -s 10.3.0.41 iptables -A FORWARD -d 10.3.0.41 iptables -A FORWARD -s 10.3.0.35 iptables -A FORWARD -d 10.3.0.35 iptables -A FORWARD -s 10.3.0.42 iptables -A FORWARD -d 10.3.0.42 iptables -A FORWARD -s 10.3.0.43 iptables -A FORWARD -d 10.3.0.43 #end accounting iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT iptables -A FORWARD -j LOG /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.35 -d 84.43.191.3 -j MASQUERADE /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.34 -d 84.43.191.3 -j MASQUERADE /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.35 -d 193.110.223.3 -j MASQUERADE /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.34 -d 193.110.223.3 -j MASQUERADE /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.41  -j MASQUERADE /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.42  -j MASQUERADE /usr/sbin/iptables -t nat -A POSTROUTING -s 10.3.0.43  -j MASQUERADE

Така, 34 и 35 са съответно хората, на които давам достъп до форума, а 84 ..... 193..... са съответно форума и .... .
41 42 43 са ми виртуални машини на vmware които си правя експерименти с някои неща.Та по този начин бяха нещата до сега, но 34 и 35 няма форум вече .... а 41 42 ...... си имат.
Не успях да намеря решение ? А вие имате ли идеи ?

[kennedy]

ако е почнал да прави TTL проверка ?

[PAIN1]

Ами не съм сигурен какво искаш да ми кажеш, нито знам как да проверя, но очевидно е имало някакви промени.... странно обаче има проблем само когато ограничавам само до форума.
Как да проверя ?

[Noone]

Ping-ни някой, абв да речем, виж колко ти е ТТЛ-а (time to live) на пакетите. Ако е единица, значи доставчика ти е започнал да те ограничава, и ще трябва да си поиграеш с iptables повечко. Ако не, проблема е другаде.

[PAIN1]

Примерен код

64 bytes from http://www.abv.bg (194.153.145.80): icmp_seq=1 ttl=56 time=30.1 ms

Тоест скрипта който е писан горе би трябвало да бачка?
Други възможни шашми които може да са направили за да не ми работи ?

[Dean79]

На пръв поглед всичко си е добре.
Провери рутиранията на двете ip-та на които искаш да дадеш достъп. И добави 10.3.0.34 във FORWARD...
Бъди сигурен, че до тези машини ще се минава през твоето ip...
84.43.191.3
193.110.223.3
П.П. Предполагам знаеш как да вкараш рутиране '>

[PAIN1]

Абе всичко работеше до оня ден.Питам какво може да са направили от ИСП-то, че сега да не работи, предложения ?
Също ми е чудно защо като дам пълен достъп работи, а като дам достъп само до 84.43.191.3 193.110.223.3 не работи ?

[PAIN1]

Как да проверя TTL-а на пакетите които ми връща доставчика ?

[Noone]

Цитат

64 bytes from http://www.abv.bg (194.153.145.80): icmp_seq=1 ttl=56 time=30.1 ms

Вече си го направил...

[PAIN1]

Хм значи някой ме лъже.Да питам по друг начин тогава.
TTL-то което ми връща след пинг, е ттл-то което е останало по пътя от мене до мястот окъдето пингвам или остатъка му от мене, до мястото и от мястото до мене пак ?

[Noone]

Time to live

In computer and computer network technology, time to live (sometimes abbreviated TTL) is a limit on the period of time that a unit of data (e.g. a record) can exist before it is discarded.
Time to live of IP datagrams
In IPv4, time to live (TTL) is an 8-bit field in the Internet Protocol (IP) header. It is the 9th octet of 20. The time to live value can be thought of as an upper bound on the time that an IP datagram can exist in an internet system. The TTL field is set by the sender of the datagram, and reduced by every host on the route to its destination. If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to the sender. The purpose of the TTL field is to avoid a situation in which an undeliverable datagram keeps circulating on an internet system.

В общи линии си схванал. Ако пакета идваше  при теб със стойност ТТЛ=1, той нямаше да продължи нататък. Проблема явно е някъде другаде.

[voyager]

Сега като се замислих... могат да правят и еднопосочно TTL филтриране... Я си представете следната ситуация: isp приема пакети от клиента към големия лош интернет, само с ttl 64, защото знае, че това е ttl-а който идва от клиента, и всичко различно (63 примерно) е маскирано... т.е. пакетите от маскираните машини въобще не излизат в нет-а '> fun. Това е и доста тривиален начин за излавяне на NAT-нати връзки... '>

voyager

[PAIN1]

Цитат (voyager @ Фев. 01 2006,04:19)

Сега като се замислих... могат да правят и еднопосочно TTL филтриране... Я си представете следната ситуация: isp приема пакети от клиента към големия лош интернет, само с ttl 64, защото знае, че това е ttl-а който идва от клиента, и всичко различно (63 примерно) е маскирано... т.е. пакетите от маскираните машини въобще не излизат в нет-а '> fun. Това е и доста тривиален начин за излавяне на NAT-нати връзки... '> voyager

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

[Hapkoc]

/offtopic

Цитат

Сега като се замислих... могат да правят и еднопосочно TTL филтриране... Я си представете следната ситуация: isp приема пакети от клиента към големия лош интернет, само с ttl 64, защото знае, че това е ttl-а който идва от клиента, и всичко различно (63 примерно) е маскирано... т.е. пакетите от маскираните машини въобще не излизат в нет-а :) fun. Това е и доста тривиален начин за излавяне на NAT-нати връзки... :) voyager

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

иначе - да, възможно е наистина...

edit: опа, не видях горното. сори за повторението :)

[voyager]

Първо по темата: Виж, това със MASQUARADE май вече е outdated... прочети за SNAT как стават нещата. Може би всъщност искаш SNAT. Не знам доколко MASQUARADE работи, навсякъде чета използвайте SNAT.
А сега да си продължим мохабета... '>
Абе грубо и некоректно, ама я се замислете обикновенните users колко пъти си сменят ttl-а... (Дори и тези, дето знаят как става това) Още повече, че доколкото си спомням... на бозата и linux бяха един и същ ttl. Пък и ако го направят, имам чувството че ще му стане доста забавно на който търси "/where the f.+ is the f.+ problem.../ пакетите ми се връщат с правилен ttl..защо подяволите не се връщат отговори към машините зад моята машина?"'>