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, ttl 126, id 38728, offset 0, flags [DF], proto: TCP (6), length: 451) 192.168.63.202.4859 > 23.48.213.231.http: P 0:411(411) ack 1 win 64620 13:20:54.699416 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38731, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.63.205.4859 > 23.48.213.231.http: ., cksum 0x5169 (correct), 411:411(0) ack 1 win 64620 на Dom0 не так tcpdump -e -vv -n -i xenbr0 src net 192.168.63.192/27 tcpdump: listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:20:54.880787 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.80: Flags [.], cksum 0x5304 (correct), seq 550254575, ack 2709415249, win 64620, length 0 14:20:54.883855 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 465: (tos 0x0, ttl 126, id 38728, offset 0, flags [DF], proto TCP (6), length 451) 192.168.63.202.4859 > 23.48.213.231.80: Flags [P.], cksum 0x7a2e (correct), seq 0:411, ack 1, win 64620, length 411 14:20:55.193537 00:16:36:54:95:10 > 10:bf:48:d7:f2:9e, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 126, id 38731, offset 0, flags [DF], proto TCP (6), length 40) Что может означать xx:xx(0) ?? "Протекают только такие пакеты.

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-я. Та же, что и натит. Судя по матчасти http://www.iptables.info/files/tables_traverse.jpg NAT POSTROUTING последнее звено. И оно похоже "течет". Неужели никак нельзя убить пакеты за ним?

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 ACCEPT [1419554:76879859] :OUTPUT ACCEPT [280073:17401880] 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 *filter :INPUT ACCEPT [7891458:3528521678] :FORWARD ACCEPT [32535726:20871476018] :OUTPUT ACCEPT [5812310:3084155959] -A FORWARD -i tnl0 -j ACCEPT -A FORWARD -o tnl0 -j ACCEPT -A FORWARD -m physdev --physdev-in vif34.0 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out vif33.0 -j ACCEPT -A FORWARD -m physdev --physdev-in vif33.0 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out vif32.0 -j ACCEPT -A FORWARD -m physdev --physdev-in vif32.0 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -m physdev --physdev-out vif31.0 -j ACCEPT -A FORWARD -m physdev --physdev-in vif31.0 -j ACCEPT -A OUTPUT -s a.a.a.a/32 -o xenbr0 -j ACCEPT -A OUTPUT -o xenbr0 -j DROP -A OUTPUT -s 192.168.63.0/24 -j DROP -A OUTPUT ! -s a.a.a.a/32 -o xenbr0 -j DROP -A OUTPUT -o peth0 -j DROP Может нужно запретить сеть 192.168.63.192/24 в FORWARD ?

# 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 ACCEPT -A INPUT -s vv -p tcp -m tcp --dport 1080 -j ACCEPT -A INPUT -p tcp -m tcp --dport 1081 -j ACCEPT -A INPUT -s ww/255.255.255.240 -p tcp -m tcp --dport 1080 -j ACCEPT -A INPUT -j RH-Firewall-1-INPUT -A INPUT -p tcp -m tcp --dport 25 -j DROP -A FORWARD -i tnl0 -j ACCEPT -A FORWARD -o tnl0 -j ACCEPT -A FORWARD -j RH-Firewall-1-INPUT -A OUTPUT -s ! a.a.a.202 -o eth0 -j DROP -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p esp -j ACCEPT -A RH-Firewall-1-INPUT -p ah -j ACCEPT -A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 5666 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 11 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8001 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited eth0 Link encap:Ethernet HWaddr 00:16:36:54:95:0D inet addr:a.a.a.202 Bcast:a.a.a.252 Mask:255.255.255.252 inet6 addr: fe80::216:36ff:fe54:950d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2030204 errors:0 dropped:0 overruns:0 frame:0 TX packets:1746029 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1030260120 (982.5 MiB) TX bytes:945832959 (902.0 MiB) gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 TX bytes:0 (0.0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4951 errors:0 dropped:0 overruns:0 frame:0 TX packets:4951 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:876499 (855.9 KiB) TX bytes:876499 (855.9 KiB) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 TX bytes:0 (0.0 tnl0 Link encap:UNSPEC HWaddr 05-09-FF-CA-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.63.41 P-t-P:192.168.63.41 Mask:255.255.255.252 UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1 RX packets:778862 errors:0 dropped:0 overruns:0 frame:0 TX packets:882169 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:79568736 (75.8 MiB) TX bytes:812249913 (774.6 MiB) Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface a.a.a.a 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 192.168.63.40 0.0.0.0 255.255.255.252 U 0 0 0 tnl0 a.a.a.200 0.0.0.0 255.255.255.252 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tnl0 0.0.0.0 a.a.a.a 0.0.0.0 UG 0 0 0 eth0

