Cenário: 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 para o servidor OpenVPN (Windows), ambos usando psexec e smb.
O que aconteceu: tudo correu bem por anos, até que o administrador do sistema atualizou a estação de trabalho para o Windows 10 Pro. Ele confiou no consultor de atualização do Windows e acabou de desinstalar o antivírus antigo que estava marcado como incompatível. Após a atualização, ele - de boa fé - fez os seguintes testes:
-verifique o serviço openvpn no cliente -> runningnning
-ping 10.8.0.1 (ip do servidor) -> OK
Então ele obviamente achava que estava tudo bem.
Como esta estação de trabalho é usada pelo funcionário à noite, na manhã seguinte, fui envolvido pelo administrador de sistema interno, pois o funcionário não conseguiu enviar atualizações. Ele disse que nenhum dos serviços enviou resposta pela vpn, apenas o icmp estava funcionando. Em primeiro lugar, fiz um telnet para as portas que esperava serem alcançáveis e descobri que a conexão instantânea foi recusada. Fiz um ping e encontrei um valor de TTL na resposta de 250!?!? 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 olhei para isso era inacreditável, mas 0,4 é o GW padrão interno deles, 22,41 é um de seus roteadores e esse roteador está conectado apenas ao ISP.
Correção para o problema do Openvpn: rapidamente descobri que, em relação à atualização do Win10 e ao cliente openvpn, era apenas uma questão de confusão de rotas, e os logs do openvpn confirmaram isso, e a solução (atualização para o último openvpn) corrigiu. Ainda consigo pingar 10.8.0.1 de qualquer outro computador em sua rede que não esteja executando OpenVPN , se a política de roteamento trouxer a conexão neste uplink 22.41. Se eu encaminhar 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, 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 do 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, ele pode mencionar algum documento como RFC informando que o ISP violou alguma regra de serviço para fornecer serviços de internet?
O espaço de endereço privado RFC1918 PODE ser usado pelo ISP, normalmente seria transparente para o cliente, parece que eles têm um firewall/ACL mal configurado, pois esses endereços não devem ser visíveis para o cliente.
Entre em contato com a operadora, seja um contato do NOC no Net-Whois ou pelo Atendimento ao cliente. Não tenho conhecimento de nenhuma ação legal que possa ser tomada.
A RFC 6598 (100.64.0.0/10) foi esculpida como um espaço CGN/NAT444 a ser utilizado pelos ISP's na transição para o espaço IPv6. Cada ISP faz sua própria coisa, padrões não são leis.
Se nada mais, você pode configurar o firewall do cliente para liberar espaço ISP privado não utilizado para a WAN, o que pode exigir um melhor roteador/firewall ou software de terceiros (DDRWRT).