После перезапуска net.eth1 коробка Gentoo не может взломать или пропинговать

Следующее полностью сбивает с толку меня. В настоящее время у нас есть gentoo box, который действует как наш сервер LAMP, DNS, DHCP. Это назначенный статический IP в сети. Этот сервер подключен напрямую к Интернету через BT BusinessHub Router. Сервер также подключен к коммутационной панели / порту коммутатора, который соединяет оставшийся офис (около 10 компьютеров) с сервером.

Все было гладко до того дня, когда сервер был перезапущен. По какой-то причине теперь доступны только части доступа к сети, в зависимости от того, какое устройство Ethernet было в последний раз перезапущено. Перезапуск net.eth0 позволяет офисному серверу выполнять CURL, пинг и т. Д., Но не позволяет всем сетевым компьютерам получать доступ к Интернету. Затем перезапуск net.eth1 восстанавливает весь интернет в сети, но останавливает сервер от керлинга, пинга и т. Д. Снова.

Тем не менее, даже когда сервер не может пропинговать, свернуть и т. Д., Я все еще могу подключиться к удаленному SSH и MySQL из командной строки сервера к другим нашим внешним серверам.

Вот моя карта маршрутов (маршрутизатор 192.168.1.254):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth1

Вот мой /etc/conf.d/net:

iface_eth0="192.168.1.99 broadcast 192.168.1.255 netmask 255.255.255.0"
iface_eth1="dhcp"

Ничто из вышеперечисленного никогда не менялось. Все просто перестало работать правильно, что заставляет меня думать, что это недавно добавленное правило Iptables. Вот таблица фильтра Iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  ##.##.##.##          anywhere            tcp dpt:ssh
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:2199
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3199
ACCEPT     tcp  --  ##.###.###.##        anywhere            tcp dpt:http
ACCEPT     tcp  --  ###.###.##.##        anywhere            tcp dpt:2199
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.##.##         anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:3128
ACCEPT     udp  --  ##.###.###.###       anywhere            udp dpt:3128
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:https
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             ##.###.###.##
DROP       all  --  anywhere             ##.###.###.##
ACCEPT     all  --  anywhere             anywhere            state NEW,ESTABLISHED
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp spt:2199
ACCEPT     udp  --  anywhere             anywhere            udp spt:4817
ACCEPT     udp  --  anywhere             anywhere            udp spt:4819
ACCEPT     udp  --  anywhere             anywhere            udp spt:3199

Помощь с благодарностью приветствуется.

2 ответа

Понимаете ли вы, что у вас есть eth0 и eth1, эффективно настроенные для одной подсети?

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

iface_eth0="192.168.1.99 broadcast 192.168.1.255 netmask 255.255.255.0"
iface_eth1="dhcp"

Измените подсеть на вашем маршрутизаторе на 192.168.0.0/24 или другую подсеть, кроме 192.168.1.0/24, перезапустите eth1, и это должно исправить это. Если два интерфейса действительно не находятся в одной сети - а их нет - их не следует настраивать для одной подсети.

Кроме того, весь трафик проходит через ваш сервер, чтобы добраться до маршрутизатора?

Если это так, я рекомендую просто включить мостовые соединения на вашем маршрутизаторе, чтобы дать вашему серверу публичный IP-адрес. Смотрите: http://business.forums.bt.com/t5/Broadband-and-internet/How-to-set-up-bridge-mode-on-the-BT-business-hub/td-p/4902 - - это позволит полностью избежать проблемы, хотя, поскольку я не знаком с вашим маршрутизатором, вы можете избежать этого; они называют это мостовым соединением, похоже, что это может быть проход, где он все еще выполняет аутентификацию (BT выполняет аутентификацию PPPoE/PPPoA?), но передает информацию DHCP через.

Установка двух подсетей NAT является пустой тратой, если вы не используете / нуждаетесь.

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

Попробуйте добавить это в ваш /etc/sysctl.conf

Добавьте / Раскомментируйте следующие строки:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

Если у вас динамический интернет-адрес, вы, вероятно, захотите включить это:

net.ipv4.ip_dynaddr = 1

Это должно решить вашу проблему

Другие вопросы по тегам