форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Маршрутизация, NAT / Linux)
Изначальное сообщение		[ Отслеживать ]

"Нестабильный Интернет у клиентов"	+/–
Сообщение от lucky89 (ok) on 24-Янв-11, 01:56
Здравствуйте! Есть такая проблема: канал в Интернет 15 Мбит, но у клиентов то все быстро и качественно работает, то страница открывается после 50 обновлений и как-то весело, то одна половина графики не загружается, то вторая, то форматирования нет, то вообще не откроется, хотя пинг с ними всегда есть. Если в моменты таких глюков протестировать скорость интернета (http://speed.yoip.ru/), то с ней все в порядке - высокая. С DNS проблем тоже нет, в любой момент исправно определяет ипы. На сервере стоит Debian без графики, по этому состояние Интернета проверяю только пингом - всегда есть. ---  -  ---  -  --- Есть вот только одна особенность моей сети: В здании раскинута сеть моего провайдера через обычные неуправляемые свитчи, работает DHCP, Интернет раздается просто по LAN. К моим клиентам идут провода от этих же свитчей. Чтобы не тягать лишних проводов я просто вбил у них статические настройки, разумеется отличные от провайдерских, и получилась подсеть 192.168.102.0/24. Так вообще можно делать??? Из сервера получается обе сетевухи смотрят физически в один и тот же свитч, но настройки разных сетей: auto lo iface lo inet loopback # Internet auto eth1 iface eth1 inet dhcp # Home3 auto eth0 iface eth0 inet static address 192.168.102.102 netmask 255.255.255.0 Раньше провайдер раздавал интернет через vpn - все было отлично, как только перешел на LAN, стали происходить вышеупомянутые чудеса. Правда и сервер у меня был раньше на Windows XP и Kerio стоял, но теперь хоть на винде, хоть на линуксе глюки есть... Даже и не знаю что делать... Настройки iptables: echo 1 > /proc/sys/net/ipv4/ip_forward #Чистим таблицу iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -t nat -X iptables -t mangle -X #Правила поумолчанию iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT #DNS-форватинг iptables -t nat -A PREROUTING -s 192.168.102.0/24 -p udp --dport 53 -j DNAT --to-destination 172.31.240.4 iptables -t nat -A POSTROUTING -p udp --destination 172.31.240.4 --dport 53 -j SNAT --to-source 172.30.186.22 #Менять ip при выходе в интернет iptables -t nat -A POSTROUTING -d ! 192.168.102.0/24 -j SNAT --to-source 172.30.186.22 Помогите, чем можете!!!
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Нестабильный Интернет у клиентов"	+/–
Сообщение от VolanD (ok) on 24-Янв-11, 08:33
>[оверквотинг удален] > iptables -P FORWARD ACCEPT > iptables -P OUTPUT ACCEPT > #DNS-форватинг > iptables -t nat -A PREROUTING -s 192.168.102.0/24 -p udp --dport 53 -j > DNAT --to-destination 172.31.240.4 > iptables -t nat -A POSTROUTING -p udp --destination 172.31.240.4 --dport 53 -j > SNAT --to-source 172.30.186.22 > #Менять ip при выходе в интернет > iptables -t nat -A POSTROUTING -d ! 192.168.102.0/24 -j SNAT --to-source 172.30.186.22 > Помогите, чем можете!!! Повесить на внешку (вместо сервака) один комп и потестить веб на нем?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 24-Янв-11, 11:04
	> Повесить на внешку (вместо сервака) >  один комп и потестить веб на нем? Если убрать сервер и поставить инет на 1 комп, то на нем все аж летает, начанаешь с него раздавать и полезут сразу косяки. Опять же повторюсь, косяки время от времени, при чем равновероятно хоть я 1 клиента повешу, хоть 70.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Нестабильный Интернет у клиентов"	+/–
Сообщение от Слоупок (ok) on 24-Янв-11, 15:49
Маскарадинг я бы сделал по-другому. iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.30.186.22 А вообще надо анализировать трафик, чтобы понять в чём дело. Провайдерский DNS-сервер лоялен к большому количеству запросов с одного IP? Пинги от клиентов до твоего сервера и до провайдерского шлюза с какими потерями идут?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от rr (ok) on 24-Янв-11, 16:09
	А провода и неуправляемые свичи кому принадлежат?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 25-Янв-11, 00:07
	> А провода и неуправляемые свичи кому принадлежат? 90% мне, ну как мне, общественности, это здание общежитие и сетка тут общая, доступ к ящикам есть.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 25-Янв-11, 00:04
	> Маскарадинг я бы сделал по-другому. > iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 172.30.186.22 > А вообще надо анализировать трафик, чтобы понять в чём дело. Как это делается?? > Провайдерский DNS-сервер лоялен к большому количеству запросов с одного IP? Думаю, что да, если даже это не так, то я пробовал всякие разные сервера из Интернета писать - один результат. > Пинги от клиентов до твоего сервера и до провайдерского шлюза с какими Пинг даже до любого из сайтов в любой момент времени с 0-2% потерь идет (тестировал по несколько часов) > потерями идут? Аськи, скайпы, всяческие игры, фтп сервера, все сразу коннектится, а вот http косячит частенько.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 25-Янв-11, 17:34
	>> А вообще надо анализировать трафик, чтобы понять в чём дело. > Как это делается?? Ну на клиентской машине запускаешь анализатор пакетов в момент проблемы (например tcpdump или что там есть у винадминов) и смотришь, что отсылает машина при выполнении проблемного действия, что приходит ей в ответ, что не приходит, а должно бы, или идёт долго, или не то что нужно, ну вот как-то так, в общем. > Аськи, скайпы, всяческие игры, фтп сервера, все сразу коннектится, а вот http > косячит частенько. В сочетании с тем, что пинги вроде как нормально ходят, у меня это вызывает подозрение на то, что проблема именно в DNS, т.к. эти приложения, скорее всего, обращаются к серверам в интернете по IP, а в браузерах все вводят имена сайтов. Чтобы проверить предположение можешь вот в момент проблемы у клиента, на его машине пингануть проблемный сайт, чтобы узнать его IP и ломиться в браузере прямо на IP. Если проканает, значит проблема в DNS, если нет -значит, что проблема не (или не только) в DNS.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	12. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 25-Янв-11, 17:42
	>Думаю, что да, если даже это не так, то я пробовал всякие разные сервера из Интернета писать - один результат. В смысле пробовал разные DNS-серверы указывать? Если так, то хреново, чё... ))
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 31-Янв-11, 08:59
	> Чтобы проверить предположение можешь вот в момент проблемы у клиента, на его > машине пингануть проблемный сайт, чтобы узнать его IP и ломиться в > браузере прямо на IP. Если проканает, значит проблема в DNS, если > нет -значит, что проблема не (или не только) в DNS. В момент глюков, командой ping ип определился сразу, пинг пошел без потерь, при попытке в браузер вставить этот ип ничего не изменилось... говорю же нормально все с ДНСом. Есть еще мысли?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	9. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 25-Янв-11, 00:11
	>
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Нестабильный Интернет у клиентов"	+/–
Сообщение от Deac (??) on 24-Янв-11, 18:02
У провайдера стоит ограничение на количество одновременных сессий.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 25-Янв-11, 00:09
	> У провайдера стоит ограничение на количество одновременных сессий. Если это действительно так, то как узнать какое именно ограничение? И еще, знакомый от этого же провайдера нормально инет раздает (в моей же сети), только он vpn сервер поднял.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 25-Янв-11, 17:39
	каких таких сессий? Сессия одна - с его сервером. Все его клиенты просто NATятся через него и провайдер вообще об их количестве ничего не знает.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	13. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Deac (ok) on 25-Янв-11, 19:44
	> каких таких сессий? Сессия одна - с его сервером. Все его клиенты > просто NATятся через него и провайдер вообще об их количестве ничего > не знает. В терминах FreeBSD см. src/dst limit. И провайдеру по барабану количество его клиентов, сделал dst limit 100, например и всё. Напрямую выявить этого нельзя, только косвенными методами, по возникновению ситуаций аналогичных TC.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 25-Янв-11, 21:11
	Ну, понятно. Для меня термины BSD - мунспик :-)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "Нестабильный Интернет у клиентов"	+/–
