natiss

Ну во первых Вы не ответили на вопрос. Во вторых Вам же на НАГе Ядрокот правильное направление указал. Уже сделал по его совету, спасибо.

Останавливается.

Не помогло. Заметил одну вещь. На виртуалке странное значение seq # tcpdump -e -vv -n -i eth0 src net 192.168.63.0/24 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 13:20:54.386674 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38727, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.63.202.4859 > 23.48.213.231.http: ., cksum 0x5304 (correct), 550254575:550254575(0) ack 2709415249 win 64620 13:20:54.389743 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 465: (tos 0x0

tcpdump -e -n -i xenbr0 net 192.168.63.0/24 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes 13:14:46.198879 [color=#ff0000]00:16:36:54:95:10[/color] > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 468: 192.168.63.202.3974 > 72.32.240.31.81: Flags [FP.], seq 1708446664:1708447078, ack 2998041683, win 64860, length 414 ^C [root@desk-202 ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:16:36:54:95:10 inet addr:a.a.a.202 Bcast:a.a.a.203 Mask:255.255.255.252 Соответственно 202-

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE на виртуалке и -A FORWARD -s 192.168.63.0/24 -j DROP не помогли. Я так понимаю правила 1 932K 96M ACCEPT all -- tnl0 * 0.0.0.0/0 0.0.0.0/0 2 1118K 1035M ACCEPT all -- * tnl0 0.0.0.0/0 0.0.0.0/0 разрешают трафик в туннелях. В OUTPUT он уже не попадет?

Пакеты на eth0 виртуалки и xenbr0 родителя идентичны.На родителе имеем # Generated by iptables-save v1.4.8 on Fri Nov 30 20:30:14 2012 *mangle :PREROUTING ACCEPT [41307417:25821193279] :INPUT ACCEPT [5750311:2775144472] :FORWARD ACCEPT [37416615:23667414494] :OUTPUT ACCEPT [5716472:3610853180] :POSTROUTING ACCEPT [43131380:27277721391] -A OUTPUT -s 192.168.63.0/24 -j DROP -A POSTROUTING -s 192.168.63.0/24 -j DROP COMMIT # Completed on Fri Nov 30 20:30:14 2012 # Generated by iptables-save v1.4.8 on Fri Nov 30 20:30:14 2012 *nat :PREROUTING ACCEPT [1505525:95427395] :POSTROUTING

# Generated by iptables-save v1.3.5 on Fri Nov 30 16:24:15 2012 *nat :PREROUTING ACCEPT [71057:3691718] :POSTROUTING ACCEPT [2155:142498] :OUTPUT ACCEPT [2346:158542] -A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADE COMMIT # Completed on Fri Nov 30 16:24:15 2012 # Generated by iptables-save v1.3.5 on Fri Nov 30 16:24:15 2012 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [964887:839826900] :RH-Firewall-1-INPUT - [0:0] -A INPUT -s xx -p tcp -m tcp --dport 1080 -j ACCEPT -A INPUT -s yy -p tcp -m tcp --dport 1080 -j ACCEPT -A INPUT -s zz -p tcp -m tcp --dport 1080 -j ACCE

Где-то раз в несколько минут абсолютно произвольные ack пакеты на порты 80, 443 и т.д. # tcpdump -n -i xenbr0 net 192.168.63.0/24 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:19:23.429839 IP 192.168.63.202.4005 > 23.51.114.116.80: Flags [FP.], seq 1315668052:1315668457, ack 2966701975, win 64240, length 405 17:19:26.181261 IP 192.168.63.202.4005 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0 17:20:11.136148 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags

Являюсь коллегой автора первого поста, которого я процитировал в первом сообщении. Поясню своими словами: Есть сервер А с адресом а.а.а.а и сеть a.a.a.200/30 (Debian) и сервер В (FreeBSD) с адресом b.b.b.b. Между ними 4 GRE туннеля между b.b.b.b и a.a.a.200/30. В туннелях используются 4 сети с маской /30 из серого блока. На сервере В 4 виртаульных машины с адресами 192.168.63.200/30, которые надо транслировать в a.a.a.c/30. Пакеты заворачиваются в туннели посредством ipfw fwd. Работает, как часы, потому что фри. На сервере А также 4 xen машины с centos , на которых и написаны a.a

Просьба знающих помочь в достижении просветления. Есть в миру сервер. с ИП, допустим, 2.2.2.2 под дебианом на нем развернуты несколько ВПС. На ВПСах ЦентОС. И ИП, допустим, 3.3.3.1 - 3.3.3.5 На каждый ВПС лежит GRE туннель. С серыми внутренними ИП. Допустим, 172.16.1.1/30 - 172.16.17/30 На каждом ВПС построен НАТ с серых ИП в белые. т.е. 172.16.1.2 -> 3.3.3.1, 172.16.1.6 -> 3.3.3.2 и т.д. Через туннели течет трафик, НАТится на ВПСах и приносит заказчику вожделенный профит. И все было бы замечательно НО: время от времени через внешние ифейсы ВПСов вылетают пакеты с сорц ИП 1

Интересует мачта высотой примерно 18 м. Может есть ли уже готовые варианты в виде мачт для сотовой связи?

Раз пошла такая "пьянка" http://myfreebsd.ru/network/dhcdrop-i-legalnyj-dhcp-server А смена сетевух по-любому проблема. Как ни крути...

Буду признателен, если поделитесь этим откровением в паровозе он склонен к зависанию, поэтому выключать порты - игра в орлянку я бы не сказал, что В ПОЛНОМ ОБЪЕМЕ, тем более реализация веб-интерфеса... это кошмар, я такого больше нигде не видел, вланы классифицируются не по VID а по номеру на коммутаторе Я тоже так думал, пока не столкнулся с таким роутером в живую. Перегрузка - потеря 2-3 пакетов в при стандартном ping. Возможно он "мягко" перегружает сервис. Причем, собака, раздавал адреса из рабочего диапазона с неправильным шлюзом. Теоретически то так, но кто сказал, что он

Хаха. Без снмп... Ото насмешили. Он такой же управляемый, как кто-то "проффесор". Мыльница на 8 портов + сфп очъко -не более! Это недоразумение даже не показывает mac-адреса. Да хоть каждую минуту. Скрипт быстренько получил весь пул, роутер мгновенно перегрузился и 60-70% времени спокойно делает свое черное дело. Да ничего страшного, если вообще никогда не получат )) Ну подумаешь, истерика будет, делов то Смело. Но негуманно.

