01. OBJETIVO
Realização de testes relacionados a validação da comunicação Site-to-Site entre Servidor de PDV e os PDVs.
02. COMUNICAÇÃO
É importante deixar claro, dividir e direcionar as questões relacionadas a comunicação em VPN em duas frentes:
VPN TOTVS - CLIENTE
É aquela prevista no projeto e documentação, configurada entre o IP Peer da TOTVS e IP Peer único do cliente nos equipamentos (firewall/roteador) desse único ponto centralizado.
Essa VPN é configurada a partir dos dados gerados pela automação TOTVS, que tem como base nos dados de IP Peer + Rede fornecidos previamente pelo cliente.
Uma vez configurado esse ponto centralizado de comunicação, a partir dele o cliente deverá criar as regras necessárias para as demais lojas em sua VPN Interna.
Mais informações: VPN | Procedimentos de Ativação
Não é necessário fechar VPN com a TOTVS em cada uma das lojas, apenas no equipamento centralizador do cliente, as demais lojas só precisam se comunicar com o Servidor de PDV nas portas previstas na documentação.
VPN CLIENTE - LOJAS
É aquela configurada pelo cliente a partir do ponto central validado na etapa anterior (VPN TOTVS - Cliente) para as demais lojas, é a responsável direta pela comunicação entre o Monitor de PDV (que é o gerenciador de todas as operações/movimentações relacionadas ao PDV) e cada PDV de cada loja.
03. TESTES
Os testes de comunicação devem ser realizados sempre nos dois sentidos, ou seja do Monitor de PDV para o PDV e por sua vez, no sentido contrário, do PDV para o Monitor de PDV, pois só assim é possível verificar e identificar de maneira assertiva, bloqueios, restrições ou falhas de comunicação na origem correta.
É importante considerar que, especificamente em caso de PDV Windows o mesmo continua sujeito a necessidade de verificação/liberação das restrições de GPO e Firewall (local).
Principais testes sugeridos:
PING
TELNET
TCPING*
NETSTAT
PATHPING
MTR
WinMTR
ZENMAP (nMap)*
WIRESHARK*
TCPing, ZenMap e WireShark não vem por padrão instalados no S.O. ou distribuições, mas são utilitários de simples instalação.
Exemplos práticos :
1.PING (Windows e Linux)
É o primeiro teste que deve ser realizado pois com ele é possível validar a comunicação e também o limite do pacote de dados MTU que pode trafegar de forma estável na VPN.
Executar no Prompt (Windows) ou Terminal (Linux)
PING SIMPLES
Serve exclusivamente para conferir se o outro equipamento está ativo/responde, não mede ou valida tamanho ou limite de pacotes na comunicação.
PING NUMEROIPDESTINO -tLinha de comandoPing 192.168.13.208 -t
PING COM TAMANHO DE PACOTE PARA TESTE DE MTU
É o teste ideal e recomendado para verificação e correção de falhas relacionadas ao envio de Cargas e Configurações a partir do AcruxMonitor para o PDV, pois envia pacotes de tamanho personalizado.
Sugerimos e indicamos fortemente a realização do teste de PING que segue abaixo logo na instalação do 1º PDV do Cliente para o devido ajuste (se necessário) no Servidor de PDV
PING NUMEROIPDESTINO -l 1410 -tLinha de comandoPing 192.168.13.208 -l 1410 -t
O valor 1410 utilizado no exemplo acima é especifico para aquele ambiente, ele foi obtido após a verificação do valor de MTU estável, segue abaixo como identificar.
Como identificar o MTU estável ?
O valor padrão de interfaces de rede em geral é 1500, porém, em se tratando de VPN é preciso lembrar-se de que há o encapsulamento, portanto, os dados em si irão trafegar abaixo desse valor.Quando forem verificadas mensagens de "Falha" no envio de Cargas e Configurações a partir do AcruxMonitor para o PDV isso já é um bom indício e elemento para a realização do teste de MTU, para tanto, utilize a linha de comando de PING com pacote e vá diminuindo os valores (1500, 1490, 1480, 1470...etc..) até que passe a haver retorno de comunicação (ao invés de "timed out") como ocorreu na imagem abaixo com 1410.
No exemplo que segue, em um teste realizado a partir do Servidor de PDV foi possível verificar que não havia retorno do PING até que o valor de MTU fosse reduzido abaixo de 1411, até esse ponto era exibido "Timed out", porém, assim que utilizado o valor de MTU=1410 é possível conferir na imagem que o PING for normalizado, esse ajuste é necessário quando utilizada VPN, pois só assim a comunicação irá ocorrer da forma esperada entre Servidor de PDV x PDV.
Recomendações:
O ideal é que o MTU seja ajustado diretamente no Servidor de PDV uma única vez, isso dispensará quaisquer ajustes complementares nos PDVs, pois as conexões irão passar a considerar sempre o MTU do Servidor de PDV, porém, em casos pontuais, se houver necessidade (Ex. instalar um PDV de testes/validações) é perfeitamente possível realizar o ajuste temporário (provisório) diretamente no PDV, sem necessidade de aplicar no Servidor de PDV.
Uma outra forma de validar se eventuais falhas no envio de cargas e configurações (do Servidor de PDV para o PDV) podem ser em virtude de erro de MTU é realizar um teste de NETSTAT na porta 8011 via Terminal Linux do PDV de Validações para conferir se o mesmo está acumulando conexões naquela porta de comunicações com o Servidor de PDV.O teste complementar de NETSTAT só é efetivo o PDV já estiver ligado há algum tempo e com a aplicação do AcruxPDV em execução, porque só nesse cenário as portas 8011 e 7011 estão sendo utilizadas.
MTU: COMO VERIFICAR O VALOR ATUAL ?
PDV LINUX - VERIFICAR MTU
No Terminal Linux do PDV
# ifconfig eth0
Será exibido o resultado abaixo:
eth0 Link encap:Ethernet HWaddr 00:0c:29:ac:b2:8e
inet addr:172.23.134.101 Bcast:172.23.134.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feac:b28e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6164356 errors:0 dropped:0 overruns:0 frame:0
TX packets:96179 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:515490533 (491.6 MiB) TX bytes:22206002 (21.1 MiB)Na linha 5 você pode ver MTU:1500
O exemplo acima é uma forma simples e rápida de verificar/confirmar o valor atual de MTU na interface de rede do PDV;
WINDOWS - VERIFICAR VALOR MTU e NOME DA INTERFACE
No prompt de comando digitar:
netsh interface ipv4 show subinterfaces
No exemplo acima (Windows) é exibido que o tamanho MTU naquele momento para a Interface de rede é 1500
MTU: COMO ALTERAR O VALOR ATUAL ?
ALTERAÇÃO TEMPORÁRIA NO PDV LINUX (PARA TESTES E VALIDAÇÕES PONTUAIS)
A alteração temporária de valor de MTU funciona até que o PDV seja reiniciado (voltará ao valor padrão 1500 automaticamente), mas já permite que sejam realizados testes de envio de Carga e Configuração para verificar se a eventual falha de comunicação está ou não relacionada a questão de MTU.
Após esse processo, verificado o valor ideal, deverá ser realizado o ajuste permanente.
É importante conferir questões que podem estar relacionadas a MTU já no 1º PDV de testes instalado.
Para realizar a alteração manual (temporária) do MTU para um valor específico, utilize o comando abaixo no Terminal do Linux, nesse exemplo específicos utilizaremos o valor de MTU como 1410 (não é padrão para todos os clientes, analise sempre primeiro).
No Terminal Linux do PDV
# ifconfig eth0 mtu 1410
O resultado de saída do comando acima será parecido com o conteúdo abaixo:
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0c:29:ac:b2:8e
inet addr:172.23.134.101 Bcast:172.23.134.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feac:b28e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1410 Metric:1
RX packets:6168787 errors:0 dropped:0 overruns:0 frame:0
TX packets:96489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:515839287 (491.9 MiB) TX bytes:22249757 (21.2 MiB)
A partir desse momento, basta fechar e abrir a aplicação do PDV (para liberar eventuais conexões pendentes) e realizar novos testes de estabilidade e funcionamento (envio de cargas e configurações a partir do AcruxMonitor)
Reforçando: a configuração via linha de comando acima será perdida após reiniciar o PDV, é indicada apenas para validação quando identificada alguma falha no envio de cargas e configurações a partir do AcruxMonitor, se confirmado deve ser realizado o ajuste permanente diretamente no Servidor de PDV.
ALTERAÇÃO PERMANENTE DO MTU
Após a análise, verificada a necessidade de ajuste permanente de MTU, embora seja possível ajustar permanentemente naquele naquele PDV (interface ETH0 por exemplo) o ideal é solicitar o ajuste no Servidor de PDV, pois isso dispensa a alteração PDV por PDV
WINDOWS
ALTERAÇÃO PERMANENTE DE MTU
Essa ação no Servidor de PDV só está disponível a usuários com permissão e acesso direto ao mesmo.
Via prompt de comando
1. Abra o prompt de comando como administrador
2.Para conferir o valor atual do MTU e anotar a Interface execute primeiro o seguinte comando:
netsh interface ipv4 show interface
O resultado do comando acima será uma janela como a que segue abaixo:
Agora com os dados necessários (exemplo de valor de MTU = 1500 e nome da Interface = "Ethernet0") siga para a etapa 3
3.Ajustar de forma permanente o valor do MTU (mantém após reboot), no exemplo abaixo utilizaremos o valor de MTU=1410, pode variar conforme cliente.
netsh interface ipv4 set subinterface “Ethernet0” mtu=1410 store=persistent
Para conferir se o ajuste foi aplicado, execute novamente o comando da Etapa 2 para exibir os valores de MTU:
Ajuste aplicado com sucesso (MTU=1410)
Esse ajuste deve ser realizado no Servidor de PDV Cloud, pois dispensa a necessidade de ajuste PDV por PDV.
2.TELNET (Windows e Linux)
A finalidade é validar se as portas principais (7011 e 8011) estão se comunicando.
Do Monitor de PDV para o PDV
Estando no prompt do Windows, digitar Telnet IP_do_PDV 8011
Exemplo
TELNET 192.168.2.10 8011
Do PDV para o Monitor de PDV
Estando no terminal, digitar Telnet IP_do_Monitor_de_PDV 7011
Exemplo
TELNET 10.0.1.6 7011
Em ambos os casos, seja do Servidor para o PDV ou do PDV para o Servidor, a confirmação da comunicação deverá exibir sempre a mensagem de "Conectado" como na imagem de exemplo abaixo
Caso o teste de Telnet informe que a porta não está acessível, verifique a mensagem exibida:
- Mensagem simples de "Porta não Acessível"
Dica 1: Verifique se não existem Objetos Inválidos no Banco de Dados (quando existentes o Listener das portas do Serviço do AcruxMonitor é desativado)
Dica 2: Verifique as regras de liberação previstas na documentação padrão (portas 7011, 8011, etc...)
Dica 3: O teste do Servidor para o PDV depende da aplicação do AcruxPDV estar em execução (pois é o Listener da porta 8011 do Telnet no PDV) Mensagem de "Excesso de conexões ou Limite de Conexões excedido"
Dica: Esse é um forte indício de divergência no tamanho máximo do pacote de MTU (faça novamente os testes de PING com Pacote como no exemplo 2 do Item 1) e siga e realize os procedimentos de Ajuste de MTU.Observação: A existência de Objetos Inválidos no Banco de Dados inativa o Serviço do Monitor e deixa parados os Listeners de portas, como 8011 e 7011, nesse cenário o PING funciona, mas o Telnet não. Verifique sempre a existência de Objetos Inválidos usando a opção "ALL USERS" no PL/SQL para conferir todos os Owners oficiais.
- Mensagem simples de "Porta não Acessível"
3.TCPING (Windows)
É praticamente a união dos comandos PING e TELNET em apenas um, é um utilitário extremamente simples e funcional, pode exibir informações sobre PING, JITTER e já direcionar para a Porta desejada (se não for informada a porta o TCPing por padrão utiliza a porta 80), não vem por padrão instalado no Windows (presente nos Servidores Cloud), mas é possível ser instalado.
Download: TCPing (x32 e x64)
Exemplos de uso:
TCPING -d -t -j IP_DESTINO
TCPING -d -t -j IP_DESTINO PORTA (indicado)
Exemplo de validação de PING + PORTA 8011 de um PDV que NÃO ESTÁ se comunicando corretamente:
Exemplo
TCPING -d -t -j 192.168.100.200 8011
Exemplo de outra validação já com comunicação funcional ou normalizada após os ajustes necessários (liberações de portas e regras)
Exemplo
TCPING -d -t -j 192.168.100.101 8011
Legenda dos parâmetros:
- -d (exibir data)
- -t (teste contínuo)
- -j (jitter)
- -c (change state, só exibe uma nova linha se houver alteração de estado da conexão
4.NETSTAT (Windows e Linux)
Valida a quantidade de conexões ativas, indicado para execução no terminal do PDV.
Linux
Estando no terminal do Linux do PDV:
Verificar conexões existentes na porta 8011:
Exemplo
netstat -an | grep 8011
Verificar apenas o total de conexões ativas existentes filtrando pela porta 8011
Exemplo
netstat -ant | grep ESTABILISHED | grep 8011 | wcl -l
Caso queira gravar a saída de resultados em um arquivo Log/TXT basta adicionar ao final da linhas acima o complemento: >arquivo.log
O NETSTAT em conjunto com o teste de MTU via PING é uma excelente forma complementar de validar conexões acumuladas na porta 8011, pois inviabilizam o envio de Configurações e Cargas para PDV) e confirmam a necessidade de alteração de MTU
5.PATHPING (Windows)
É uma combinação de PING com TRACERT, permite que você confira as rotas/pontos a partir do Host de origem até IP de destino informado, podendo evidenciar problemas de comunicação como link e operadora.
Exemplo
Pathtping 192.168.0.201
6.MTR (Linux)
É o equivalente em LINUX do PATHPING, deve ser executado no Terminal do Linux, a grande vantagem é que ele fica em execução constante automática, verificando a velocidade, perdas de pacote, etc... (até que seja finalizado).
Como fica em execução (loop) é possivel usar atalhos para "D" Display mode, "R" Restart statistics, etc...
Forma de uso: mtr -o "LSD A MX" IP_Destino
Exemplo
mtr -o "LSD A MX" 192.168.0.201
Dicas de Parâmetros
- Use -x ou -xml para gerar xml
- Use -C para exportar os dados em arquivo csv
- Use -j para saida no padrão json
Lista de parâmetros adicionais para usar com a opção "-o"
É possível informar vários parâmetros adicionais de acordo com a necessidade de monitoramento, segue tabela:
Flag | Descrição |
L | Loss ratio |
D | Dropped packets |
R | Received packets |
S | Sent packets |
N | Newest RTT(ms) |
B | Min/Best RTT(ms) |
A | Average RTT(ms) |
W | Max/Worst RTT(ms) |
V | Standard Deviation |
G | Geometric Mean |
J | Current Jitter |
M | Jitter Mean/Avg. |
X | Worst Jitter |
I | Interarrival Jitter |
7.WinMTR (Windows)
Versão do MTR para Windows, permite testar a rota e exibe detalhes sobre a comunicação e salvar o log em TXT ou HTML.
É possivel ainda (Options) alterar o tamanho do pacote de dados para o ping, etc...
Download: https://winmtr.net/
8.ZENMAP (Windows, no Linux é NMAP)
Solução extremamente completa e que não exige necessáriamente conhecimentos avançados, substitui e centraliza a maioria das ferramentas e comandos citados anteriormente em uma unica aplicação.
É possivel realizar testes de ping, telnet, portas, tracerout, serviços em execução com poucos cliques e ainda salvar o log diretamente em arquivos.
Verificação de Portas do Go-Global:
Download: https://nmap.org/download
No linux é possivel utiliza-lo via linha de comando no Terminal (NMAP) digitando exatamente a mesma linha que a interface ZENMAP exibe em "Command"
9.WIRESHARK (Windows e Linux)
Software que possui versões Windows e Linux (vem embarcado em algumas distribuições Linux do AcruxPDV) e permite filtros e um detalhamento ainda mais avançado que todos os anteriores, é possivel até mesmo conferir a inconsistência do tamanho de um pacote MTU.
Linux (AcruxPDV)
Procure pela aplicação Wireshark (use F3 para alternar aplicação do AcruxPDV caso queira mantê-la ativa e busque em aplicativos).
Exemplo: no Filtro digite o IP do Servidor de PDV, no caso do exemplo ip.src==10.0.1.6
Podem haver algumas variações na interface interface inicial de acordo com a versão utilizada e ou embarcada, mas a forma de uso é sempre a mesma, informar o filtro desejado a as interfaces que deseja monitorar
OUTROS IMPACTOS RELACIONADOS A DIVERGÊNCIA DE MTU E MSS CLAMPING
01. Pacotes de atualização não sendo baixados no PDV.
Ajustar o MTU - TCP MSS Clamping no tráfego entre a rede local e a VPN e vice-versa, este ajuste varia de firewall para firewall, basta seguir as informações sobre testes de MTU nos itens anteriores.
Para maiores informações sobre conceitos acerca de MSS e MTU: https://www.cloudflare.com/pt-br/learning/network-layer/what-is-mss/
ACESSOS
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas