У меня есть Ubuntu Server 14.04 с Apache, который находится за корпоративным брандмауэром. Это работало нормально в течение последнего месяца, но теперь сервер не отвечает на запросы, поступающие из-за пределов локальной сети (переадресация портов выполняется межсетевым экраном). Моя первоначальная мысль заключалась в том, что что-то в apache пошло не так, но когда я пытаюсь получить доступ к серверу, используя внутренний адрес (192.168.8.10), все работает нормально. Когда я пытаюсь установить telnet из локальной сети:
$ telnet 192.168.8.10 80
Trying 192.168.8.10...
Connected to 192.168.8.10.
Escape character is '^]'.
Netstat на сервере дает мне следующий вывод:
$netstat -n -c | grep "192.168.8.19:80"
tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
и когда я приезжаю http://192.168.8.10 в браузере netstat производит:
$netstat -n -c | grep "192.168.8.19:80"
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2
tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2
Теперь, когда я пытаюсь сделать это из-за пределов локальной сети, telnet не подключается и браузер просто отключается.
$ telnet 78.xx.xx.245 80
Trying 78.xx.xx.245...
Это просто зависает на неопределенный срок, но netstat все еще признает SYN_RECV пакеты.
$ netstat -n -c | grep "192.168.8.19:80"
tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV
tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV
tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV
tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV
Тест браузера не дает никаких результатов в netstat.
Это привело меня к мысли, что проблема связана с переадресацией портов на брандмауэре. Однако, когда я попытался перенаправить порт 80 на сервер Windows, он работал абсолютно нормально. Когда я изменил порт 80 для перенаправления обратно на сервер Ubuntu, возникла та же проблема. Тот факт, что тест telnet действительно достигает сервера через брандмауэр, указывает мне, что проблема не в брандмауэре.
Мой ИТ-отдел сообщил мне, что за последние несколько дней в конфигурацию брандмауэра не вносилось никаких изменений и что я не вносил никаких изменений в сервер. Фактически, попытка перенаправить порт 80 на другой Настольный компьютер Ubuntu с запущенным apache дал те же результаты (зависший браузер и telnet не подключались, несмотря на вывод netstat).
Другие порты успешно перенаправляются на сервер Windows за брандмауэром (и 80 работали при перенаправлении на сервер Windows), поэтому я не думаю, что проблема связана с провайдером. Похоже, это проблема исключительно Ubuntu.
Есть ли у кого-нибудь идеи относительно того, что это может быть, поскольку сейчас это большая проблема для нас?
Когда хост может связываться с локальной сетью, но не за ее пределами, наиболее вероятной ошибкой конфигурации, которую нужно искать, является неправильный IP-адрес шлюза.
Если хост с неправильно настроенным шлюзом является сервером TCP-соединения, то симптомы будут заключаться в том, что пакеты SYN принимаются и принимаются, но пакеты SYN-ACK не могут быть доставлены из-за отсутствия правильного адреса шлюза. Это соответствует симптомам, описанным в вашем вопросе.
Плохой обходной путь - преобразование IP-адреса источника входящих подключений в шлюз через NAT, что, по-видимому, и сделал ваш ИТ-отдел. Это не очень хорошая идея, потому что вы теряете IP-адрес клиента в своих файлах журнала, и это потенциально вводит дополнительное отслеживание соединения. Однако может показаться, что это работает нормально, поскольку сервер больше не отправляет пакеты на IP-адрес клиента, а скорее на IP-адрес шлюза, который, поскольку он находится в напрямую подключенном сегменте сети, не зависит от неправильно настроенного шлюза по умолчанию.
Правильное решение в этом случае - настроить правильный IP-адрес шлюза на сервере и отменить обходной путь, который был применен к брандмауэру.
Если ваш сервер Ubuntu настроен со статическим IP-адресом, и IP-адрес, и адрес шлюза находятся в /etc/network/interfaces. Изменение этого файла вступит в силу при следующей перезагрузке.
это был проблема конфигурации межсетевого экрана. Видимо, правило межсетевого экрана было включить NAT для работы переадресации портов. ИТ-отдел заверил меня, что это было не был включен ранее (хотя он работал раньше), и это кажется проблемой только в том случае, если порты перенаправляются на сервер Linux (т.е. серверы Windows не требуют включения NAT в соответствующих правилах брандмауэра для успешной работы перенаправления портов) .
РЕДАКТИРОВАТЬ Это была пластыря на проблеме. Как заметил касперд, проблема заключалась в настройке шлюза на сервере.
Попробуйте sudo ufw disable
Также проверьте конфигурацию Apache в файле conf. /etc/apache2/apache2.conf
Например: - / var / www
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted </Directory>