Acesso remoto & CGNAT
O conjunto de protocolos conhecido como TCP/IP é responsável por transmitir dados e identiticar computadores na rede, sendo a principal tecnologia que sustenta a internet. Um problema a muito tempo conhecido (e vivenciado) no TCP/IP é o esgotamento de endereços baseado em IPV4, a solução? IPV6, com endereços em IPV6 as identificações beiram o infinito, porém adotar IPV6 demanda uma transição longa e complicada por parte dos ISP (Internet Service Provider).
Atualmente muitos ISPs utilizam a tecnologia CGNAT (Carrier Grade NAT) como meio de dar uma sobrevida ao IPV4 enquanto o IPV6 não é globalmente adotado, o grande problema aqui é que a solução paliativa se tornou uma "solução final" (muitos devs devem ter se identificado com isso agora) devido a inércia em compatibilizar tudo em IPV6 logo. O CGNAT a grosso modo permite que um único endereço IPV4 seja reaproveitado por vários clientes do ISP, é como se houvesse um outro roteador do lado WAN, uma baita gambiarra.
O uso de CGNAT atrapalha muito quando queremos acessar remotamente algum dispositivo como gateways, roteadores, terminais ou qualquer outra coisa conectada a internet devido ao fato de não se ter um endereço único, pois no CGNAT o "seu" endereço IP do lado WAN não é só seu. Quando garantir um IP público fixo para o equipamento, ou deslocar-se até ele é uma tarefa inviável, o melhor caminho é o de garantir no próprio equipamento estratégias de acesso remoto via túneis como SSH reverso, VPNs ou serviços terceiros como pagekite ou ngrok antes da instalação final em campo .Todas essas estratégias partem da idéia básica de que primeiramente o equipamento remoto se conectará a um servidor vísivel na internet, em seguida o cliente que deseja acessar remotamente o equipamento também deverá se conectar a esse servidor, com isso teremos um túnel livre e seguro conectando dispositivo e cliente enquanto a sessão estiver em pé. Até aqui ficou claro que com CGNAT é necessário um terceiro agente (pago e geralmente dificil de configurar) intermerdiando essa conexão.
Nesse artigo quero apresentar um solução de baixo custo para ser utilizado no lugar de serviços de túneis quando se está preso em uma rede CGNAT, é um script de minha autoria que chamo de termB. É basicamente um script em python que utiliza um bot do Telegram em execução no seu dispostivo. Por meio do chat do Telegram é possível enviar comandos de terminal e trocar arquivos, são tarefas básicas,mas suficientes para realizar a maiorias das manutenções e configurações mais comuns em equipamentos remotos como mudar alguma regra no firewall, editar configurações de alguma interface de sensores/atuadores ou até enviar um novo firmware (sinceramente não testei isso ainda).
Com essa abordagem de utilizar um chat é possível enviar comandos para vários bots (equipamentos remotos) ao mesmo tempo e com isso realizar tarefas em lote de modo seguro graças a criptografia do Telegram.
Assim que tive essa ideia fiz uma pesquisa na internet para ver se fui o primeiro a pensar nisso,não fui. Algumas pessoas já construíram scripts semelhantes em shell script, python e programas compilados em C,mas sempre com a mesma ideia de mapear no bot um comandos especifico do sistema de destino. No meu script decidi deixar isso flexível para permitir o envio de qualquer comando e também adicionei formas de permitir a troca de arquivos (Sim! Você também pode receber aquivos do bot/equipamento). Imagina que legal buscar aquele arquivo em .csv daquele datalogger esquecido dentro de um painel empoeirado no meio do nada?
Recomendados pelo LinkedIn
Segue o link do meu github com detalhes de como utilizar:
Um uso real desse bot: