У меня есть многосетевая система (сервер Ubuntu, 11.04), где eth0 - это lan, а eth1 - wan. Есть подключение к Интернету через оба, но через разные маршруты.
Когда система загружается, я не могу подключиться, например. apache (TCP 443) на интерфейсе WAN, несмотря на то, что он прослушивает * .443.
Однако если я отключу eth0, то смогу. После резервного копирования eth0 я все еще могу получить доступ к apache.
Нет активных правил IPTables (Политика: принять).
Система и ядро
Ununtu Server 11.04
$ uname -r
Linux myserver 2.6.38-11-server #50-Ubuntu SMP Mon Sep 12 21:34:27 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Сетевые интерфейсы:
eth0 is lan, dhcp assigned.
eth1 is wan, static ip.
IPTables
No rules set.
Policy is ACCEPT
Исходящее соединение eth1 работает.
Я протестировал исходящее соединение на eth1 с помощью nmap, и это работает:
$ nmap -sT -P0 -p80 -eeth1 google.com)
port is open.
Тест из WAN там доступа не показывает.
# nmap -sS -P0 -p443 myhost
states the port is filtered
Проверка из локальной сети прошла успешно с использованием Chrome.
Apache правильно слушает:
$ sudo lsof -i :443
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
apache2 822 root 4u IPv4 7965 0t0 TCP *:https (LISTEN)
apache2 857 www-data 4u IPv4 7965 0t0 TCP *:https (LISTEN)
apache2 858 www-data 4u IPv4 7965 0t0 TCP *:https (LISTEN)
Следующее разрешит входящие соединения:
# ifconfig eth0 down
# ifconfig eth0 up
Содержимое / etc / network / interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address xx.yy.zz.ww
netmask 255.255.255.128
gateway xx.yy.zz.1
nameserver 8.8.8.8
Я хотел бы просто спросить: «Что не так?», Но я не ожидаю, что в этом вопросе будет достаточно информации, чтобы это сработало.
Вместо этого я спрошу: с чего начать поиск причины проблемы? Какую информацию мне нужно получить?
Сразу после перезагрузки
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
xx.yy.zz.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
10.10.53.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.10.53.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 xx.yy.zz.1 0.0.0.0 UG 0 0 0 eth1
eth0 вниз
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
xx.yy.zz.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
0.0.0.0 xx.yy.zz.1 0.0.0.0 UG 0 0 0 eth1
eth0 резервное копирование
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
xx.yy.zz.0 0.0.0.0 255.255.255.128 U 0 0 0 eth1
10.10.53.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 xx.yy.zz.1 0.0.0.0 UG 0 0 0 eth1
Исходя из этого, я бы предположил, что ваш маршрут по умолчанию из eth0 имеет приоритет. Маршрутизация заботится только о наилучшем способе отправки данного пакета, она не заботится об общем потоке данных. Клиент попытается подключиться к вашему серверу на xx.yy.zz.1 через eth0, но ответ будет перенаправлен из eth1 10.10.53.1. Даже если ответный пакет успешно достигает места назначения, он будет иметь неправильный IP-адрес в качестве источника, и клиент не будет знать, что с ним делать. Вы сможете проверить, так ли это, просто запустив захват пакетов на своих интерфейсах, когда вы делаете запросы к серверу.
Проверять, выписываться это руководство о том, как маршрутизировать пакеты обратно из интерфейса, на который они прибыли
Добавьте строку, определяющую адрес WAN в httpd.conf (sub в вашем IP-адресе WAN для 1.2.3.4).
Listen 1.2.3.4:80
Не уверен, есть ли способ привязать процесс к определенному порту. Если бы это был RHEL, я бы смог помочь немного больше, не уверен, есть ли в debian сценарии маршрутизации (ну, они есть, просто не уверен, как они работают).