Отброшенный IP-трафик на многосетевом сервере
(Прежде чем вдаваться в подробности, я представляю эту проблему с Apache и SSH в качестве примера, но это не относится к TCP-трафику, это та же проблема с протоколами на основе TCP и UDP.)
У меня есть многосвязный, многосетевой сервер под управлением Ubuntu 9.04 с eth0, подключенным к вне сеть и eth1 подключены к внутри сеть. Внешняя сеть представлена «остальному миру», а внутренняя сеть содержит все рабочие станции разработчиков и рабочие серверы. Существует брандмауэр, блокирующий трафик из «остального мира» во внутреннюю сеть, но не блокирующий исходящие запросы.
$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:18:a5:62:63
inet addr:xxx.yyy.159.36 Bcast:xxx.yyy.159.47 Mask:255.255.255.240
[snip]
eth1 Link encap:Ethernet HWaddr 00:02:b3:bd:03:29
inet addr:xxx.zzz.109.65 Bcast:xxx.zzz.109.255 Mask:255.255.255.0
[snip]
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
xxx.yyy.159.32 0.0.0.0 255.255.255.240 U 0 0 0 eth0
xxx.zzz.109.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 xxx.yyy.159.33 0.0.0.0 UG 100 0 0 eth0
Apache прослушивает порт 80, sshd прослушивает порт 22:
$ netstat --tcp -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:www *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
[snip]
С моей внутренней машины разработки, xxx.zzz.109.40, я могу подключиться к внутреннему адресу, и все в порядке. Снаружи я могу подключиться к внешнему адресу, и все работает как надо.
Но для некоторых видов тестирования я хотел бы подключиться к внешнему адресу с моей машины разработки, но сервер отклоняет запрос на подключение. Я предполагаю, что он просматривает свои таблицы маршрутизации, и поскольку входящие данные поступают с адреса, который должен быть на eth1, но прибывает на eth0, он их отбрасывает, вероятно, в качестве меры безопасности.
Есть ли способ ослабить это ограничение?
Странно то, что раньше это работало в 8.04, но не работает в 8.10 или 9.04, поэтому в прошлом году ядро проводило дополнительную проверку. Чтобы соединение работало, обратный путь должен быть таким же, как и исходный путь, поэтому это означает, что сообщения с моей машины разработки, поступающие на eth0, должны будут возвращаться на eth0, чтобы быть перенаправленными обратно на мою машину.
Вот схема, NAT нигде нет.
Предполагая, что у вас нет правил iptables, которые могли бы предотвратить это, вам необходимо отключить фильтрацию обратного пути. Вы можете сделать это, используя:
# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
Вы также можете использовать конкретное имя интерфейса вместо всего, и есть также значение по умолчанию, которое повлияет на вновь созданные интерфейсы.
Из:
фильтр обратного тракта; это проверка, чтобы увидеть, будет ли для пакета, поступающего на интерфейс, пакет, отправленный на исходный адрес исходного пакета, быть отправлен на этот интерфейс; в противном случае приходящий пакет отбрасывается. это можно рассматривать как попытку обнаружения пакетов с поддельными адресами источника.
Чтобы быть анальным, я бы не назвал приведенную выше конфигурацию сети многодомной. Это просто пересылка между двумя сетями в одной AS. В наши дни многосетевой действительно означает соединение с двумя или более соседями (AS) или, по крайней мере, несколькими маршрутами к одному и тому же восходящему соседу (AS) в случае конечной сети с одним провайдером восходящего соединения.
Я предполагаю, что вы используете эту коробку в качестве своего интернет-маршрутизатора, используя iptables NAT - очевидно, если это не так, то это не поможет, иначе вам, вероятно, понадобится что-то вроде:
iptables -t nat -I POSTROUTING -s xxx.zzz.109.0/24 -d xxx.yyy.159.36 -j ACCEPT
Это позволит пропустить исходный наттинг, который вы делаете для пакетов, идущих изнутри наружу, для всего, что предназначено для внешнего IP этого сервера.
Какой шлюз по умолчанию используется на вашей машине разработки? Шлюз по умолчанию, предполагающий, что коммутатор / маршрутизатор уровня 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 FORWARD таблицы фильтров на xxx.zzz.109.65 разрешает пересылку пакетов для вашей машины разработки.
Вы не показали конфигурацию своего брандмауэра, но держу пари, что там есть правило, которое делает что-то неправильное с фильтрацией подключений к внешнему IP-адресу изнутри. Сильно испорченная конфигурация NAT также может быть виновата, но я не могу представить себе что-то настолько патологическое в результате обычной попытки настройки.
Просто чтобы прояснить один момент: только потому, что пакет приходит с одного интерфейса, адресованный на IP-адрес другого интерфейса, будет не заставить ядро отклонить этот пакет. Что бы ни случилось, это не вина ядра.
Кроме того, tcpdump трафика (как на внутреннем и внешнем интерфейсах сервера, так и на клиенте) был бы полезен для диагностики.
Уже дано много полезных идей. Я бы а) перепроверил, что это не межсетевой экран / NAT. Добавьте правило -j LOG перед вашими правилами REJECT и DROP и посмотрите, не обнаружится ли что-нибудь подозрительное. б) Запустите tcpdump на обоих интерфейсах (-i any) и найдите свои пакеты.
Кстати, что именно вы имеете в виду, говоря «сервер отклоняет запрос на соединение»? Вы видите какое-то (немедленное) сообщение об отказе или соединение просто истекает?
Это должно быть проблема с правилами вашего брандмауэра. Скорее всего, собственный внешний IP-адрес устройства смешивается со «всем внешним трафиком» и поэтому не может быть возвращен внутреннему клиенту. Попробуйте поместить исключение в правила брандмауэра для этого IP-адреса; то есть явно разрешить внешнему IP-адресу веб-сервера отправлять трафик во внутренние сети.
Для дополнительной отладки потребуется опубликовать правила брандмауэра.