Назад | Перейти на главную страницу

Веб-сайт недоступен за пределами локальной сети и случайно отключается внутри

Как и в названии. Веб-сайт недоступен из-за пределов нашей сети, и случайные компьютеры внутри здания таймаут на пару минут, а затем снова включаются.

Для компьютеров внутри здесь использование IP-адреса дает им доступ к сайту даже при истечении времени ожидания домена.

Я пытался позвонить нашему провайдеру DNS, и они сказали, что проблема где-то в сервере, а не в них. Мой ИТ-менеджер сказал мне, что проблема не в брандмауэре. И то, и другое наводит меня на мысль, что в одном из файлов конфигурации что-то не так, но у меня недостаточно опыта работы с этим материалом, чтобы безопасно поиграть, не сняв, возможно, все.

Вот некоторая информация, если вам нужно увидеть что-нибудь еще, просто спросите ..

/ и т.д. / сеть / интерфейсы:

# The primary network interface
iface eth0 inet static
        address         10.0.1.15
        netmask         255.0.0.0
        broadcast       10.255.255.255
        gateway         10.0.0.1
        network         10.0.0.0

/etc/resolv.conf:

nameserver 10.0.1.3
nameserver 8.8.8.8
nameserver 10.0.1.4
nameserver 8.8.4.4

/ etc / hosts:

127.0.0.1       localhost
127.0.1.1       TPSWEB

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.1.7 git.toolplas.com
10.0.1.15       toolplas.com

Не уверен, какая еще информация может быть полезна, и многое здесь, я не уверен, что это значит. Итак, как я уже сказал, если вам что-то еще нужно, просто дайте мне знать.

Также кое-что мне показалось странным, когда я wget -qO - icanhazip.com он возвращает IP 68.179.41.129. Но когда я сделаю nslookup new.toolplas.com он возвращается 68.179.41.131. Не уверен, связано это или нет ..

Кроме того, когда я пытаюсь подключиться по SSH из-за пределов сети, я получаю:

ssh: connect to host new.toolplas.com port 22: No route to host

РЕДАКТИРОВАТЬ: Все еще читаю, пытаюсь собрать как можно больше информации ..

nmap new.toolplas.com

Starting Nmap 5.00 ( http://nmap.org ) at 2015-05-08 13:20 EDT
Interesting ports on toolplas.com (10.0.1.15):
Not shown: 991 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
443/tcp   open  https
445/tcp   open  microsoft-ds
8010/tcp  open  xmpp
10000/tcp open  snet-sensor-mgmt

iptables -L -n:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Пожалуйста, любая помощь будет принята с благодарностью .. Спасибо

10.0.0.0/8 - это частный диапазон адресов, поэтому он никогда не будет доступен извне.

В вашем Nmap new.tooplas.com разрешается до 10.0.1.15, а в другом - 68.179.41.131. Итак, я предполагаю, что топология вашей сети следующая:

  • Ваша локальная сеть использует внутреннюю версию 10.0.0.0/8
  • Ваш шлюз по умолчанию (10.0.0.1) имеет общедоступный IP-адрес 68.179.41.129.
  • У вас есть ряд доступных общедоступных IP-адресов. Среди них 68.179.41.131 зарезервирован для вашего веб-сервера.
  • Ваш интернет-провайдер направляет весь ваш диапазон на ваш шлюз, который должен есть правило NAT для сопоставления 68.179.41.131 с 10.0.1.15
  • Вы используете разделенный DNS, так что поиск DNS изнутри разрешает частный адрес, а поиск извне разрешает общедоступный.

Если все это верно, ваши случайные таймауты можно объяснить содержимым resolv.conf, если у вас такая же конфигурация на рабочих станциях; запросы будут случайным образом попадать либо на ваши внутренние DNS-серверы, либо на серверы Google. Если правила nat на шлюзе не настроены должным образом, публичный адрес может быть недоступен извне.

Сообщение ssh no route to host может быть вызвано неправильным преобразованием имени в частный диапазон.

Короче говоря, главными подозреваемыми являются:

  • Правила NAT на шлюзе
  • Настройки DNS на ваших внутренних рабочих столах
  • Файл hosts на компьютере, который вы использовали для проверки подключения извне.