...
Realização de testes relacionados a validação da comunicação Site-to-Site necessária entre Servidor de PDV e os PDVs e o Monitor de PDV.
É importante deixar claro, dividir e dividir direcionar as questões relacionadas a comunicação em VPN em duas situações distintasfrentes:
É aquela prevista no projeto e documentação, realizada configurada entre o IP Peer da TOTVS e IP Peer ( único ) do cliente, definidos e validados, a partir da sua configuração, o cliente deverá realizar e validar a configuração desse ponto principal para as demais lojas da rede do mesmodo 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
Nota |
---|
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. |
É aquela configurada pelo cliente a partir do ponto principal central validado na etapa anterior (VPN TOTV 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.
...
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 é possivel possível verificar e identificar de maneira assertiva, bloqueios, restrições ou falhas de comunicação na origem correta.
...
Principais testes sugeridos:
Informações |
---|
Os comandos de 1 a 5 estão presentes e funcionais nativamente nos respectivos ambientes (Linux e ou Windows), já as sugestões dos itens 6 e 7 (TCPing e Wireshark) os mesmos podem demandar instalação complementar por não virem instalados/embarcados em todas as distribuições. |
Nota |
---|
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. |
...
É 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)
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 -t
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
Ping 192.168.13.208 - |
t |
Aviso |
---|
Falha no envio de configurações e cargas são indícios de divergência em tamanho de pacotes MTU e impactam diretamente na comunicação do Servidor de PDV com os PDVs (o Default de MTU em vários equipamentos é 1500), portanto, indicamos fortemente esse teste básico de limite do tamanho do pacote logo na instalação do 1º PDV e caso necessário, sejam realizados os ajustes no pacote daquele PDV na interface ETH0 para validação e replicação (o exemplo acima é de 1410, mas pode ser acima disso em algumas redes). |
# 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: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
Nota |
---|
O exemplo acima é uma forma simples e rápida de confirmar o MTU atual/default na interface de rede do PDV; |
No prompt de comando:
netsh interface ipv4 show subinterfaces
Nota |
---|
No exemplo acima (Windows) é exibido que o tamanho MTU naquele momento para a Interface de rede é 1500 |
# ifconfig eth0 mtu 1410
O resultado de saída do comento será parecido com o conteúdo abaixo:# ifconfig eth0
|
É 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.
Nota |
---|
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 -t
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
Ping 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.
Nota |
---|
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. |
PDV LINUX - VERIFICAR MTU
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
# 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
Nota |
---|
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
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
netsh interface ipv4 show subinterfaces |
Nota |
---|
No exemplo acima (Windows) é exibido que o tamanho MTU naquele momento para a Interface de rede é 1500 |
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).
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
# 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)
Aviso |
---|
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. |
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
ALTERAÇÃO PERMANENTE DE MTU
Nota |
---|
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:
Bloco de código | ||||
---|---|---|---|---|
| ||||
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.
Bloco de código | ||||
---|---|---|---|---|
| ||||
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)
Nota |
---|
Esse ajuste deve ser realizado no Servidor de PDV Cloud, pois dispensa a necessidade de ajuste PDV por PDV. |
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
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
TELNET 192.168.2.10 8011 |
Do PDV para o Monitor de PDV
Estando no terminal, digitar Telnet IP_do_Monitor_de_PDV 7011
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
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 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.
Aviso |
---|
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. |
É 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:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
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)
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
TCPING -d -t -j 192.168.100.101 8011 |
Legenda dos parâmetros:
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:
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
netstat -an | grep 8011 |
Verificar apenas o total de conexões ativas existentes filtrando pela porta 8011
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
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
Nota |
---|
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 |
É 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.
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
Pathtping 192.168.0.201 |
É 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
Bloco de código | ||||||
---|---|---|---|---|---|---|
| ||||||
mtr -o "LSD A MX" 192.168.0.201 |
Dicas de Parâmetros
É 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 |
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/
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
Nota |
---|
No linux é possivel utiliza-lo via linha de comando no Terminal (NMAP) digitando exatamente a mesma linha que a interface ZENMAP exibe em "Command" |
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
Nota |
---|
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 |
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/
Column |
---|
|
Column | ||
---|---|---|
|
Estado | ||
---|---|---|
|
Aviso |
---|
A configuração via linha de comando acima será perdida após reiniciar o equipamento, é indicada para validação do tamanho estavel limite e confirmado, deverá ser ajustado permanentemente. |
...
...
Aviso |
---|
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 Objetos Inválidos na opção "ALL USERS" utilizando usuário que tenha essas permissões. |
...
...
...
É possível informar vários, de acordo com a necessidade de monitoramento.
...
...
...
...