Где-то раз в несколько минут абсолютно произвольные 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 [.], ack 2974144532, win 64240, length 0 17:20:11.137992 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [P.], seq 0:394, ack 1, win 64240, length 394 17:20:12.101210 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0 17:20:14.118151 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [F.], seq 394, ack 1, win 64240, length 0 17:20:14.205524 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0 17:20:14.215003 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0 17:20:16.612219 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [FP.], seq 0:394, ack 1, win 64240, length 394 17:20:18.440447 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0 17:20:28.685567 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [FP.], seq 0:394, ack 1, win 64240, length 394 17:20:29.766795 IP 192.168.63.201.3107 > 23.51.114.116.80: Flags [.], ack 1, win 64240, length 0 ^C 12 packets captured

Являюсь коллегой автора первого поста, которого я процитировал в первом сообщении. Поясню своими словами: Есть сервер А с адресом а.а.а.а и сеть 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.a.c/30. В машинах поднят snat и настроено дропание пакетов. Есть дропание и на родительском хосте. Тем не менее на коммутатор ДЦ просачиваются пакеты от серых адресов виртуальных машин, за что сервер был уже блокирован. tcpdump иногда показывает пакеты с сорцом из диапазона 192.168.63.200/30, хотя доступ в интернет виртуалки на фри имеют. Я, честно, линукс не люблю и в iptables ничего не понимаю, на фрибсд такой проблемы бы не возникло никогда. Но тут нужен именно линукс, и мой коллега, настраивающий его, попал в тупик. Огромная просьба помочь.

Просьба знающих помочь в достижении просветления. Есть в миру сервер. с ИП, допустим, 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 и т.д. Через туннели течет трафик, НАТится на ВПСах и приносит заказчику вожделенный профит. И все было бы замечательно НО: время от времени через внешние ифейсы ВПСов вылетают пакеты с сорц ИП 172.16.1.2 и т.п. Вылетают редко, но ДЦ ругается. И грозит плёткой. Что сделано: на Dom0 запрещен с внешнего ифейса (который 2.2.2.2) исходящий трафик с ИП отличным от 2.2.2.2 iptables -A OUTPUT -o xenbr0 -s ! 2.2.2.2 -j DROP не помогло. на ВПСах запрещен исходящий с внешних ифейсов траф с ИП отличных от их собственных iptables -A OUTPUT -o eth0 -s ! 3.3.3.1 -j DROP Количество вылетающих "левых" пакетов уменьшилось, но не стало нулевым. ДЦ продолжает ругаться. Вопросы стандартны: "Кто виноват?" и "Что делать?" а если точнее, то: 1) Как этот трафик умудряется просочиться через NAT и DROP? 2) Как ему СОВСЕМ запретить это делать? Я, откровенно говоря впервые сталкиваюсь с таким эффектом и немного в растерянности.

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

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

Буду признателен, если поделитесь этим откровением в паровозе он склонен к зависанию, поэтому выключать порты - игра в орлянку я бы не сказал, что В ПОЛНОМ ОБЪЕМЕ, тем более реализация веб-интерфеса... это кошмар, я такого больше нигде не видел, вланы классифицируются не по VID а по номеру на коммутаторе Я тоже так думал, пока не столкнулся с таким роутером в живую. Перегрузка - потеря 2-3 пакетов в при стандартном ping. Возможно он "мягко" перегружает сервис. Причем, собака, раздавал адреса из рабочего диапазона с неправильным шлюзом. Теоретически то так, но кто сказал, что он является рабочим шлюзом абонента? Просто подключен к сеточке.... Это теория. А практика "паровоза" такова, что "задние вагоны" скорее получат адрес от такого роутера чем от "тягача". Да никак. Продолжать использовать dhcdrop, но быть осторожнее в плане понимания его, как панацея. Но и выдавливать из абонента его MAC-адрес, или заставлять его настраивать TCP/IP вручную не гуманно. Согласны? Помоему с точки зрения клиента гораздо меньше "головняка", если нет никаких привязок. Понятно, что в идеале это Fiber Directly To Ass, VLAN per user и option 69 , но в паровозе всё печальнее...

Хаха. Без снмп... Ото насмешили. Он такой же управляемый, как кто-то "проффесор". Мыльница на 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 сильно проблематично будет.

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