Титла: Arp проблеми
Публикувано от: never_mind в Apr 20, 2007, 21:31
От няколко седмици ISP-то ми прави проблеми. Има пуснат arp proxy на gw. Аз натвам 2 машини зад рутера ( debian etch ) - един Уин и един дебиан още. По някаква причина на външния интерфейс се получава това
и нета замира като отрязан с нож. Преди бях с openbsd на рутера, същият проблем. За пояснение X.X.X.X е адреса на Уин-а за НАТ, а Медиа адреса е всъщност MAC-а на гейта ( заради проксито ). Имам следния въпрос: Защо получавам такъв пакет и то само когато Уин-а генерира трафик, а не линукса? Защо през tcpdump виждам arp reply-то, но не и request-a? Как да блокирам/филтирам подобен reply, за да не ми обърква мрежата?
| Примерен код |
| arp reply X.X.X.X is-at 00:30:48:8d:2f:b1 (oui Unknown) |
и нета замира като отрязан с нож. Преди бях с openbsd на рутера, същият проблем. За пояснение X.X.X.X е адреса на Уин-а за НАТ, а Медиа адреса е всъщност MAC-а на гейта ( заради проксито ). Имам следния въпрос: Защо получавам такъв пакет и то само когато Уин-а генерира трафик, а не линукса? Защо през tcpdump виждам arp reply-то, но не и request-a? Как да блокирам/филтирам подобен reply, за да не ми обърква мрежата?
Титла: Arp проблеми
Публикувано от: gat3way в Apr 20, 2007, 23:50
Ясно е защо го получаваш, когато уиндоуса "генерира трафик".
Защо не виждаш arp broadcast-а обаче нямам идея. Как пускаш tcpdump?
Този пакет не ти "обърква" мрежата. Проблемът твърде вероятно е проблем на рутера на доставчика ти, който не иска да си говори с няколко IP адреси, които отговарят на един и същ ethernet адрес в arp таблицата му.
Защо не виждаш arp broadcast-а обаче нямам идея. Как пускаш tcpdump?
Този пакет не ти "обърква" мрежата. Проблемът твърде вероятно е проблем на рутера на доставчика ти, който не иска да си говори с няколко IP адреси, които отговарят на един и същ ethernet адрес в arp таблицата му.
Титла: Arp проблеми
Публикувано от: never_mind в Apr 21, 2007, 21:40
С 2 tcpdump-а - 1 на вътрешния и 1 на външния следя това:
когато получа на външния
arp reply 192.168.143.2 is-at 00:30:48:8d:2f:b1 (oui Unknown)
нета умира. След малко получавам на вътрешния
arp who-has 192.168.143.2 tell 192.168.143.1
arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
нета пак тръгва. Явно нормално си приемам броудкаста. Остава проблема откъде на къде ще получавам на външния подобен пакет? Вътрешния броудкаст от рутера към локала си е наред, през ~30 сек се премятат arp заявки
21:33:34.175015 arp who-has 192.168.143.2 tell 192.168.143.1
21:33:34.175185 arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
21:34:10.176326 arp who-has 192.168.143.2 tell 192.168.143.1
21:34:10.176488 arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
21:34:46.173634 arp who-has 192.168.143.2 tell 192.168.143.1
21:34:46.173827 arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
Но идва момента с пакета на външния с грешен медиа адрес и сичко се насира с извинение. Ще се побъркам вече. И аз не виждам арп заявката, няма такава просто. А има reply.
когато получа на външния
arp reply 192.168.143.2 is-at 00:30:48:8d:2f:b1 (oui Unknown)
нета умира. След малко получавам на вътрешния
arp who-has 192.168.143.2 tell 192.168.143.1
arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
нета пак тръгва. Явно нормално си приемам броудкаста. Остава проблема откъде на къде ще получавам на външния подобен пакет? Вътрешния броудкаст от рутера към локала си е наред, през ~30 сек се премятат arp заявки
21:33:34.175015 arp who-has 192.168.143.2 tell 192.168.143.1
21:33:34.175185 arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
21:34:10.176326 arp who-has 192.168.143.2 tell 192.168.143.1
21:34:10.176488 arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
21:34:46.173634 arp who-has 192.168.143.2 tell 192.168.143.1
21:34:46.173827 arp reply 192.168.143.2 is-at 00:a0:c9:6c:89:23 (oui Unknown)
Но идва момента с пакета на външния с грешен медиа адрес и сичко се насира с извинение. Ще се побъркам вече. И аз не виждам арп заявката, няма такава просто. А има reply.
Титла: Arp проблеми
Публикувано от: VladSun в Apr 21, 2007, 22:32
Пробвай на твоя рутер да сложиш статична АРП таблица ...
Титла: Arp проблеми
Публикувано от: never_mind в Apr 24, 2007, 21:58
Това и направих, но не стана. Сега пак е статична, но сложих arptables, която да филтрира всичко от вън. Проблема изчезна. E, филтрира и комуникацията ми с gw, затова и съм задал статична таблица. Проблемът е, че позволя ли комуникация с gw, той пак ми праща пакета с частното IP. Въпрос: Мога ли да накарам tcpdump да ми показва src и dst адреса на arp пакетите?
От това
не се разбира нищо... кой праща reply и на кого?
От това
| Примерен код |
| arp reply 5.76.99.232 is-at 00:30:48:8d:2f:b1 (oui Unknown) |
не се разбира нищо... кой праща reply и на кого?
Титла: Arp проблеми
Публикувано от: gat3way в Apr 24, 2007, 22:36
А, чакай, аз не съм разбрал явно.
Кой прави proxyarp, ти или доставчика?
Ако го правиш ти, то защо НАТ-ваш?
Кой прави proxyarp, ти или доставчика?
Ако го правиш ти, то защо НАТ-ваш?
Титла: Arp проблеми
Публикувано от: never_mind в Apr 25, 2007, 23:10
Не го правя аз, а доставчика.
Титла: Arp проблеми
Публикувано от: VladSun в Apr 25, 2007, 23:42
Тогава пробвай без ARP протокол на интерфейсите и със статична таблица.
ПП: Това със статичната таблица и на вътрешните машини трябва да го направиш.
ПП: Това със статичната таблица и на вътрешните машини трябва да го направиш.
Титла: Arp проблеми
Публикувано от: gat3way в Apr 26, 2007, 10:22
Донякъде си представям какво точно се случва. От "другата страна" (демек след proxyarp рутера) има друга машина с ИП адрес същия като на уиндоус машината ти. Но там няма такава машина с адрес като на линукс-а ти, затова с него си нямаш проблеми.
В един момент, твоят рутер иска да разбере на какъв мак адрес съответства ип адреса на уиндоуса. Тогава или праща АРП заявки през всички интерфейси, или му се "дава" gratituous отговор от страна на рутера на доставчика ти и той го приема. Като резултат, вместо твоят рутер да осъществява L2 комуникация с уиндоуса, той се опитва да го прави с рутера на провайдъра ти.
Има два начина да се избегне това, първият е както каза VladSun да се набият статични АРП ентрита, това трябва със сигурност да сработи. Другият е да изръчкаш няколко настройки на ядрото по отношение на АРП "поведението", т.е:
echo 2 > /proc/sys/net/ipv4/conf/*/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/*/arp_filter
които контролират дали ядрото трябва да се занимава с АРП "дейности" през всичките си интерфейси или само през тези, които са в същия subnet. Мисля, че и това е вариант също
А всъщност и трети вариант има, да смениш адресите на НАТ-натите машини с някакви за каквито със сигурност знаеш че не се ползват. За това може да се провери лесно с arping, рутера на доставчика ти или ще отговори от тяхно име, или не - при втория вариант вероятно можеш да ползваш адреса без проблем.
В един момент, твоят рутер иска да разбере на какъв мак адрес съответства ип адреса на уиндоуса. Тогава или праща АРП заявки през всички интерфейси, или му се "дава" gratituous отговор от страна на рутера на доставчика ти и той го приема. Като резултат, вместо твоят рутер да осъществява L2 комуникация с уиндоуса, той се опитва да го прави с рутера на провайдъра ти.
Има два начина да се избегне това, първият е както каза VladSun да се набият статични АРП ентрита, това трябва със сигурност да сработи. Другият е да изръчкаш няколко настройки на ядрото по отношение на АРП "поведението", т.е:
echo 2 > /proc/sys/net/ipv4/conf/*/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/*/arp_filter
които контролират дали ядрото трябва да се занимава с АРП "дейности" през всичките си интерфейси или само през тези, които са в същия subnet. Мисля, че и това е вариант също
А всъщност и трети вариант има, да смениш адресите на НАТ-натите машини с някакви за каквито със сигурност знаеш че не се ползват. За това може да се провери лесно с arping, рутера на доставчика ти или ще отговори от тяхно име, или не - при втория вариант вероятно можеш да ползваш адреса без проблем.
Титла: Arp проблеми
Публикувано от: never_mind в Apr 27, 2007, 08:30
Ето каква е хавата... gat3way, това със смяната 1-во го направих, не стана... тоест не е това , и със статична не става, IP-то ми се мени по 3-пъти на ден, следователно и гейта . Къде бил проблема: по някаква причина ( бъг според мен ) от време на време НАТ-а ми не НАТ-ва 
, говоря за следното нещо
Сами виждате... стандартен TCP пакет на 80 порт не бива НАТ-ван. Докато другите заявки от същата сесия на браузъра на вътрешния комп са си НАТ-вани... не знам каква е причината ( претоварване на рутера, бъг в НАТ модула на ядрото, се тая ... ) и като пратя навън подобно нещо ест че гейта ще ми отговори. Но този пакет е единичен, не някаква серия. И получи ли такъв, се задейства MAC/IP защитата на гейта, понеже пакета е с медиа адрес външния ми интерфейс, а IP някакво си вътрешно. Някой да е изпитвал подобно нещо?
. Къде бил проблема: по някаква причина ( бъг според мен ) от време на време НАТ-а ми не НАТ-ва , говоря за следното нещо| Примерен код |
| tcpdump -n -s 1500 -vvv -e -i eth2 ether src host 00:0B:6A:B6:9A:51 and src net 192.168.0.0/16 |
| Примерен код |
| 20:52:13.881991 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 53176, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.3230 > 87.120.40.135.80: F, cksum 0x2f0e (correct), 1150976501:1150976501(0) ack 1409321540 win 65368 |
Сами виждате... стандартен TCP пакет на 80 порт не бива НАТ-ван. Докато другите заявки от същата сесия на браузъра на вътрешния комп са си НАТ-вани... не знам каква е причината ( претоварване на рутера, бъг в НАТ модула на ядрото, се тая ... ) и като пратя навън подобно нещо ест че гейта ще ми отговори
. Но този пакет е единичен, не някаква серия. И получи ли такъв, се задейства MAC/IP защитата на гейта, понеже пакета е с медиа адрес външния ми интерфейс, а IP някакво си вътрешно. Някой да е изпитвал подобно нещо?Титла: Arp проблеми
Публикувано от: gat3way в Apr 27, 2007, 11:27
Хм, обаче в такъв случай ми изглежда странно само с уиндоус-а да ти се получават такива неща...знам ли..
BTW можеш ли да ми кажеш в момента в който това се случи какви са стойностите на:
/proc/sys/net/ipv4/netfilter/ip_conntrack_count
/proc/sys/net/ipv4/netfilter/ip_conntrack_max
/proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
Възможно е да си ударил лимита на conntrack entries и заради това да не успява да го НАТ-не...макар че само с 2 нат-нати машини е много странно как ще стане това. Освен ако по принцип не са много ниски. Също така, максималният брой по дефолт мисля че се сет-ваха по някаква формула, която взема предвид наличната РАМ. Ако няма много РАМ на машината е възможно да е size-нат твърде ниско, знам ли и аз...
BTW можеш ли да ми кажеш в момента в който това се случи какви са стойностите на:
/proc/sys/net/ipv4/netfilter/ip_conntrack_count
/proc/sys/net/ipv4/netfilter/ip_conntrack_max
/proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
Възможно е да си ударил лимита на conntrack entries и заради това да не успява да го НАТ-не...макар че само с 2 нат-нати машини е много странно как ще стане това. Освен ако по принцип не са много ниски. Също така, максималният брой по дефолт мисля че се сет-ваха по някаква формула, която взема предвид наличната РАМ. Ако няма много РАМ на машината е възможно да е size-нат твърде ниско, знам ли и аз...
Титла: Arp проблеми
Публикувано от: never_mind в Apr 28, 2007, 10:45
Пакетите са само от Уин-а, и аз не знам защо... когато вместо дебиан заредя Уин на другата вътрешна машина, и от него почва да логва не НАТ-нати пакети.
Далееч съм от лимита. Най-интересното е, че и
не ги спира, а ми е първо правило за OUTPUT ( демек най-отгоре ).
| Примерен код |
| cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count 310 cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max 8184 cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets 1023 |
Далееч съм от лимита. Най-интересното е, че и
| Примерен код |
| -A OUTPUT -s 192.168.0.0/255.255.0.0 -o eth2 -j DROP |
не ги спира, а ми е първо правило за OUTPUT ( демек най-отгоре ).
Титла: Arp проблеми
Публикувано от: VladSun в Apr 28, 2007, 14:27
| Цитат (never_mind @ Април 28 2007,10:45) | ||
не ги спира, а ми е първо правило за OUTPUT ( демек най-отгоре ). |
NAT-натите пакети не са локални - т.е. не излизат от OUTPUT. NAT-a го правиш в POSTROUTING, трябва да имаш подобно правило в тази верига, след SNAT-a ...
ПП: Дай един iptables -t nat -nxvL да видим за какво става въпрос.
Титла: Arp проблеми
Публикувано от: never_mind в Apr 28, 2007, 22:20
| Примерен код |
| Chain PREROUTING (policy ACCEPT 208629 packets, 15317551 bytes) pkts bytes target prot opt in out source destination 152277 8848056 net_dnat 0 -- eth2 * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol none Chain POSTROUTING (policy ACCEPT 85286 packets, 3672091 bytes) pkts bytes target prot opt in out source destination 139550 9932315 eth2_masq 0 -- * eth2 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 4242 packets, 395067 bytes) pkts bytes target prot opt in out source destination Chain eth2_masq (1 references) pkts bytes target prot opt in out source destination 8063 435275 MASQUERADE 0 -- * * 192.168.144.0/24 0.0.0.0/0 policy match dir out pol none 50316 6079397 MASQUERADE 0 -- * * 192.168.143.0/24 0.0.0.0/0 policy match dir out pol none Chain net_dnat (1 references) pkts bytes target prot opt in out source destination 3782 186416 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23080 to:192.168.143.2 |
Това е изхода, а ето ми и НАТ правилата
| Примерен код |
| *nat :PREROUTING ACCEPT [938:59043] :POSTROUTING ACCEPT [253:17349] :OUTPUT ACCEPT [60:9157] :eth2_masq - [0:0] :net_dnat - [0:0] -A PREROUTING -i eth2 -m policy --dir in --pol none -j net_dnat -A POSTROUTING -o eth2 -j eth2_masq -A eth2_masq -s 192.168.144.0/255.255.255.0 -m policy --dir out --pol none -j MASQUERADE -A eth2_masq -s 192.168.143.0/255.255.255.0 -m policy --dir out --pol none -j MASQUERADE -A net_dnat -p tcp -m tcp --dport 23080 -j DNAT --to-destination 192.168.143.2 |
Титла: Arp проблеми
Публикувано от: VladSun в Apr 28, 2007, 23:09
Дай му още:
| Примерен код |
| -t nat -А eth2_masq -s 192.168.0.0/16 -j DROP |
Титла: Arp проблеми
Публикувано от: never_mind в Apr 29, 2007, 10:38
Въведох го правилото, но то ще се изпълни само ако пакета не е от мрежа 144. или 143. нали? Това как ще ми спре пакетите от 143. пак да излизат от време на време?
p.s Мне, пак не става....
tcpdump -n -s 1500 -vvv -e -i eth2 ether src host 00:0B:6A:B6:9A:51 and src net 192.168.0.0/16
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 1500 bytes
12:51:25.336770 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 53248, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.23080 > 82.77.18.223.1875: F, cksum 0xc357 (correct), 2447601630:2447601630(0) ack 1208257703 win 65467
12:52:06.239291 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 53272, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.23080 > 82.77.18.223.2037: F, cksum 0x296a (correct), 2795668862:2795668862(0) ack 3792593289 win 65467
13:06:20.051024 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 14922, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.23080 > 82.77.18.223.1085: F, cksum 0x6881 (correct), 985780358:985780358(0) ack 1259527679 win 65467
и още 2 докато браузвам под вътрешния дебиан
13:31:19.017017 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 10621, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.144.2.33409 > 64.124.204.232.80: F, cksum 0x6794 (correct), 3819647837:3819647837(0) ack 4282159949 win 432 <nop,nop,timestamp 489605 37816374>
13:33:16.514133 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 10622, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.144.2.33409 > 64.124.204.232.80: F, cksum 0xf4d3 (correct), 0:0(0) ack 1 win 432 <nop,nop,timestamp 518981 37816374>
I give up ....
| Примерен код |
| -A eth2_masq -s 192.168.144.0/255.255.255.0 -m policy --dir out --pol none -j MASQUERADE -A eth2_masq -s 192.168.143.0/255.255.255.0 -m policy --dir out --pol none -j MASQUERADE -A eth2_masq -s 192.168.0.0/255.255.0.0 -j DROP |
p.s Мне, пак не става....
tcpdump -n -s 1500 -vvv -e -i eth2 ether src host 00:0B:6A:B6:9A:51 and src net 192.168.0.0/16
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 1500 bytes
12:51:25.336770 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 53248, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.23080 > 82.77.18.223.1875: F, cksum 0xc357 (correct), 2447601630:2447601630(0) ack 1208257703 win 65467
12:52:06.239291 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 53272, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.23080 > 82.77.18.223.2037: F, cksum 0x296a (correct), 2795668862:2795668862(0) ack 3792593289 win 65467
13:06:20.051024 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 127, id 14922, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.143.2.23080 > 82.77.18.223.1085: F, cksum 0x6881 (correct), 985780358:985780358(0) ack 1259527679 win 65467
и още 2 докато браузвам под вътрешния дебиан
13:31:19.017017 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 10621, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.144.2.33409 > 64.124.204.232.80: F, cksum 0x6794 (correct), 3819647837:3819647837(0) ack 4282159949 win 432 <nop,nop,timestamp 489605 37816374>
13:33:16.514133 00:0b:6a:b6:9a:51 > 00:30:48:8d:2f:b9, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 10622, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.144.2.33409 > 64.124.204.232.80: F, cksum 0xf4d3 (correct), 0:0(0) ack 1 win 432 <nop,nop,timestamp 518981 37816374>
I give up ....
Титла: Arp проблеми
Публикувано от: VladSun в Apr 29, 2007, 14:44
| Цитат (never_mind @ Април 29 2007,10:38) |
| Въведох го правилото, но то ще се изпълни само ако пакета не е от мрежа 144. или 143. нали? Това как ще ми спре пакетите от 143. пак да излизат от време на време? |
Напротив - последното правило ти спира пакетите от цялата 192.168.0.0/16 мрежа.
Имам въпрос: за какво са тия IPSEC match-ове (--dir, --pol)?
Титла: Arp проблеми
Публикувано от: voyager в Apr 29, 2007, 15:40
Ок, а пробва ли да правиш SNAT вместо MASQUARADE?
Доколкото съм запознат, MASQUARADE беше стария начин.. вече всичко е [S|D]NAT.
Пробвай нещо от сорта:
iptables -t nat -A POSTROUTING -s $INT_NET -o $OUT_IF -j SNAT --to-source $EXT_IP
и сподели каква е хавата. Успех!
пп: И наистина, VladSun задава много основателен въпрос... възможно е първия пакет да не попада в правилото което трябва, а просто да се форуардва без да му се прави никаква транслация (което се наблюдава). Пробвай и да ги разкараш. Колкото по-малко, по-прости и чисти правила толкова по-добре
Доколкото съм запознат, MASQUARADE беше стария начин.. вече всичко е [S|D]NAT.
Пробвай нещо от сорта:
iptables -t nat -A POSTROUTING -s $INT_NET -o $OUT_IF -j SNAT --to-source $EXT_IP
и сподели каква е хавата. Успех!
пп: И наистина, VladSun задава много основателен въпрос... възможно е първия пакет да не попада в правилото което трябва, а просто да се форуардва без да му се прави никаква транслация (което се наблюдава). Пробвай и да ги разкараш. Колкото по-малко, по-прости и чисти правила толкова по-добре
Титла: Arp проблеми
Публикувано от: never_mind в Apr 29, 2007, 19:33
Еми не мога SNAT, понеже IP-то ми се мени постоянно... значи правилата ми са генерирани от shorewall, понеже ми беше по-лесно с него. Сега вече съм прочел доста за iptables и ще направя мой си скрипт с по-малко глупости вътре...
Титла: Arp проблеми
Публикувано от: never_mind в Apr 30, 2007, 20:43
| Примерен код |
| # Generated by iptables-save v1.3.6 on Mon Apr 30 20:37:14 2007 *raw :PREROUTING ACCEPT [3169194:2290115178] :OUTPUT ACCEPT [119768:115928510] COMMIT # Completed on Mon Apr 30 20:37:14 2007 # Generated by iptables-save v1.3.6 on Mon Apr 30 20:37:14 2007 *nat :PREROUTING ACCEPT [34634:3698652] :POSTROUTING ACCEPT [35722:4341001] :OUTPUT ACCEPT [123:24265] -A PREROUTING -p tcp -m tcp --dport 23080 -j DNAT --to-destination 192.168.143.2 -A PREROUTING -p udp -m udp --dport 23080 -j DNAT --to-destination 192.168.143.2 -A POSTROUTING -s 192.168.143.0/255.255.255.0 -o eth2 -j MASQUERADE -A POSTROUTING -s 192.168.144.0/255.255.255.0 -o eth2 -j MASQUERADE COMMIT # Completed on Mon Apr 30 20:37:14 2007 # Generated by iptables-save v1.3.6 on Mon Apr 30 20:37:14 2007 *mangle :PREROUTING ACCEPT [3169209:2290115970] :INPUT ACCEPT [109950:15246625] :FORWARD ACCEPT [3048348:2273987045] :OUTPUT ACCEPT [119785:115930834] :POSTROUTING ACCEPT [3168107:2389943102] -A PREROUTING -i eth2 -j TTL --ttl-inc 1 -A POSTROUTING -s 192.168.0.0/255.255.0.0 -o eth2 -j TTL --ttl-set 64 COMMIT # Completed on Mon Apr 30 20:37:14 2007 # Generated by iptables-save v1.3.6 on Mon Apr 30 20:37:14 2007 *filter :INPUT DROP [0:0] :FORWARD DROP [142:8865] :OUTPUT ACCEPT [119576:115907758] :valid-dst - [0:0] :valid-src - [0:0] -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 3/sec -j ACCEPT -A INPUT -p tcp -m tcp --dport 23080 -j ACCEPT -A INPUT -p udp -m udp --dport 23080 -j ACCEPT -A INPUT -p tcp -m tcp --dport 13333:13334 --tcp-flags SYN,ACK SYN -j ACCEPT -A INPUT -p udp -m udp --dport 13333:13334 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 --tcp-flags SYN,ACK SYN -m limit --limit 5/sec -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,ACK SYN -m limit --limit 3/sec -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -s 192.168.143.0/255.255.255.0 -i eth0 -j ACCEPT -A INPUT -s 192.168.144.0/255.255.255.0 -i eth1 -j ACCEPT -A INPUT -i eth2 -j valid-src -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth1 -o eth2 -j ACCEPT -A FORWARD -i eth2 -o eth1 -j ACCEPT -A FORWARD -i eth2 -o eth0 -j ACCEPT -A FORWARD -i eth2 -j valid-src -A FORWARD -o eth2 -j valid-dst -A FORWARD -o eth2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.144.0/255.255.255.0 -d 192.168.143.0/255.255.255.0 -i eth1 -o eth0 -j ACCEPT -A OUTPUT -o eth2 -j valid-dst -A OUTPUT -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -d 192.168.143.0/255.255.255.0 -o eth1 -j ACCEPT -A OUTPUT -d 192.168.144.0/255.255.255.0 -o eth0 -j ACCEPT -A valid-src -s 10.0.0.0/255.0.0.0 -j REJECT --reject-with icmp-port-unreachable -A valid-src -s 172.16.0.0/255.240.0.0 -j REJECT --reject-with icmp-port-unreachable -A valid-src -s 192.168.0.0/255.255.0.0 -j REJECT --reject-with icmp-port-unreachable -A valid-src -s 224.0.0.0/240.0.0.0 -j REJECT --reject-with icmp-port-unreachable -A valid-src -s 240.0.0.0/248.0.0.0 -j REJECT --reject-with icmp-port-unreachable -A valid-src -s 127.0.0.0/255.0.0.0 -j REJECT --reject-with icmp-port-unreachable -A valid-src -j REJECT --reject-with icmp-port-unreachable COMMIT |
Пренаписах всичко, по просто от това не може... аре ся ми кажете къде бъркам в правилата, че изпускам пакети без да са НАТ-нати... Ще взема да си компилирам последното ядро, да не би да е бъг в него...