Привет всем, меня недавно попросили администрировать пару ящиков ubuntu с веб-серверами. Я разработчик по профессии, поэтому, если этот вопрос довольно нуб, пожалуйста, простите.
У нас на этой машине работает около десятка сайтов. 2 из наших сайтов должны общаться через спокойный api. К сожалению, у нас возникли проблемы с подключением друг к другу через wget. Когда мы пытаемся запустить wget вручную из командной строки с сервера, указывающего на сайт также на этом сервере, он зависает и в конечном итоге выходит из строя. Если мы сделаем то же самое извне сервера с тем же сайтом на сервере, это будет работать.
Есть ли что-то, что может мешать сайтам на одном сервере взаимодействовать друг с другом? То же самое происходит при пинге сайта с сервера.
Я предполагаю, что у вас есть такая настройка:
Интернет - устройство / маршрутизатор NAT - внутренняя сеть -> веб-сервер
Предположим, что веб-сервер имеет имя www.example.com и преобразуется во внешний IP-адрес 1.2.3.4, а DNAT устройства NAT с 1.2.3.4 по 10.4.4.4 является внутренним IP-адресом веб-сервера.
Это хорошо работает для внешних клиентов, но для внутренних клиентов требуется дополнительная настройка. Причина: предположим, что внутренний клиент (10.4.4.5) хочет получить доступ к www.example.com (1.2.3.4). Он отправляет трафик на маршрутизатор по умолчанию (допустим, это устройство NAT, хотя более вероятны сложные настройки маршрутизации). Устройство NAT преобразует IP-адрес назначения с 1.2.3.4 в 10.4.4.4 и отправляет трафик на 10.4.4.4. (На этом этапе глупый NAT может отправить (бесполезное) перенаправление ICMP, потому что трафик идет через тот же интерфейс, на котором он пришел.) 10.4.4.4 получает трафик, формулирует ответ и отправляет его обратно клиенту 10.4.4.5 . Маршрутизация / NAT не выполняется, потому что веб-сервер находится в той же подсети. 10.4.4.5 получает трафик от 10.4.4.4 и идет «WTF?» (Т.е. отправляет пакет сброса TCP), потому что он не разговаривал с 10.4.4.4. Он разговаривал с 1.2.3.4 и не знает, что 1.2.3.4 является действительно 10.4.4.4.Только устройство NAT знает это.
Для этого есть три решения.
SNAT. Когда устройство NAT получает запрос на внешний IP-адрес с NAT изнутри, оно преобразует исходный адрес в (один из) свой собственный IP-адрес, чтобы оно получило ответ от веб-сервера и могло выполнить для них DNAT.
Различие внутреннего / внешнего DNS. Настройте внутренние серверы имен для возврата 10.4.4.4 для www.example.com. (Требуется другой сервер имен для сервера внешних запросов с внешним IP-адресом.)
Поскольку клиентом в этом случае является сам веб-сервер, вы можете добавить www.example.com в качестве псевдонима для 127.0.0.1. (Легко, но не масштабируется.)
Я бы проверил / etc / hosts на предмет неправильных записей. Я бы также проверил порядок разрешения хостов и конфигурацию DNS.
Например, если ваша пробежка wget http://www.example.com/whatever и /etc/hosts содержит запись для www.example.com тогда эта команда не сработает при локальном запуске.
редактировать
/etc/hosts не содержит "маршрутов" в обычном смысле (см. netstat -nr) он содержит ассоциации между именами хостов и IP-адресами.
Вы упоминаете «внутренние IP-имена» и «внешний IP-адрес». Вы имеете в виду «внешний IP-адрес» и «внутренний IP-адрес», где внешний IP-адрес - это адрес внешнего интерфейса вашего маршрутизатора и, следовательно, тот используется пользователями Интернета для доступа к вашему производственному веб-серверу?
Если это так, вполне вероятно, что ваш веб-сервер считает, что это внешний IP-адрес вне локальной сети, перенаправляет wget трафик к вашему маршрутизатору, чей NAT и сопоставление портов не позволяют маршрутизировать этот IP-адрес со стороны локальной сети.
Если да, отредактируйте /etc/hosts и либо замените внешний ip-адрес на внутренний ip-адрес или добавить дополнительную запись test.host.local с внутренний 10.n.n.n ip-адрес и используйте это новое имя в wget http://test.host.local/whatever.