Linio Alan

O que é certo é que esse equipamento faz a validação de região para a modulação de frequência de rede sem-fio, no caso de um firmware chinês fora do território dele, esse check-up muito provavelmente está entrando em loop na tentativa de sincronizar a configuração correta, mas entendo que essa versão de firmware chinês muito provavelmente terá triggers muito específicas, mais ainda do que a versão 'global', seria o mais plausível de ocorrer do meu ponto de vista. Fosse eu no seu lugar, eu tentaria o upgrade ou downgrade para a versão Global mesmo, do que para uma outra versão chinesa. É bem comum equipamentos de rede, mesmo esses SOHO terem uma página dedicada à logs para análise de erros, o seu tem algo nesse sentido?

Explique melhor o que foi feito, como ocorre o acesso à partir de outras máquinas na rede Workgroup e a versão de Windows em cada uma das máquinas, e ainda se estão todos no mesmo plano de endereçamento tanto via WiFi quanto via cabo.

Numa escala de 1 - 10 o repetidor WiFi for um '10' mas o seu adaptador WiFi for um '4' num cenário de qualidade hipotético, tendo ainda uma distância considerável e uma parede entre ambos, então sim vai ter problemas sem dúvidas. Neste cenário, o mais indicado é levar o repetidor o mais próximo possível da sua estação de trabalho, com o repetidor sendo instalado no mesmo cômodo/espaço, conectando-o ao ponto de rede principal via cabo. Em qualquer dos casos o investimento em equipamentos quiçá em mão-de-obra pode ser considerável, melhor 'custo-benefício' sempre tende à ser com o cenário extendendo via cabo de rede como exemplificado acima.

A descrição do problema faz suspeitar principalmente do driver de rede mesmo, se ainda não o fez faça a atualização deste (se hourver) ou mesmo a sua reinstalação. O adaptador WiFi<>USB teoricamente modula a frequência que o seu notebook não tem -- 5Ghz -- e se for realmente plug-and-play como anunciado pode ser exatamente a solução para um problema de instabilidade driver de rede no Windows Home desse notebook, embora não tenha utilizado particularmente este adaptador em específico para uma melhor recomendação. Lembrando que, se acabar por adquir o adaptador, usá-lo a porta USB 3.0 (azul) para uma melhor experiência:

Você fez o hard-reset? Se fez, após o procedimento acima,consegue/conseguiu reproduzir o passo-a-passo da configuração abaixo?

Dependendo do provedor VPN que usar, o tráfego para os sites não são tunelados/roteados pela VPN, precisava ver qual a rota e servidor DNS estão sendo usados entre o seu PC e os sites com e sem VPN ligada: nslookup github.com tracert github.com

Faz a consulta do MAC-address nesse site, veja se está registrado para algum fabricante conhecido: https://www.wireshark.org/tools/oui-lookup.html

Existem mais coisas pelo caminho que podem e vão impedir o acesso remoto via RDP de fora da sua rede, muitos níveis de NAT entre o seu PC e a sua operadora principalmente. Configurar o redirecionamento de portas no seu roteador e usar um DDNS como o No-IP funcionavam bem antes dos provedores usarem CGNAT e bloqueio de ataques e tráfego malicioso. TeamViewer e outros programas de acesso remoto funcionam de forma independente do protocolo RDP, por isso funcionaram.

Essa configuração permitindo conexões externas estar alinhada especificamente para o IP do servidor é mandatório, você fez bem! A proteção também se complementa fazendo o servidor aceitar conexões apenas da sua rede, no caso dos IPs da sua LAN/WAN, provavelmente está ocorrendo por fora da sua VPN certo pela sua menção ao DDNS, então os IPs dos provedor também são IPs públicos mas dinâmicos, então seria interessante fechar a VPN para transmitir também o backup, deixaria o servidor, a transmissão em si dos backups e a sua rede LAN mais seguros de ataques externos. Claro que o WAF e firewall da VM na cloud já mitigam bastante essa questão, porém como o backup muitas das vezes É o bem mais valioso em termos gerais, será muito bem-vinda esse "hardening" com mais essa camada de proteção: transmissão do backup pela VPN.

A vantagem de especificar portas na origem da conexão e não deixar aberto estilo UPnP é a segurança, em caso de comprometimento de algum dos hosts na sua rede LAN, não vai necessariamente barrar o scan malicioso mas vai atrasá-lo e, eventualmente até te permite estabelecer regras mais rígidas de conexão com autenticação na origem, porém a aplicação que abre a sessão com o servidor destino precisa ter especificada a porta que o seu firewall está permitindo a saída. Em segurança porém, o "custo-benefício" sempre será a melhor métrica de sucesso, não se trata de frouxidão nas regras mas na aplicabilidade das melhores práticas que permita o negócio existir dentro de um framework de segurança para a realidade em questão.