Сообщение от pavel_simple (ok) on 31-Янв-11, 13:29
> Помогите, чем можете!!! iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Vitalik (??) on 01-Фев-11, 17:59
	>> Помогите, чем можете!!! > iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS > --clamp-mss-to-pmtu Почти у всех MTU отличное от стандартного 1500, сам долго мучался, когда ADSL на 512Кбит, а такое впечатление, что интернет работает избирательно.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 02-Фев-11, 11:48
	> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS > --clamp-mss-to-pmtu Добавил эту строку - улучшений в работе Интернета нет...
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от rusadmin (ok) on 02-Фев-11, 12:02
	>> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS >> --clamp-mss-to-pmtu > Добавил эту строку - улучшений в работе Интернета нет... У меня проблема решилась после изменения MTU внутреннего интерфейса на 1400 и добавления парвила iptables которое описано выше
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от rusadmin (ok) on 02-Фев-11, 12:06
	man iptables TCPMSS        This  target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus        40 for IPv4 or 60 for IPv6, respectively).  Of course, it can only be used in conjunction with -p tcp.  It is only valid in the mangle table.        This target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big" packets.   The  symptoms  of  this        problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:         1) Web browsers connect, then hang with no data received.         2) Small mail works fine, but large emails hang.         3) ssh works fine, but scp hangs after initial handshaking.        Workaround: activate this option and add a rule to your firewall configuration like:         iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \                     -j TCPMSS --clamp-mss-to-pmtu        --set-mss value               Explicitly set MSS option to specified value.        --clamp-mss-to-pmtu               Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).        These options are mutually exclusive. описалово номер 1 как в твоем случае
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	24. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 02-Фев-11, 15:42
	> описалово номер 1 как в твоем случае Согласен, но пробовал добавить iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu и пробовал iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 Никаких результатов...
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	22. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 02-Фев-11, 12:07
	> У меня проблема решилась после изменения MTU внутреннего интерфейса на 1400 Как изменять MTU? Его нужно уменьшить именно для внутреннего интерфейса или для внешнего тоже?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

