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

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

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

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

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

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

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

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

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

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

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

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