Вы оптимист. Какой-то сильно умный тп-линк роутер при исчерпании пула адресов быстренько перегружался... А если у вас порвался паровоз на какое-то время и все абоненты получили настройки от левого сервера? Да, dhcdrop умеет форсировать, но лучше бы он этого не умел. При использовании dhcdrop вам надо фильтровать его на сервере. Думаете указали "хорошие" маки и все хорошо?

верно TL-SL2210 - не коммутатор, там и фильтров то никаких нет

это печально

Только в предположении, что они подключены одинаковыми проводами. А на практике это не так! почему? как раз кпд онлайн-упса ниже. Если преобразователи импуьсные, то при 1 блок экономичнее 10, но не так существенно, как Вы пишете разрешите не согласиться

ну не совсем офисных... возьмите импульсный почему в 64? обоснуйте, речь идет о случае, когда 1 96 в - 2 квт и 8 по 12в - 250 вт, мне кажется в таком случае потери в меди одинаковы

А возможно включение двух одинаковых балансиров на 48в в общую цепь 96в? Что б каждый балансировал свои 4 акума. Мои зачаточные радиолюбительские познания говорят что не должно быть проблем.. Получится универсальное решение, разбаланс между блоками по 4 батареи уже маловероятен и не страшен, да и лечится легко(поменял местами пару батареек между блоками и еще годик-два можно туда не заглядывать). Все бы хорошо, но все эти недоустройства тяготеют к соединению нуля сети с минусом аккумулятора....

потом пришли настучали по шапке пригрозили расторжением договора и все . а может сразу всех, чтобы и не мучаться? Кстати , никто не сталкивал с тем, что мыльницы могут зависать так, что не пропускают dhcp, хотя dns прекрасно работает.

8 упс с аккумуляторами по 12 в лучше одного "ублюдка" на 96 в

DHCP - не для "паровозов" из мыльниц. от dhcdrop пользы не много.

Нужен еще и ipfw. Debian сильно проблематично будет.

Всё серверное, всё по феншую