Jump to content

sire

Пользователи
  • Posts

    20
  • Joined

  • Last visited

About sire

  • Rank
    Абитуриент
    Абитуриент

Контакты

  • ICQ
    Array
  1. Если я правильно понимаю Ваш вопрос, то я уже писал "На сервере tcpdump показывает зеркалируемый трафик и на eth1, и на br0. Но счётчик iptables для правила -j NETFLOW равен нулю, и ipt_netflow не видит трафик с зеркалируемого порта."
  2. Да, пробовал и с включенным, и с отключенным :(
  3. У меня не работает хак с бриджем и дамми интерфейсом. Есть сервер, подключенный к порту коммутатора, на котором настроен порт мирроринг. Зеркалируется входящий и исходящий трафик с одного порта на порт, к которому подключен сервер. На сервере tcpdump показывает зеркалируемый трафик и на eth1, и на br0. Но счётчик iptables для правила -j NETFLOW равен нулю, и ipt_netflow не видит трафик с зеркалируемого порта. На сервере стоит клон RHEL 6.1 с ядром 2.6.32-131.0.15.el6.x86_64, iptables 1.4.7, ipt_netflow 1.8. Настраивал по этой доке. Есть какие-нибудь идеи?
  4. Проблему удалось решить пересборкой ядра Debian Etch без параметра CONFIG_IP_ROUTE_MULTIPATH_CACHED=y. Теперь всё работает как надо. Зачем они вообще его включили? Столько времени из-за него потерял!
  5. FreeBSD на том же сервере с той же нагрузкой очень тормозит. Загрузка проца под 100%. К тому же, говорю, что на других линуксах балансировка нагрузки пашет. Это проблема Debian Etch.
  6. К стати, та же конфигурация прекрасно работает на ALT Linux Master 2.4 с ядром 2.4.26 и на ASP Linux с ядром 2.6.18.1.
  7. Как оказалось, это глюк Debian Etch. Немало народу задаёт этот же вопрос в Инете, в основном на английском. Буду искать решение. Возможно пересборка ядра или iproute.
  8. >Ещё я обратил внимание на странные маршруты в кэше: ip route show cache #(фрагмент) 85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P1 dev IF_P1[/b] src [b]IP_P2[/b] cache mtu 1500 advmss 1460 hoplimit 64 iif IF_INT 85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P2 dev IF_P2[/b] src [b]IP_P2[/b] cache mtu 1500 advmss 1460 hoplimit 64 iif eth3 "Странные" маршруты победил добавлением в таблицу main тех маршрутов во внутреннюю сеть, которые были прописаны в таблицах prov1 и prov2 (несколько маршрутов через внутренние шлюзы via 10.253.253.154 dev IF_INT). Обнаружил новую "странность" ip route show cache |grep 'src IP_P2' выдаёт записи вида 10.1.150.100 from 38.99.76.89 via 10.253.253.154 dev IF_INT src IP_P2 В то время как ip route show cache |grep 'src IP_P1' выдаёт записи вида local IP_P1 from 74.12.206.112 dev lo src IP_P1 Обнаружил ещё одну "странность". Это нормально, что в кэше содержатся маршруты для одних и тех же точек через разные шлюзы? Ещё и по несколько раз одно и то же. 83.9.82.101 from 10.1.149.152 via GW_P1 dev IF_P1 src 10.253.253.104 cache mtu 1500 advmss 1460 hoplimit 64 iif IF_INT 83.9.82.101 from 10.1.149.152 via GW_P1 dev IF_P1 src 10.253.253.104 cache mtu 1500 advmss 1460 hoplimit 64 iif IF_INT 83.9.82.101 from 10.1.149.152 via GW_P2 dev IF_P2 src 10.253.253.104 cache mtu 1500 advmss 1460 hoplimit 64 iif IF_INT
  9. Есть два подключения к двум разным провайдерам (P1 и P2). Стоит задача разделить трафик между провайдерами в отношении 80% к 20%. На маршрутизаторе - Linux Debian Etch. Ядро 2.6.18. Прочитал LARTC, кучу разных примеров, настроил. В итоге - весь трафик идёт через того провайдера, маршрут к шлюзу которого прописан последним. То есть если ip route говорит default equalize nexthop via GW_P2 dev IF_P2 weight 20 nexthop via GW_P1 dev IF_P1 weight 80 , то весь трафик идёт через провайдера P1. Стоит поменять записи nexthop местами, как весть трафик постепенно перетекает на провайдера P2. Что интересно, команда ip route show cache|grep GW_P1 |wc -l; ip route show cache|grep GW_P2 |wc -l выдаёт количество маршрутов в кэше для GW_P1 =~ 2.2 * GW_P2, то есть маршрутов через GW_P1 примерно в 2 раза больше, чем через GW_P2. Хотя в соответствии с указанными весами маршрутов отношение должно быть 4 к 1. Привожу свою конфигурацию ip route NET_P1/29 dev IF_P1 proto kernel scope link src IP_P1 NET_P2/29 dev IF_P2 proto kernel scope link src IP_P2 10.253.253.0/24 dev IF_INT proto kernel scope link src 10.253.253.104 # внутренняя сеть default equalize nexthop via GW_P2 dev IF_P2 weight 20 nexthop via GW_P1 dev IF_P1 weight 80 ip route show table prov1 несколько маршрутов через внутренние шлюзы via 10.253.253.154 dev IF_INT default via GW_P1 dev IF_P1 ip route show table prov2 несколько маршрутов через внутренние шлюзы via 10.253.253.154 dev IF_INT default via GW_P2 dev IF_P2 iptables-save *mangle -A PREROUTING -j CONNMARK --restore-mark -A POSTROUTING -o IF_P1 -m state --state NEW -j MARK --set-mark 0x1 -A POSTROUTING -o IF_P2 -m state --state NEW -j MARK --set-mark 0x2 -A POSTROUTING -m state --state NEW -j CONNMARK --save-mark COMMIT *nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source IP_P1 -A POSTROUTING -m mark --mark 0x2 -j SNAT --to-source IP_P2 COMMIT *filter -A FORWARD -j ACCEPT COMMIT Ещё я обратил внимание на странные маршруты в кэше: ip route show cache #(фрагмент) 85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P1 dev IF_P1[/b] src [b]IP_P2[/b] cache mtu 1500 advmss 1460 hoplimit 64 iif IF_INT 85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P2 dev IF_P2[/b] src [b]IP_P2[/b] cache mtu 1500 advmss 1460 hoplimit 64 iif eth3 10.1.146.111 from 203.131.198.76 via 10.253.253.154 dev IF_INT src IP_P2 cache mtu 1500 advmss 1460 hoplimit 64 iif IF_P1 10.1.150.36 from 194.67.57.206 via 10.253.253.154 dev IF_INT src IP_P1 cache mtu 1500 advmss 1460 hoplimit 64 iif IF_P1 212.143.210.244 from IP_P1 via GW_P1 dev IF_P1 cache mtu 1500 advmss 1460 hoplimit 64 local IP_P1 from 125.2.30.104 dev lo src IP_P1 cache <local> iif IF_P1 10.1.151.238 from 64.207.161.110 via 10.253.253.154 dev IF_INT src IP_P2 cache mtu 1500 advmss 1460 hoplimit 64 iif IF_P1 Подскажите, пожалуйста, что попроавить. Заранее очень благодарен.
  10. Хорошо, как обычно поступают провайдеры? Если можно, приведите примеры. В Линукс можно делать так: 1. iptables -A FORWARD -j LOG --log-prefix "[FORWARD] " 2. iptables -A FORWARD -m state --state NEW -j LOG --log-prefix "[FORWARD] " 3. iptables -t nat -A POSTROUTING -s ! $IP_EXT/$MASK_EXT -o $IF_EXT -j LOG --log-prefix [NAT] Какой вариант будет достаточным для внутренних органов? :-)
  11. Из постановления:14. Базы данных должны содержать следующую информацию об абонентах оператора связи: фамилия, имя, отчество, место жительства и реквизиты основного документа, удостоверяющего личность, представленные при личном предъявлении абонентом указанного документа, - для абонента-гражданина; наименование (фирменное наименование) юридического лица, его место нахождения, а также список лиц, использующих оконечное оборудование юридического лица, заверенный уполномоченным представителем юридического лица, в котором указаны их фамилии, имена, отчества, места жительства и реквизиты основного документа, удостоверяющего личность, - для абонента - юридического лица; сведения баз данных о расчетах за оказанные услуги связи, в том числе о соединениях, трафике и платежах абонентов. Здесь не указано какую конкретно информацию о соединениях и трафике абонентов надо хранить. Дело в том, что при нескольких тысячах абоенентов сети в секунду набегает порядка 7000 строк файла протокола доступа. Это если протоколировать заголовки каждого пакета в текстовом виде. Например: Если протоколировать только первые пакеты соединений, то размер файла протокола будет существенно меньше.
  12. Обязаны ли российские провайдеры Интернет хранить протоколы доступа пользователей в Сеть? Как долго? Насколько детальными должны быть протоколы, то есть, например, только адреса, порты и время начала соединения, или заголовки всех пакетов?
  13. Согласен, я ошибся, спасибо. Проблем с ФТП нет, проверял, писал об этом выше. Поэтому проблему с ICQ считаю "странной", необычной.