Веб-сайт недоступный outsideLAN и случайным образом испытывает таймаут внутри

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

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

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

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

/etc/network/interfaces:

# 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         

Любая справка действительно ценилась бы..Спасибо

1
задан 8 May 2015 в 20:23
1 ответ

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 на ваших внутренних рабочих столах
  • Хост-файл на машине, которую вы использовали для тестирования подключение извне
1
ответ дан 4 December 2019 в 00:08

Теги

Похожие вопросы