20. "Нестабильный Интернет у клиентов"	+/–
Сообщение от desenix (ok) on 02-Фев-11, 12:05
отдели сеть провайдера от своей, думаю в этом дело. А такие баги наблюдал на двух или более машинах, когда у них совпадал MAC адрес, почему он совпадал, дело десятое :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 02-Фев-11, 12:16
	> отдели сеть провайдера от своей, думаю в этом дело. > А такие баги наблюдал на двух или более машинах, когда у них > совпадал MAC адрес, почему он совпадал, дело десятое :) Не вариант сети разделять - у нас в ящиках черт ногу сломит, да и люди все (мои и не мои клиенты) должны быть в одной сети, нужно лишь в эту сеть грамотно добавить шлюз в Интернет.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	25. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 02-Фев-11, 16:42
	такое построение сети уже не грамотное. Если кто в сеть пускает ARP флуд, то можно попробовать прописать MAC шлюза у клиентов в статическую ARP таблицу.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	26. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 02-Фев-11, 19:58
	> Если кто в сеть пускает ARP флуд, то можно попробовать прописать MAC > шлюза у клиентов в статическую ARP таблицу. Про флуд - это вряд ли... Т.е. прописать у клиентов в ARP мак сетевухи моего сервера смотрящей в локалку?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 03-Фев-11, 04:22
	Еще момент интересный! Пишу у клиента arp -a и он определят мак сервера той сетевухи, которая в инет смотрит, а не в локалку. Во как! Т.е. IP от eth0 а mac от eth2 (см. начало темы).
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	28. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 03-Фев-11, 06:52
	> Еще момент интересный! Пишу у клиента arp -a и он определят мак > сервера той сетевухи, которая в инет смотрит, а не в локалку. > Во как! Т.е. IP от eth0 а mac от eth2 (см. > начало темы). Вспомнил, это древний баг ARP протокола в Linux системах. Поясню на примере, имеем Net1-----[{MAC1,IP1}PC{MAC2,IP2}]-----Net2 так вот, если дать ARP запрос из Net1 для IP2, то получим ответ MAC1,IP2. Этот баг некоторые провайдеры использовали для поиска роутеров у клиентов. Как от этого избавится? как уже говорил, писать клиентам статическую ARP таблицу, второй вариант, фильтровать на сетевухах не свои ARP запросы, например с помощью ebtables http://ru.wikipedia.org/wiki/Ebtables PS: всё таки это ARP флуд был, но генерит его твой же сервер :) PSS: есть ещё вариант решения, оставить одну сетевуху и на неё повесить две сети, два IP.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	30. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 03-Фев-11, 07:51
	Что-то я не наблюдаю таких багов на Debian 5.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	31. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 03-Фев-11, 08:01
	> Что-то я не наблюдаю таких багов на Debian 5. м.б. там полечили, а наблюдать надо с помощью команды http://ru.wikipedia.org/wiki/Arping естественно с другой машины.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	37. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 04-Фев-11, 08:41
	>> Что-то я не наблюдаю таких багов на Debian 5. > м.б. там полечили, а наблюдать надо с помощью команды http://ru.wikipedia.org/wiki/Arping > естественно с другой машины. Я только сейчас понял о чём речь. Никакой это не баг, а вполне адекватное поведение ядра, т.к. по-умолчанию обращение к любому интерфейсу разрешается с любого интерфейса. Заноситься такие "соответствия" (как вот ниже я привёл) не будут в кэш arp клиента т.к. отсылающая запрос станция видит, что запрос к IP-адресу не из её подсети. В этом случае она шлёт пакеты на дефолтный маршрут, поэтому и arp-запрос будет выполнен только ко внутреннему интерфейсу шлюза для определения его мака, либо не будет выполнен вообще, если кэш итак свежий. Баг т.е. соответствия mac/ip в таблице у клиента: внешIP/внутр mac внутрIP/внутр mac может быть только в том случае, если IP-адреса у сервера на обоих интерфейсах из той же подсети, что и у клиента. В этом случае нужно в ручную в таблице маршрутизации указывать - на каком конкретно интерфейсе тот или иной хост. Это тупо. Так никто не делает. Ну а если делают, то оооочень крайних случаях в виде исключения, когда компов от силы 2-3. И, кстати, даже в этом случае несоответствия по сути нет. Если оба адреса висят через один интерфейс, то да. Это именно так и должно выглядеть в arp-таблице клиента. И причём должно работать нормально, если маршруты на шлюзе прописаны верно.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	38. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 04-Фев-11, 09:04
	Можно почитать в каком RFC это "нормальное поведение" описано и узаконено ? И ведут ли себя так же форточные компьютеры? Кстати из разных подсетей интерфейсы так же отвечают, сам видел. Сижу в сети провайдера 10.xxx.0.0/8 даю ARPING 192.168.1.1 и вижу несколько ответов с разными MAC, ага думаю, роутеры в локалке. Вот так-то. Мне вообще кажется что в Linux сеть сделали тяп ляп, оно и понятно.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	39. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 04-Фев-11, 09:22
	Нет RFC по Linux. о поведении форточных компьютеров я могу тоже кое-что сказать. Например ты пробовал на XPшке расшарить подключение? Тебя не удивило появление, в той сети, в которую шарить, неуправляемого DHCP-сервера принудительно всем раздающего адреса из сети 192.168.1.0? :-)) В каком RFC такое поведение узаконено? ) Вот и я про то же. >Кстати из разных подсетей интерфейсы так же отвечают, сам видел. Сижу в сети провайдера 10.xxx.0.0/8 даю ARPING 192.168.1.1 и вижу несколько ответов с разными MAC, ага думаю, роутеры в локалке. Быдлороутеры , d-link и пр вата )) Если бы на них был настроен секьюрный фаервол хрен бы такая штука сработала. Нормальная сеть у пингвинов. По-мне дак она, как автомат Калашникова работает, надо только знать как собрать и разобрать :-) А вот в окошках есть кнопочка "исправить" которая регулярно обламывается получить новый адрес по DHCP и приходится класть весь интерфейс. А в самом плохом случае перезагружать винду, так как интерфейсы там тоже бывает тупят.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 04-Фев-11, 09:50
	>Кстати из разных подсетей интерфейсы так же отвечают, сам видел. Отвечать то они ответят. Я говорю про то, что записи в arp-таблицах не делаются в таком случае. Поэтому говорить о том, что arp или linux работает некорректно нельзя.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	41. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 04-Фев-11, 10:03
	> Нет RFC по Linux. При чём тут линух, по сетям, в каких документах регламентировано такое поведение? Или то что сделали в линухе теперь стандарт для всех как закон? тогда это фанатизм. > о поведении форточных компьютеров я могу тоже кое-что сказать. Например ты пробовал > на XPшке расшарить подключение? Тебя не удивило появление, в той сети, > в которую шарить, неуправляемого DHCP-сервера принудительно всем раздающего адреса из > сети 192.168.1.0? :-)) Именно в XP расшаривал, почему-то DHCP у меня не появлялся ни разу, хотя нужен был. Вот то что он принудительно сеть выбирал только 192.168.1.0/24 и с другой не работал, это от убогости ума мелкософта. > В каком RFC такое поведение узаконено? ) Вот и я про то > же. см. в начале. >>Кстати из разных подсетей интерфейсы так же отвечают, сам видел. Сижу в сети провайдера 10.xxx.0.0/8 даю ARPING 192.168.1.1 и вижу несколько ответов с разными MAC, ага думаю, роутеры в локалке. > Быдлороутеры , d-link и пр вата )) Если бы на них был так же на линух машинах это видел, и не я один, версию ядра не подскажу > настроен секьюрный фаервол хрен бы такая штука сработала. с каких пор iptables умеет фильтровать ARP ? я им даже DHCP клиента не мог отфильтровать, потому что этот гад открывал сырой сокет, и клал на фильтры. Кстати ARP не должно в ядро попадать, оно должно крутится около своего адаптера, по большому счёту ядру вообще не нужно знать об этих пакетах. > Нормальная сеть у пингвинов. По-мне дак она, как автомат Калашникова работает, надо > только знать как собрать и разобрать :-) А ещё надо тысячу её собственных нюансов учитывать, про которые постоянно забываешь. Один большой +, всё бесплатно, и делай шо хошь. > А вот в окошках есть кнопочка "исправить" которая регулярно обламывается получить новый > адрес по DHCP и приходится класть весь интерфейс. А в самом > плохом случае перезагружать винду, так как интерфейсы там тоже бывает тупят. Эта кнопочка у меня нормально работает, если например клиент подымется раньше чем DHCP сервер после вкл. питания, то эта кнопочка хорошо помогает. А вот чтоб новый попросить, она не поможет, у тебя ведь аренда не истекла, не имеет права, для этого сначала адрес освободи ipconfig /release а потом новый проси. Лучше просто скрипт написать, если часто надо.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	42. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 04-Фев-11, 11:44
	> При чём тут линух, по сетям, в каких документах регламентировано такое поведение? > Или то что сделали в линухе теперь стандарт для всех как > закон? тогда это фанатизм. Я уже утерял нить беседы. ))))) Короче в Linux с помощю sysctl можно выбирать маршрутизируемые интерфейсы. Закончим на том, что реализация arp в Linux не нарушает RFC826(ARP) при любом раскладе, так как по любой из записей в arp-таблице можно достучаться до IP. :-) > с каких пор iptables умеет фильтровать ARP ? я им даже DHCP > клиента не мог отфильтровать, потому что этот гад открывал сырой сокет, > и клал на фильтры. Кроме iptables существуют ещё и arptables и ebtables. Вообще пытаться запретить клиенту получить адрес по DHCP странная затея в принципе. Не могу себе представить ситуацию когда бы такое требовалось. Если дело касается провайдерской раздачи интернетов, то там как правило используются туннельные решения, что в принципе исключает подобные проблемы. DHCP сам по себе, в принципе, не предназначен для таких задач, какую ты пытался решить. > Кстати ARP не должно в ядро попадать, > оно должно крутится около своего адаптера, по большому счёту ядру вообще > не нужно знать об этих пакетах Не знаю, я не программист, но Линус, похоже считает иначе. :-) > А ещё надо тысячу её собственных нюансов учитывать, про которые постоянно забываешь. У любой системы есть свои нюансы.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	43. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 04-Фев-11, 12:00
	> Я уже утерял нить беседы. ))))) Короче в Linux с помощю sysctl > можно выбирать маршрутизируемые интерфейсы. Закончим на том, что реализация arp в > Linux не нарушает RFC826(ARP) при любом раскладе, так как по любой > из записей в arp-таблице можно достучаться до IP. :-) И как показала практика, автора топика, до чужого также и далеко не без отрицательных последствий. А раз в систему заложен разрушительный механизм, который делает лишние и ненужные действия, значит логически можно предположить что это не правильно. Я опираюсь в своих суждениях на логику, а не на фанатизм. > Кроме iptables существуют ещё и arptables и ebtables. Вообще пытаться запретить клиенту > получить адрес по DHCP странная затея в принципе. Не могу себе > представить ситуацию когда бы такое требовалось. Если дело касается провайдерской раздачи > интернетов, то там как правило используются туннельные решения, что в принципе > исключает подобные проблемы. DHCP сам по себе, в принципе, не предназначен > для таких задач, какую ты пытался решить. Вы не поняли ситуацию, есть провайдер, он выдаёт по DHCP адреса, но попадались у него умники втыкавшие не тем концом роутеры в его сеть, и так же раздавали адреса. > Не знаю, я не программист, но Линус, похоже считает иначе. :-) Похоже линукс писали не боги и там попадаются неграмотные программисты, а неграмотные, потому что "багу" уже много лет, а он до сих пор не исправлен. И мне не понятно, зачем нужно предпринимать лишние действия, напрягая при этом процессор, дабы отфильтровать ненужное поведение ОС.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	44. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 04-Фев-11, 21:22
	> И как показала практика, автора топика, до чужого также и далеко не > без отрицательных последствий. А раз в систему заложен разрушительный механизм, который > делает лишние и ненужные действия, значит логически можно предположить что это > не правильно. Я опираюсь в своих суждениях на логику, а не > на фанатизм. У меня и своя практика под рукой. Не могу сэмулиовать ситуацию в которой возникал бы такой баг: > Пишу у клиента arp -a и он определят мак сервера той сетевухи, которая в инет смотрит, а не в локалку. Во как! Т.е. IP от eth0 а mac от eth2 (см. начало темы).
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	45. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 05-Фев-11, 08:28
	> У меня и своя практика под рукой. Не могу сэмулиовать ситуацию в > которой возникал бы такой баг: >> Пишу у клиента arp -a и он определят мак сервера той сетевухи, которая в инет смотрит, а не в локалку. Во как! Т.е. IP от eth0 а mac от eth2 (см. начало темы). к сожалению ни чем помочь не могу, гадалку в отпуск отправил :) другими словами, ситуация плохо описана. Да и проверять надо RPING-ом, ибо работа в среде описанной автором это лотерея. К тому же, вы не потрудились выяснить у автора какая у него версия ядра и ОС, а это имеет значение. Эксперимент должен быть чистым.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	46. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 05-Фев-11, 16:26
	Ну будь здоров. :-)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	48. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 16-Фев-11, 17:08
	вот ответ на твой вопрос, случайно наткнулся http://www.opennet.dev/base/sys/sysctl_linux.txt.html net.ipv4.conf.all.arp_filter = 0 Включает/выключает связывание IP-адреса с ARP-адресом. Если эта опция включена, то ответ будет передаваться через тот интерфейс, через который поступил запрос. В принципе, было бы не плохо, если бы ответы исходили через тот же интерфейс, через который был получен запрос, однако, в отдельных случаях, это может стать причиной ошибок. Обычно включение этой опции необходимо только в том случае, если на вашем хосте производится управление распределением нагрузки между сетевыми интерфейсами. Значение по-умолчанию  0 (выключено), поскольку эта опция идет немного вразрез с современным пониманием принципов IP-адресации. Ранее IP-адреса рассматривались как путь к некоторому устройству, в смысле аппаратуры, теперь же их следует рассматривать как отдельную службу доставки, которая должна выдавать ответы на запросы вне зависимости от того на какой интерфейс эти запросы были получены. Дополнительную информацию по данной тематике вы найдете в Guide to IP Layer Network Administration with Linux.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	32. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 03-Фев-11, 09:41
	> Вспомнил, это древний баг ARP протокола в Linux системах. > Поясню на примере, имеем > Net1-----[{MAC1,IP1}PC{MAC2,IP2}]-----Net2 > так вот, если дать ARP запрос из Net1 для IP2, то получим > ответ MAC1,IP2. > Этот баг некоторые провайдеры использовали для поиска роутеров у клиентов. Так я дал запрос из Net1 для IP1 и получил MAC2, это случаем не немного другое?;) > Как от этого избавится? > как уже говорил, писать клиентам статическую ARP таблицу, Необходимо у каэдого прописать arp -s 192.168.102.102 "соответствующий этой сетевухе мак"??? И добавить батник в автозагрузку > второй вариант, фильтровать на сетевухах не свои ARP запросы, например с помощью > ebtables http://ru.wikipedia.org/wiki/Ebtables Что-то не понял я логику этого инструмента, не пояснишь? > PS: всё таки это ARP флуд был, но генерит его твой же > сервер :) Что-то мне подсказывает, что это окажется не единственной проблемой))) > PSS: есть ещё вариант решения, оставить одну сетевуху и на неё повесить > две сети, два IP. Это не скажется на производительности сервера, скорости интернета??? Клиентов будет где-то 30, ширина канала 20 Мбит, сетевуха 100 Мбит, пользователи юзают P2P сети, то есть выжимают из канала всё.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	33. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 03-Фев-11, 11:37
	> Так я дал запрос из Net1 для IP1 и получил MAC2, это > случаем не немного другое?;) То же самое, только у тебя обе сетевухи в одну сторону смотрят и отвечают почти одновременно, от какой ответ раньше придёт, тот MAC и пользуется :) > Необходимо у каэдого прописать arp -s 192.168.102.102 "соответствующий этой сетевухе мак"??? думаю этого будет достаточно, но это через ж...у, > Что-то не понял я логику этого инструмента, не пояснишь? Нет, не пользовался этим пакетом, ищи информацию самостоятельно. > Что-то мне подсказывает, что это окажется не единственной проблемой))) с такой организацией сети, вполне может быть. > Это не скажется на производительности сервера, скорости интернета??? > Клиентов будет где-то 30, ширина канала 20 Мбит, сетевуха 100 Мбит, пользователи > юзают P2P сети, то есть выжимают из канала всё. В сети гигабитные HUB-Switch используются? нет?, тогда как это скажется на производительности?
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	35. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 03-Фев-11, 19:58
	> В сети гигабитные HUB-Switch используются? нет?, тогда как это скажется на производительности? Всякие стоят и на 100 Мбит и на 1 Гбит пара-тройка есть, свитчей вообще гора, здание - общага, тут в коридоре на каждом этаже свитча по 4 более или мение нормальных и в каждой комнате стоит такой, как жильцы купят. Сделала через 1 сетевуху, повесил на нее 2 ипа, грузится теперь вроде все полностью, но если раньше тест скорости у клиента стабильно выдавал 5-6 Мбит, то теперь выше 800 Кбит не поднимается. Не подходит получается такое решение к данной проблеме!?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от desenix (ok) on 03-Фев-11, 20:02
	> Сделала через 1 сетевуху, повесил на нее 2 ипа, грузится теперь вроде > все полностью, но если раньше тест скорости у клиента стабильно выдавал > 5-6 Мбит, то теперь выше 800 Кбит не поднимается. Не подходит > получается такое решение к данной проблеме!? не могу по этому поводу ничего сказать, т.к. не проводил исследований.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	29. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от Слоупок (ok) on 03-Фев-11, 07:04
	И так на всех клиентах?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	34. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 03-Фев-11, 19:51
	> И так на всех клиентах? Вроде на всех
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	47. "Нестабильный Интернет у клиентов"	+/–
	Сообщение от lucky89 (ok) on 07-Фев-11, 11:28
	>> И так на всех клиентах? > Вроде на всех Хотя НЕТ! У кого какой MAC из двух возможных определяется
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема