Вопросы Теги

Отброшенный трафик IP с многосетевым сервером

Для использования больше чем 2 ГБ RAM на машине SQL Server, у Вас есть две опции:

i. Восстановите сервер с O/S на 64 бита и SQL Server на 64 бита.

ii. Используйте AWE и настройте сервер для начальной загрузки с / переключателем 3G. Чтобы сделать это, Вам также нужна версия для предприятий SQL Server. Это позволит Вам использовать до 8 ГБ RAM на 2k3 Enterpise и возможно больше на 2k3 Центр обработки данных.

4
задан 15 January 2019 в 17:32
7 ответов

Принятие Вас не имеет никаких правил iptables, которые предотвратили бы это, необходимо отключить фильтрацию обратного канала. Можно сделать это использование:

# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Можно также использовать конкретное имя интерфейса вместо всех и существует также значение по умолчанию, которое влияло бы на недавно созданные интерфейсы.

От:

инвертируйте фильтр пути; это - проверка, чтобы видеть, был ли, для пакета, прибывающего в интерфейс, пакет, отправленный в исходный адрес исходного пакета, бы отослан в том интерфейсе; в противном случае приходящий пакет отбрасывается. это можно считать попыткой обнаружения пакетов с имитировавшими исходными адресами.

3
ответ дан 3 December 2019 в 03:53
  • 1
    Учитывая, что исходный адрес isn' t быть имитировавшимся, rp_filter isn' t собирающийся помогать немного. –  womble♦ 4 July 2009 в 05:01
  • 2
    Пакет будет получен во внешнем интерфейсе, но исходящий пакет будет направлен из внутреннего интерфейса. Это, кажется, соответствует описанию rp_filter довольно точно. –  David Pashley 4 July 2009 в 05:09
  • 3
    @David: Если машины разработки будут подключены к единой сети, и их шлюз является рассматриваемой машиной, то пакет прибудет из внутреннего интерфейса. –  derobert 4 July 2009 в 06:52
  • 4
    @David: Как пакет будет получен во внешнем интерфейсе? –  womble♦ 4 July 2009 в 11:03
  • 5
    Я don' t понимают downvotes. Это, кажется, самое вероятное объяснение. –  bortzmeyer 5 July 2009 в 23:58

Вы не показали свою конфигурацию брандмауэра, но я буду держать пари, что существует правило там, это делает что-то неблагоприятное с фильтрацией соединений с внешним IP-адресом изнутри. Плохо завинченный конфигурация NAT могла также быть виновным, но я испытываю затруднения при обеспечении чего-то, таким образом, патологического следующий из обычной попытки конфигурации.

Просто для уточнения одна точка, также: просто, потому что пакет прибывает из одного интерфейса, адресованного IP-адресу другого интерфейса, не заставит ядро отклонять тот пакет. Независимо от того, что происходит, это не отказ ядра.

Кроме того, tcpdump трафика (и во внутренних и внешних интерфейсах сервера, и на клиенте) был бы с помощью диагностики полезен.

0
ответ дан 3 December 2019 в 03:53
  • 1
    Я подтвердил с Wireshark, что запросы с внутренней части делают его через брандмауэр к внешнему интерфейсу, но с сервера нет никакого ответа. I' ll выполненный tcpdump на сервере в интерфейсе eth0, но I' m довольно уверенный they' ll обнаруживаются там также. –  Joel 4 July 2009 в 05:18
  • 2
    Вы видели пакеты на внешний интерфейс? Это shouldn' t происходят. Я чувствую запах безумия NAT. –  womble♦ 4 July 2009 в 06:23
  • 3
    Нет, никакой NAT, надо надеяться, схема сделает это более ясным. –  Joel 8 July 2009 в 07:06

Что такое шлюз по умолчанию для Вашей машины разработки? Шлюз по умолчанию, принимающий Коммутатор уровня 3/, Маршрутизатор должен знать, как достигнуть другого интерфейса сервера.

У Вас должно быть что-то как 

