Итак, у меня есть новая установка Fedora Core 28, которую мы пытались вывести в онлайн. Установка прошла отлично, насколько мы могли сказать. Он имеет две сетевые карты, одну для внутренней сети, одну с фиксированным IP-адресом. Это сервер, поэтому его основной задачей является запуск веб-сервера httpd . И он должен быть доступен не с консоли, а для запуска sshd .
На первый взгляд, все в порядке. Первым сетевым использованием было использование yum для установки многих пакетов, проблем не было. Мы добавили gnome чтобы получить графический интерфейс, добавили firefox чтобы получить веб-браузер, а затем использовали его, чтобы получить данные для устранения неполадок. Соединения на внутренней сети в порядке. Соединение с SSH не является проблемой, и по крайней мере одна учетная запись была настроена для использования ключей шифрования, чтобы избежать пароля. Подключение к новому веб-серверу также выглядит нормально, используя как внутренние, так и внешние IP-адреса. Итак, мы почувствовали, что убедились, что ssh и веб-сервер настроены правильно. ...Изначально мы не знали, что что-то не так.
Когда мы добрались до соединения с внешним миром, это когда вещи "пошли в сторону". Попытки соединиться с SSH просто потерпели неудачу, и соединения с веб-сервером также, казалось, потерпели неудачу.
Первая попытка была с брандмауэром. Как это настроено? Это iptables или firewalld? Как мы можем гарантировать, что мы можем пройти снаружи? Мы обнаружили, что каким-то образом настроили исключение в /etc/firewalld/zones zone - зона по умолчанию "FedoraServer.xml" в нашем случае - как httpd , и мы заметили при перезагрузке, что он пожаловался на это, и изменили его на http , с которой мы больше не заметили ни одной жалобы. Все еще нет радости.
Тогда есть nmap ! Это сканер портов для систем Linux для просмотра открытых портов любой сетевой цели. Это, казалось, показывало, что мы не были заблокированы брандмауэром. Мы подтвердили, что iptables не использовался и был firewalld , поэтому мы отключили его и до сих пор не радуются.
Тогда мы рассмотрели старое оборудование. Порты Ethernet для витой пары являются двунаправленными устройствами, поэтому возможно ли, что входящий сигнал на внешнем порту был хорошим, а исходящий - плохим? ИЛИ, может быть, на коммутаторе был плохой порт? Итак, мы попытались поменять их, внутренние и внешние. Без изменений.
Затем мы посчитали, что МОЖЕТ маршрутизатор фильтровать, хотя и не должен. Новая коробка была заменой старой, которая вышла на пенсию, а старая была полностью функциональной, но кто знает? Может роутер сошел с ума? Итак, мы пошли, чтобы войти в него и посмотреть. Но, к сожалению, никто не смог найти пароль роутера.
Вместо этого, поскольку маршрутизатор знает системы только по их внешним IP-адресам, мы отключили полнофункциональную систему, и новая система получила IP-адрес отключенной системы. Это исключает маршрутизатор как потенциальную причину, по крайней мере, мы так думали. Однако проблемы не исчезли.
Было высказано предположение, что, возможно, виноват маршрутизатор, так как, возможно, он захватывал MAC-адреса, и поэтому, чтобы исключить эту возможность, мы перезагрузили его. Опять без улучшений.
Затем я получил возможность попросить нашего внешнего тестера увеличить детализацию диагностических данных ssh-соединения, добавив, все чаще, -v к командной строке (вы можете сделать до трех), и нашему внутреннему sys-admin, чтобы проверить Логи Apache. И это было очень полезно. Мы обнаружили, что внешнее восприятие было связано с тем, что ssh добирается до нашего демона sshd , но соединения сбрасываются, а также в журналах веб-сервера отображаются правильные входящие соединения только из тех мест, которые мы ожидали, и в результате записывается "200", что означает httpd думал, что веб-клиенты получают свои страницы. Но это не было правдой.
Ок, теперь что?