Изпечатай

[never_mind]

От няколко седмици ISP-то ми прави проблеми. Има пуснат arp proxy на gw. Аз натвам 2 машини зад рутера ( debian etch ) - един Уин и един дебиан още. По някаква причина на външния интерфейс се получава това

Примерен код

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, за да не ми обърква мрежата?

[gat3way]

Ясно е защо го получаваш, когато уиндоуса "генерира трафик".

Защо не виждаш arp broadcast-а обаче нямам идея. Как пускаш tcpdump?

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

[never_mind]

С 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.  

[VladSun]

Пробвай на твоя рутер да сложиш статична АРП таблица ...

[never_mind]

Това и направих, но не стана. Сега пак е статична, но сложих arptables, която да филтрира всичко от вън. Проблема изчезна. E, филтрира и комуникацията ми с gw, затова и съм задал статична таблица. Проблемът е, че позволя ли комуникация с gw, той пак ми праща пакета с частното IP. Въпрос: Мога ли да накарам tcpdump да ми показва src и dst адреса на arp пакетите?
От това

Примерен код

arp reply 5.76.99.232 is-at 00:30:48:8d:2f:b1 (oui Unknown)

не се разбира нищо... кой праща reply и на кого?

[gat3way]

А, чакай, аз не съм разбрал явно.

Кой прави proxyarp, ти или доставчика?

Ако го правиш ти, то защо НАТ-ваш?

[never_mind]

Не го правя аз, а доставчика.

[VladSun]

Тогава пробвай без ARP протокол на интерфейсите и със статична таблица.

ПП: Това със статичната таблица и на вътрешните машини трябва да го направиш.

[gat3way]

Донякъде си представям какво точно се случва. От "другата страна" (демек след proxyarp рутера) има друга машина с ИП адрес същия като на уиндоус машината ти. Но там няма такава машина с адрес като на линукс-а ти, затова с него си нямаш проблеми.

В един момент, твоят рутер иска да разбере на какъв мак адрес съответства ип адреса на уиндоуса. Тогава или праща АРП заявки през всички интерфейси, или му се "дава" gratituous отговор от страна на рутера на доставчика ти и той го приема. Като резултат, вместо твоят рутер да осъществява L2 комуникация с уиндоуса, той се опитва да го прави с рутера на провайдъра ти.

Има два начина да се избегне това, първият е както каза VladSun да се набият статични АРП ентрита, това трябва със сигурност да сработи. Другият е да изръчкаш няколко настройки на ядрото по отношение на АРП "поведението", т.е:

echo 2 > /proc/sys/net/ipv4/conf/*/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/*/arp_filter

които контролират дали ядрото трябва да се занимава с АРП "дейности" през всичките си интерфейси или само през тези, които са в същия subnet. Мисля, че и това е вариант също '>

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

[never_mind]

Ето каква е хавата... gat3way, това със смяната 1-во го направих, не стана... тоест не е това , и със статична не става,  IP-то ми се мени по 3-пъти на ден, следователно и гейта '>. Къде бил проблема: по някаква причина ( бъг според мен ) от време на време НАТ-а ми не НАТ-ва '> , говоря за следното нещо

Примерен код

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 някакво си вътрешно. Някой да е изпитвал подобно нещо?

[gat3way]

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

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-нат твърде ниско, знам ли и аз...

[never_mind]

Пакетите са само от Уин-а, и аз не знам защо... когато вместо дебиан заредя Уин на другата вътрешна машина, и от него почва да логва не НАТ-нати пакети.

Примерен код

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 ( демек най-отгоре ).

[VladSun]

Цитат (never_mind @ Април 28 2007,10:45)

Примерен код -A OUTPUT -s 192.168.0.0/255.255.0.0 -o eth2 -j DROP не ги спира, а ми е първо правило за OUTPUT ( демек най-отгоре ).

NAT-натите пакети не са локални - т.е. не излизат от OUTPUT. NAT-a го правиш в POSTROUTING, трябва  да имаш подобно правило в тази верига, след SNAT-a ...

ПП: Дай един iptables -t nat -nxvL да видим за какво става въпрос.

[never_mind]

Примерен код

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

[VladSun]

Дай му още:

Примерен код

-t nat -А eth2_masq  -s 192.168.0.0/16 -j DROP