Новая установка Linux, не может заставить работать соединения ssh или http, соединения сделаны, но обрываться?

Итак, у меня есть новая установка Fedora Core 28, которую мы пытались подключить к сети. Установка прошла отлично, насколько мы могли сказать. Он имеет две сетевые карты, одну для внутренней сети, одну с фиксированным IP-адресом. Это сервер, поэтому его основной задачей является запуск веб-сервера, httpd, И он должен быть доступен из консоли, кроме того, чтобы он работал sshd,

На первый взгляд, все в порядке. Первым сетевым использованием было использование yum для установки многих пакетов, проблем не было. Мы добавили gnome чтобы получить графический интерфейс, добавил firefox чтобы получить веб-браузер, а затем использовал это, чтобы помочь получить данные для устранения неполадок. Соединения на внутренней сети в порядке. Соединяясь с SSH это не проблема, и по крайней мере одна учетная запись была настроена для использования ключей шифрования, чтобы избежать пароля. Подключение к новому веб-серверу также выглядит нормально, используя как внутренние, так и внешние IP-адреса. Итак, мы чувствовали, что подтвердили ssh и веб-сервер были настроены правильно.... Изначально мы не знали, что что-то не так.

Когда мы добрались до связи с внешним миром, это когда вещи "пошли в сторону". Попытки связаться с SSH просто провалился сразу, и соединения с веб-сервером также, казалось, потерпели неудачу также.

Первая попытка была с брандмауэром. Как это настроено? Это iptables или же firewalld? Как мы можем гарантировать, что мы можем пройти снаружи? Мы обнаружили, что каким-то образом мы настроили исключение в /etc/firewalld/zones - зона по умолчанию "FedoraServer.xml" в нашем случае - как httpdи мы заметили при перезагрузке, что он пожаловался на это и изменил его на http, с которым мы больше не заметили никаких жалоб. Все еще нет радости.

Тогда есть nmap! Это сканер портов для систем Linux для просмотра открытых портов любой сетевой цели. Это, казалось, показало, что мы не были заблокированы брандмауэром. Мы подтвердили iptables не использовался и был firewalldтак мы его выключили и до сих пор не радости.

Тогда мы рассмотрели старое оборудование. Порты Ethernet для витой пары являются двунаправленными устройствами, поэтому возможно ли, что входящий сигнал на внешнем порту был хорошим, а исходящий - плохим? ИЛИ, может быть, на коммутаторе был плохой порт? Итак, мы попытались поменять их местами, внутренними и внешними. Без изменений.

Затем мы посчитали, что МОЖЕТ маршрутизатор фильтровать, хотя и не должен. Новая коробка была заменой старой, которая вышла на пенсию, а старая была полностью функциональной, но кто знает? Может роутер сошел с ума? Итак, мы пошли, чтобы войти в него и посмотреть. Но, к сожалению, никто не смог найти пароль роутера.

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

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

Затем я получил возможность попросить нашего внешнего тестировщика увеличить детализацию диагностических данных ssh-соединения, добавив, все чаще, -v к командной строке (вы можете сделать до трех), и нашему внутреннему sys-admin, чтобы проверить Логи Apache. И это было очень полезно. Мы обнаружили, что внешнее восприятие было ssh добирался до нашего sshd демон, но соединения были разорваны, а также в журналах веб-сервера были показаны правильные входящие соединения только из тех мест, которые мы ожидали, и в результате было записано "200", что означает httpd думал, что веб-клиенты получают свои страницы. Но это не было правдой.

ОК, и что теперь?