Назад | Перейти на главную страницу

Проблема с многосетевым входящим подключением ubuntu

У меня есть многосетевая система (сервер 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

Вопрос

Я хотел бы просто спросить: «Что не так?», Но я не ожидаю, что в этом вопросе будет достаточно информации, чтобы это сработало.

Вместо этого я спрошу: с чего начать поиск причины проблемы? Какую информацию мне нужно получить?

Изменить: netstat -rvn output

Сразу после перезагрузки

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 сценарии маршрутизации (ну, они есть, просто не уверен, как они работают).