ip route xxx.yyy.159.36 netmask 255.255.255.240 gw xxx.zzz.109.65

Это должно заставить вещи работать. Но в случае, если это не достаточно, затем включите передачу IP на машине xxx.zzz.109.65 использование

sysctl net.ipv4.ip_forward = 1

Также отредактируйте/etc/sysctl.conf и включите IP, передающий там также.

Удостоверьтесь iptables ВПЕРЕД, цепочка таблицы фильтра на xxx.zzz.109.65 позволяет пакетную передачу для Вашей машины разработки.

0
ответ дан 3 December 2019 в 03:53
  • 1
    Как ответ, отправленный Метелкой, it' s довольно ясный I' ve получил некоторые передающие правила/шаблоны/поведение заняться расследованиями. –  Joel 8 July 2009 в 07:10

Я предполагаю, что Вы используете то поле в качестве своего интернет-маршрутизатора NAT с помощью iptables NAT - очевидно, если это не так затем это не поможет, иначе Вам, вероятно, будет нужно что-то как:

iptables -t nat -I POSTROUTING -s xxx.zzz.109.0/24 -d xxx.yyy.159.36 -j ACCEPT

Это пропустит исходную сетку, которую Вы делаете для пакетов, перемещающихся изнутри во внешнюю сторону для чего-либо предназначенного для внешнего IP того сервера.

0
ответ дан 3 December 2019 в 03:53
  • 1
    Никакой NAT, но мой iptables опыт NAT не согласуется в период в конце этого предложения. –  Joel 8 July 2009 в 07:08

Только, чтобы быть анальным я не назвал бы вышеупомянутую конфигурацию сети многосетевой. Это просто передает между двумя сетями в том же AS. Многосетевой в эти дни действительно средства, подключенные к двум или больше соседям (AS) или по крайней мере нескольким маршрутам тому же восходящему соседу (AS), в случае листовой сети с единственным восходящим поставщиком возможности соединения.

0
ответ дан 3 December 2019 в 03:53
  • 1
    Мне нравится думать это I' m сторонник использования корректной терминологии, мог Вы комментировать со ссылкой на какой ' AS' относится к в этом контексте? Я отредактировал вопрос добавить схему, если это помогает разъяснить что-нибудь. –  Joel 8 July 2009 в 07:13
  • 2
    AS == автономная система. –  Jason Tan 17 July 2009 в 14:11

Много полезных идей уже дано. Я a) Перепроверил бы, это не брандмауэр/NAT. Добавьте правило ЖУРНАЛА-j перед своим ОТКЛОНЕНИЕМ и ОТБРОСЬТЕ правила и посмотрите, поймано ли что-либо подозрительное. b) Выполнил бы tcpdump в обоих интерфейсах (-i любой) и искал бы Ваши пакеты.

BTW, что точно Вы подразумеваете "под сервером, отказывается от запроса на установление соединения"? Вы видите, что некоторый (непосредственный) отказ обменивается сообщениями, или убирает соединение только время?

0
ответ дан 3 December 2019 в 03:53
  • 1
    Нет никакого ответа с сервера, it' s, как будто запрос никогда не прибывал. Клиент в конечном счете испытывает таймаут..., и tcpdump был моим другом в течение долгого времени :-). –  Joel 8 July 2009 в 07:16

Это должно быть проблемой с Вашими правилами брандмауэра. Скорее всего, собственный внешний IP поля становится смешанным в с 'всем внешним трафиком' и так не позволяется назад до внутреннего клиента. Попытайтесь поместить исключение в правила брандмауэра для того IP-адреса; то есть, явно позвольте внешнему IP-адресу веб-сервера отправлять трафик во внутренние сети.

Больше отладки потребует, чтобы Вы отправили свои правила брандмауэра.

0
ответ дан 3 December 2019 в 03:53
  • 1
    Как оказалось, это не была проблема с брандмауэром, но спасибо. –  Joel 8 July 2009 в 07:23

Теги

Похожие вопросы