Por que os IPs do Espaço de Endereçamento Privado podem ser acessados pela rede pública e o que os clientes podem fazer a respeito?

1

Cenário: Eu tenho um cliente executando um Win7 Pro e um cliente OpenVPN; esta estação de trabalho é usada por um de seus funcionários para enviar cmds remotos ao servidor OpenVPN (Windows), ambos usando psexec e smb.

O que aconteceu: Tudo correu bem por anos, até que o seu administrador de sistema atualizou a estação de trabalho para o Windows 10 Pro. Ele confiava no orientador de atualização do Windows e desinstalava o antivírus antigo que era marcado como incompatível. Após a atualização, ele - de boa fé - fez os seguintes testes:

-Verifique o serviço openvpn no cliente - > runnning

-ping 10.8.0.1 (ip do servidor) - > OK

Então ele obviamente achou que estava tudo bem.

Como esta estação de trabalho é usada pelo funcionário à noite, na manhã seguinte eu estava envolvido com o administrador de sistema interno, pois o funcionário não conseguia enviar atualizações. Ele disse que nenhum dos serviços enviou resposta através da vpn, apenas icmp estava funcionando. Em primeiro lugar, eu fiz algumas telnet para as portas que eu esperava estar acessível e descobri que eu tenho conexão instantânea recusada. Eu fiz um ping e encontrei um valor TTL na resposta de 250!?!? Eu fiz o seguinte tracert:

C:\>tracert -w 100 10.8.0.1

Traccia instradamento verso 10.8.0.1 su un massimo di 30 punti di passaggio

  1     3 ms     2 ms     2 ms  192.168.0.4
  2     1 ms     2 ms     2 ms  192.168.22.41
  3     1 ms     3 ms     1 ms  10.139.59.130
  4     5 ms     3 ms     3 ms  10.3.132.113
  5    15 ms    13 ms    15 ms  10.254.12.202
  6    15 ms    15 ms    15 ms  10.254.1.245
  7    27 ms    25 ms    23 ms  10.8.0.1

A primeira vez que eu olhei isso foi inacreditável, mas 0,4 é o padrão GW interno, 22,41 é um dos roteadores e este roteador é conectado somente ao ISP.

Correção para o problema do Openvpn: Eu rapidamente percebi que em relação à atualização do Win10 e do cliente openvpn era apenas uma questão de rotas de bagunça, e os logs do openvpn confirmaram isso, e a solução (atualizar para o openvpn mais recente) o corrigiu. Eu ainda posso pingar 10.8.0.1 a partir de qualquer outro computador em sua rede não executando o OpenVPN , se o roteamento de políticas trouxer a conexão neste uplink de 22.41. Se eu direcionar a conexão para qualquer outro de seus 4 (tot. 5) uplinks, o problema não acontece. Como este "dizer pirata" 10.8.0.1 responde em todas as portas com rejeições instantâneas e tudo está fechado eu acho que pode ser um roteador. Eu só estou querendo saber se o ISP está violando o RFC 1918 ou então como é possível que eu possa pingar um ip de o espaço de endereços privados na rede pública!?

--- Editar 2

Pergunta: Como o Cliente sente que esse comportamento inesperado prejudicou seus negócios, eles podem mencionar algum documento como o RFC declarando que o ISP violou alguma regra de serviço para fornecer serviços de Internet?

    
por Marco 23.06.2017 / 19:22

1 resposta

3

RFC1918 O espaço de endereço privado PODE ser usado pelo provedor, normalmente seria transparente para o cliente, parece que ele tem um firewall / ACL configurado incorretamente, pois esses endereços não devem ficar visíveis para o cliente.

Entre em contato com a operadora, seja NOC Contact da Net-Whois ou através do Suporte ao Cliente. Não tenho conhecimento de nenhuma ação legal que possa ser tomada.

O RFC 6598 (100.64.0.0/10) foi criado como um espaço CGN / NAT444 a ser usado pelos ISPs em transição para o espaço IPv6. Cada ISP faz o que é próprio, os padrões não são Leis.

Se nada mais, você pode configurar seu firewall de cliente para descartar espaço ISP privado não utilizado para a WAN, o que pode exigir um roteador / firewall melhor ou software de terceiros (DDRWRT).

    
por 26.06.2017 / 17:30