Excelente documentação e detalhamento do cenário mas para mitigar o problema de falha na conexão do servidor na rotina de backup é preciso realizar a captura de pacotes tanto lá no servidor quanto após o seu pFsense que está realizando o balanceamento dos links, o teste de captura de pacotes ou famoso tcpdump serve pra confirmar como o tráfego está ocorrendo, se por fora ou por dentro da VPN, qual IP que chega no cabeçalho do pacote , tanto na ida quanto na volta do mesmo pacote, isso é um troubleshooting relativamente complexo e que demanda 100% de hands-on, o teste de tcpdump é apenas uma das etapas de troubleshooting, para enfim saber quais ajustes na sua rede interna deverão ocorrer, se a supressão ou mudança de alguma regra NAT ou rota IP ou o que for necessário. Ferramentas: tcpdump ou Wireshark ou o outra ferramenta que for mais familiar para você.

Se você chega à cogitar o X50 e se por acaso a sua planta for considerável -- dezenas de metros quadrados para cobrir com sinal WiFi -- vai de X50. Mas se economia e uma planta modesta/mediana for a sua realidade, o X10 vai te atender bem também.

O cascateamento de roteadores -- A <> B -- ocorrerá perda natural devido overhead Ethernet principalmente (encapsulamento > desencapsulamento) múltiplas vezes, à isso dá-se o nome de "Windowing" ou "Janelamento Ethernet", então mesmo no cabo não conseguirá usar 1Gbps do link internet, aliás provavelmente não consegue isso nem no roteador da operadora pela mesma razão acima, irá ocorrer um overhead e a banda total utilizável será descontada, mesmo que pouco mas será, quanto mais em outro roteador cascateando após este. Embora ocorra esse déficit na banda utilizável, não será nenhum problema do ponto de vista prático, mas pode vir a ser caso o uso no roteador A seja intenso, lotando a capacidade de comutação dos frames Ethernet interna do equipamento, pois o tráfego da rede do roteador A irá disputar recursos com a rede do roteador B. Somente a prática dirá o que irá ocorrer, faça o cascateamento e verifique o resultado.

Zigbee estando devidamente configurado não vejo razão para interferência direta na sua VPN, salvo se esse device estiver lotando a sua rede LAN com eventual tráfego broadcast, que pode estar chegando em todos os devices na rede e, por consequência interferindo na banda utilizável prática da rede e gerando ainda colisões, mas isso somente com um Wireshark para se averiguar, fora isso não vejo correlação entre um e outro. Quanto a diferença no número e saltos na comparação com a internet da sua sogra, se estiver realmente ocorrendo, é bem estranho, muito mesmo. Sua operadora deveria investigar isso pois, em teoria, deve haver o mesmo número de saltos, mas existem outros elementos que podem interferir na qualidade de rede para além do número de saltos, como a forma que a rede LAN está estruturada e como se dá o uso desse link internet. Uma forma de se investigar essa questão, ao meu ver, seria o de fechar uma outra VPN em outro host na sua rede, e deixar rodando um teste de ping ou MTR para se determinar questões como perda de pacote, latência e jitter. Um teste rodando dentro da VPN e outro rodando contra o IP de gateway padrão que aparece nas informações de rede na interface PPPoE que o seu AX73 adquiriu via sessão PPPoE, para confirmar se as perdas ocorrem dentro do backbone da operadora ou fora dela.

@tiagopraz sua portaria não usa Whatsapp né? Mas aparentemente você fez tudo certo, colocou um conversor de mídia e gateway como o ATA e incluiu ele no Issabel como um ramal digital, que por sua vez precisa ser convertido ainda para ramal IP, o que já está feito com certeza caso contrário você não conseguiria ouvir o porteiro. Ocorre que dentro do esquema "digital <> IP <> digital" existe a necessidade, assim como entre roteadores, de se criarem rotas, lembro de ter criado isso no Asterisk mas no Issabel fica por sua conta, porém o princípio é comum entre ambos, precisa existir rota de ida e volta caso contrário ocorre o que você está tendo, de um dos lados não ouvir. Outra questão à ser verificada é o Codec, para rotear chamadas pela internet acredito que o G.729 seja o melhor por ter um payload leve de ser roteado e manter as características mais próximas do áudio original. Mas antes de funcionar na internet, esse seu ramal VoIP precisa funcionar na sua rede LAN, isso está ocorrendo? Lembre-se de que para funcionar na sua rede LAN o roteamento do Issabel para o seu smartphone não pode sair para a internet, então nesse caso precisa apontar para o IP LAN do Issabel, ok?