Website indisponível fora da LAN e aleatoriamente dentro

Question

Assim como o título indica. O site não pode ser acessado de fora da nossa rede e computadores aleatórios dentro do tempo limite do prédio por alguns minutos e, em seguida, ficam de volta.

Para os computadores aqui dentro, o uso do endereço IP permite que eles acessem o site mesmo quando o domínio atinge o tempo limite.

Eu tentei ligar para o nosso provedor de DNS e eles disseram que o problema está em algum lugar do servidor, não deles. Meu gerente de TI me diz que não é um problema de firewall. Esses dois me levam a acreditar que há algo em um dos arquivos de configuração que está errado, mas eu não tenho experiência suficiente com essas coisas para brincar com segurança sem possivelmente reduzir tudo.

Aqui estão algumas informações, se você precisar ver qualquer outra coisa, por favor, pergunte.

/ 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

Não tenho certeza de que outras informações podem ser úteis, e muitas das coisas aqui não tenho certeza do que isso significa. Então, como eu disse, se há mais alguma coisa que você precisa, me avise.

Além disso, algo que achei estranho, quando eu faço wget -qO - icanhazip.com ele retorna o IP 68.179.41.129 . Mas quando eu faço nslookup new.toolplas.com , ele retorna 68.179.41.131 . Não tenho certeza se isso está relacionado ou não ..

Além disso, quando tento acessar o SSH de fora da rede, obtenho:

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

EDIT: Ainda lendo, tentando reunir o máximo de informação possível.

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         

Por favor, qualquer ajuda seria realmente apreciada .. Obrigado

    

Answer 1

10.0.0.0/8 é um intervalo de endereços privados e, como tal, nunca será acessível a partir do exterior.

Em seu nmap, new.tooplas.com resolve para 10.0.1.15 e, em outro, você tem 68.179.41.131. Então, estou supondo que sua topologia de rede é a seguinte:

• Sua LAN usa 10.0.0.0/8 internamente
• Seu gateway padrão (10.0.0.1) tem um IP público 68.179.41.129
• Você tem vários IPs públicos disponíveis. Entre eles, 68.179.41.131 está reservado para o seu servidor web
• O seu ISP encaminha todo o seu alcance para o seu gateway, que deve ter uma regra NAT para mapear 68.179.41.131 a 10.0.1.15
• Você está usando o DNS dividido para que as pesquisas de DNS do interior resolvam o endereço particular e as pesquisas externas resolvam o público.

Se tudo isso estiver correto, seus tempos limite aleatórios podem ser explicados pelo conteúdo do resolv.conf , se você tiver a mesma configuração nas estações de trabalho; as consultas acertarão aleatoriamente seus servidores DNS internos ou os do Google. Se as regras nat no gateway não forem configuradas corretamente, é possível que o endereço público não esteja disponível externamente.

A mensagem ssh no route to host provavelmente é causada pelo nome incorretamente resolvido para o intervalo privado.

Em suma, os principais suspeitos são:

• As regras NAT no gateway
• As configurações de DNS em seus desktops internos
• O arquivo hosts na máquina que você usou para testar a conectividade do lado de fora