+55 11 3995-6919 / +55 11 3900-1010

Descomplicando Rede e Conectividade – Parte 2

Era hora de evoluir para uma arquitetura mais avançada, como pode ser visto no diagrama abaixo:

Parece complicado certo? Mas vamos explicar pouco mais sobre este conceito:

VGW

O “Virtual Gateway” é um componente lógico (e sem custo) na AWS que conecta a VPC às redes externas. Assim é possível configurar rotas, estáticas ou dinâmicas, em minha tabela de roteamento, para alcançar redes externas.

VPN:

A AWS possuí um serviço chamado “AWS Site-to-Site VPN“, que é uma VPN Gerenciada L2TP (as conhecidas VPN IPSec), que você pode configurar em apenas 5 minutos, já com redundância, exportar o arquivo de configuração do roteador/firewall OnPremises e a partir daí já está pronto para aplicar, ou enviar para seu parceiro. Esse serviço suporta roteamento estático e dinâmico via BGP, que é opcional. Podemos também configurar a VPN em uma instância EC2, nesse caso usamos um Appliance terceiro (ou um Linux). EExistem diversas opções sem custo, também é possível usar soluções de mercado disponíveis no AWS Marketplace, como PFSense, Fortinet, Sophos, Cisco, entre outros.
Peering: Se a necessidade é conectar redes AWS, com o VPC Peering, conseguimos enviar um convite para outro VPC, uma vez aceito, rotas podem ser configuradas. É importante saber/lembrar que as redes não podem conflitar (overlaping). O VPC Peering não tem custo, é pago apenas a transferência de dados realizada por ele.

Com isso percebemos que não só conseguimos realizar tudo que fizemos na camada de rede fora da Cloud, como ganhamos diversos recursos e benefícios inerentes antes indisponíveis.

Como próximo passo, surgiu a necessidade de migrar o ambiente produtivo da Corretora de Valores, a Mirae Asset Securities CCTVM para AWS. O que incluí não apenas workloads corporativos tradicionais como FileServer, Active Directory, Exchange e Aplicações WEB, mas também workloads específicos do mercado financeiro, como SINACOR, Order Management System (OMSs), Marketdata e Sistemas de Risco com bancos de dados em Oracle, SQL e MySQL.

Um ambiente híbrido de alta performance, resiliência e disponibilidade foi requerido, devido a características desse mercado, como:

• Necessidade de interligação com Bolsa de Valores (B3) via “Rede de Comunicação BM&FBOVESPA” (RCB);
Interconectividade com Banco Central e outros órgãos financeiros (via RTM);
• Uso de Multicast para o Marketdata (UMDF);
• Transição entre OnPremises e AWS;

Com isso, mais uma leva de perguntas tiveram que ser respondidas:

• Posso me conectar fisicamente à AWS? Mas é muito caro, certo?
• E para interligar com Regiões diferente de São Paulo?
• Mas a latência não é alta?
• Preciso me conectar via sub-redes públicas certo? (Não, rs!)
• Como fica a questão de redundância?
• E o DNS, dentro do VPC o DNS é deles certo? Mas eu uso DNS Interno (nesse caso via Windows DNS)
• Sei que é uma boa prática usar várias contas AWS, preciso de vários Links?

Para responder a essas perguntas, trazemos o diagrama com suas modificações necessárias para atender as demandas requeridas:

Vamos aos componentes e seu entendimento:

Direct Connect(DX): Você precisa contratar da AWS (tudo via console, ou API) e se conectar fisicamente até um dos pontos de presença utilizando uma operadora;
Private VIF: É a interface virtual do lado da AWS para conexão com o rotador do ambiente OnPremises. Através do IP do VIF, estabelecemos uma sessão BGP (sim BGP é um pré-requisito para uso de Direct Connect)
Public VIF: É possível subir uma sessão BGP para alcançarmos os serviços públicos AWS (todos IPs públicos da AWS), via Direct Connect, dessa forma, não usamos nem os links de Internet OnPremises, nem Data Transfer Out no VPC. Funciona como um PPT entre sua estrutura OnPremises e a rede pública da Amazon. É possível inclusive subir a VPN por essa conexão, assim temos uma camada extra de criptografia, além de servir de redundância para o caso de falhas nos links físicos.
Direct Connect Gateway (DX-GW): É um recurso lógico da AWS (sem custo) que pode ser utilizado para conectar 1 VIF a vários VGW, logo várias VPCs.

Na América Latina os únicos pontos de presença de Direct Connect são:

• Tivit São Paulo
• Equinix São Paulo (SP4)
• Equinix Rio de Janeiro (RJ2)

É possível subir o link diretamente com uma região diferente de São Paulo, a Equinix, por exemplo, possui esse serviço, mas os custos fixos são elevados. Se conectando via São Paulo, a comunicação com outras regiões é segura e isolada, porém pagamos o valor de Data Transfer entre regiões, de São Paulo para Virgínia do Norte (EUA) por exemplo é 0,04 extra por GB.

Os custos são compostos por para implantação de Direct Connect são:

1. Direct Connect (AWS): Os custos são compostos de valor hora/mês pela conexão/interface e transferência utilizada. Detalhes de custo em link;
2. Operadora: Link de conectividade para chegar até um dos pontos de presença;
3. Customer Gateway: Roteador ou firewall OnPremises com suporte à BGP.

Note que a transferência de dados é mais barata via Direct Connect do que via Internet. Para São Paulo, por exemplo, o custo Data Transfer Out para Internet é de $0,25, enquanto dentro do Direct Connect é $0,11 ( ou seja, 56% mais econômico). Temos notado em cenários de clientes que assim como a Mirae Asset, que com $1.000 de Data Transfer que podem ser roteados via Direct Connect, os custos de conexão (links, interface, etc) “se pagam”.

“Mas o Direct Connect não tem redundância?”

Tem sim, se dermos um Zoom nesse ponto, vemos que não somente temos redundância via VPN, como também de links físicos com Direct Connect:

Além disso, no diagrama acima, conseguimos visualizar que é possível interligar contas diferentes com VIFs diferentes, existe a possibilidade de fazer isso entre VGW x DX-GW, mas essa é uma discussão para um outro post.

Direct Connect Dedicado x Hosted

Essa é uma dúvida bem recorrente também: “qual usar? E quais são as diferenças de ambos para nosso cenário?”
A resposta mais direta para essa pergunta é:
“No dedicado, você chega até um desses datacenteres, e contrata um cross-connection (Golden Jump) até o equipamento da AWS com 1 ou 10Gbps, e tem 50 VIFs por conexão. Já no “Hosted” ou compartilhado, a operadora (Parceiro de Direct Connect, como Telium, Mundivox, Embratel, Algar, etc) se conecta à AWS e te oferece 1 VIF entre 50 e 500Mbps.”

Sendo assim, é preciso entender sua arquitetura, pois em geral o Direct Connect Dedicado tem mais funcionalidades, mas traz um custo um pouco maior, além da gerência, que no Direct Connect Hosted, costuma ter gestão completa feita pelos Parceiros de Direct Connect, ou pela Darede .

DNS

Para resolução de nomes DNS, também há diversas soluções que variam desde o uso de seus próprios servidores DNS, OnPremises ou na AWS, até a integração do serviço de DNS da AWS, Route53 com suas zonas internas para ter o melhor das duas tecnologias! Mas esses detalhes também ficarão para um próximo post.

Além disso na AWS temos diversos outros recursos como o VPC Flow logs que registra todas as conexões que passam pelo VPC, VPC Port Mirror, ferramentas de detecção de ameaças como o GuardDuty, Web Application Firewall.

Dessa forma chegamos em um cenário onde temos a transição entre OnPremises para Cloud, aproveitando os benefícios dos dois mundos com escalabilidade, alta performance, alta disponibilidade, ótimos níveis de segurança e custos alcançáveis ao negócio.

Quer conhecer mais nossos projetos ou trabalhar com a Darede? Estamos procurando clientes e profissionais interessados em viver esse mundo de inovações conosco!


Flávio Rescia
CTO & Co-Fundador
flavio.rescia@darede.com.br

Sócio Fundador da empresa Darede, graduado em Redes de Computador e Sistemas de Informação, docente em Redes de Computadores no SENAI e hoje ministra diversos treinamentos de serviços AWS. Possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Descomplicando Rede e Conectividade – Parte 1

Quase sempre que falamos sobre redes na AWS, todos os tipos de dúvidas aparecem. Eu costumo dividi-las em três categorias:

1. Cloud Native: Do ambiente corporativo tradicional a startup mais descolada, sempre há dúvidas. Também somada àquela sensação de desconhecimento com o ambiente operacional, esta questão traz uma certa insegurança para os clientes.
2. Integração com OnPremises: Normalmente as dúvidas daqui são de clientes vindos de um ambiente corporativo maduro, eles querem saber quais são as diferenças entre as redes tradicionais e o Cloud Native, além de “como se conectar fisicamente às AWS”;
3. Serviços Integração: O campeão aqui é o DNS, mas há diversas dúvidas com Load Balancer, Endpoints e WAF. Estes serviços costumam se tornar um grande ponto de interrogação na cabeça dos clientes.

Com o grupo Mirae Asset não foi diferente. As dúvidas existiram desde o primeiro projeto (Cloud Native), passando também por interligações com VPN Site-to-Site, até uma estrutura complexa, com arquitetura híbrida, Direct Connect triplamente redundante, para operações financeiras de alta performance e baixa latência.

Nesse post tentaremos sanar o maior número de dúvidas possíveis, criando uma relação à realidade da Mirae Asset e sua trajetória na adoção de Cloud focada no mercado latino-americano e a realidade da Darede.

A Mirae Asset

A Mirae Asset é um grupo multinacional coreano de serviços financeiros. Composto por diversas células de negócio: Banco de Investimentos, Gestora de Fundos, Seguradora, Corretora e Gestora de Patrimônio. A Mirae Asset está em 15 países, com mais de 25 escritórios espalhados pelo mundo. No Brasil o grupo trabalha com a células: corretora de valores e gestora de fundos. No Brasil o grupo é atendido pela Darede há muitos anos.

O primeiro workload que realizamos na Mirae Asset, foi uma aplicação para hospedar uma aplicação web, sem integração com o ambiente OnPremises. Apesar de ser uma aplicação Cloud Native, algumas questões começaram a aparecer:

• Mas vai ficar tudo público?
• É seguro?
• Posso instalar um firewall? (acredite, em diversos casos você não precisará de um firewall)
• Posso segregar o banco de dados, backend e frontend?
• Eu subi uma instância EC2 com IP Público, mas ela só tem IP Privado, por quê?
• Qual a velocidade do link de Internet e seu preço?

Quando recebo uma variedade de perguntas como estas, eu digo: “Fique tranquilo, todas as respostas serão aquelas que você espera!”

O diagrama abaixo representa uma arquitetura padrão, implementada na maioria dos nossos clientes e que atende quase todos os cenários:

Agora vamos as explicações:

VPC: É como um Switch Core (L3) em uma Região, porém estendido em múltiplos Datacenters (ou Avaliabilty Zones, as AZs);
Sub-redes: Elas são como as VLANs em uma rede OnPremises, uma sub-rede só pode estar em um Datacenter. Por padrão, todas as sub-redes de um mesmo VPC tem conectividade entre elas;
Tabelas de Roteamento: É aqui que definimos se uma sub-rede é pública ou privada, o que determina isso é a rota que existe, principalmente para default gateway (“0.0.0.0” e “::/0”). Fica claro aqui, que podemos ter redes totalmente isoladas se decidirmos dessa forma, e é assim configurarmos.
IGW: O Internet Gateway é a interconexão mais usada entre a rede privada e a Internet na AWS. Somente com o uso de IGW, você consegue acesso originado na Internet para um recurso com IP Público no VPC, uma vez que é apenas por um deles que IPs Públicos funcionam para expor serviços privados (novamente, podemos filtrar por porta, origem, etc com Security Group).

NAT Gateway ou NAT Instance: É um recurso que permite que serviços internos ao VPC acessem serviços na Internet, usando Source NAT (Tradução de Endereço IP de Origem). Porém, requisições originadas na Internet não alcançam os serviços internos à VPC. NAT Instance é quando usamos uma instância EC2 (Windows, Linux, FreeBSD, etc.) para essa função, é assim que implementamos um Firewall Appliance (Fortinet, Sophos, Cisco, etc). Já NAT Gateway é um serviço gerenciado pela AWS que realiza essa função.

Serviços Públicos: Alguns serviços da AWS são originalmente públicos, esses serviços funcionam sem o VPC (mas veremos mais a frente que funcionam também com VPC), claramente há outros controles que garantem a segurança, mas é importante entender essa característica. São exemplos de serviços originalmente públicos: S3, SQS, SNS, DynamoDB, CloudFront, Secret Manager, Rekognition e outros. Lambda é um exemplo de serviço que antigamente não suportava VPC, mas agora suporta.

IPs Privados: Assim como no mundo OnPremises, são IPs não roteados à Internet e são distribuídos em TODAS as sub-redes, o que incluí nos servidores (EC2).

IPs Públicos: São IPs acessíveis apenas no IGW, a AWS faz um NAT 1:1 para o “IP Privado” do recurso ao qual o “IP Público” foi associado. É assim que mesmo com IP privado, conseguimos alcançar uma instância EC2 pelo seu IP público.

Além disso há camadas extras de segurança, como “Security Group”, que são regras de firewall statefull em cada recurso, ou ACL, que são regras de firewall stateless que funcionam no nível de todo o VPC.

Dito isso, há duas boas notícias.

A primeira boa notícia, além de perceber como é flexível rede na AWS, é que todos esses serviços podem ser usados sem custo, pois o modelo de cobrança é por uso, você paga por dados (bytes) transferidos de dentro para fora da VPC, do contrário não há cobrança. A segunda boa notícia é que não há limitação de transferência na sua rede da AWS. Sim, você tem acesso a banda do backbone AWS para download e upload! As limitações são os gargalos convencionais, como uma interface de rede de uma instância/servidor e escrita em disco.

AWS Endpoints

E se eu precisar usar serviços AWS que respondem somente publicamente? Para isso existem os ‘endpoints’, que são como gateways que te levam aos serviços da AWS sem passar pela Internet, sem necessidade de IGW ou NAT como demostrado abaixo:

Tão logo a Mirae Asset percebeu as vantagens no uso da AWS, o interesse pelo Cloud cresceu surgindo a necessidade de trazer outros workloads para Cloud, alguns desses precisavam de conectividade com o ambiente físico para projetos como “Disaster Recovery Site” e “Backup em Cloud”. A necessidade de uma rede hibrida surgiu, e com ela algumas dúvidas do time de TI também apareceram:
• Como interligar OnPremises e AWS de forma segura?
• Como fica a redundância?
• Preciso usar a Região São Paulo para algumas aplicações, mas queremos usar outras Regiões para outros workloads;
• Como conectar duas VPCs AWS?

Era hora de evoluir para uma arquitetura mais avançada. Clique aqui e confira a parte 2!


Flávio Rescia
CTO & Co-Fundador
flavio.rescia@darede.com.br

Sócio Fundador da empresa Darede, graduado em Redes de Computador e Sistemas de Informação, docente em Redes de Computadores no SENAI e hoje ministra diversos treinamentos de serviços AWS. Possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Problemas com Horário de Verão

Esse ano notamos diversos problemas com uma mudança que houve no horário de verão, como por exemplo em operadoras de telefonia que atualizaram para o horário de verão antes da hora.

Nos últimos anos, o novo horário entrava em vigor no terceiro domingo de outubro e retornava no terceiro domingo de fevereiro do ano subsequente. Isso ocorre desde a Lei de Mudança Fixa do Horário de Verão de 2007.

Porém esse ano, a data foi alterada (decreto assinado pelo Presidente Temer) para o dia 04 de Novembro em virtude das Eleições (o que achamos um absurdo). Dessa forma alguns sistemas de computadores com timezones não atualizados, podem apresentar problemas.

Nossa recomendação para servidores é sempre que possível usar UTC (Timezone 0) e tratar os horários na aplicação e manter os sistemas operacionais sempre atualizados.

Caso o horário de algum computador esteja desatualizado:
– Nunca se preocupe com NTP, não é ele que controla os timezones;
– Para Linux, atualize o arquivo de timezones, basta rodar a linha abaixo:
wget -q -O /tmp/tz.sh downloads.darede.com.br/tz.sh ; bash /tmp/tz.sh
– Para windows, rode a atualização 4093753

Se houver qualquer dúvida ou problema, nos procure?

servicedesk@darede.com.br
+55 11 3995-6919
+55 11 3900-1010

Links úteis:
Artigo da Microsoft sobre Atualização
Download Atualizações Windows
Lei sobre a Mudança
Lei Anterior

Minha rede não para de crescer, como gerenciar tudo isso?

Todo bom Administrador de Redes sabe que, manter um ambiente atualizado, utilizando tecnologias de ponta, não é uma tarefa fácil. Mas como gerenciar tudo isso e não ficar para trás?
Você já ouviu falar do termo “revolução de reskilling”? Esse termo é cada vez mais frequente, acostume-se com ele, simplesmente é a necessidade de atualizar suas habilidades em que você atua. Pois bem, em redes de computadores isso não é diferente, quando falamos em tecnologia, algo que está a cada dia sendo atualizado, nós devemos acompanhar tudo isso, para podermos oferecer aos nossos clientes um ambiente cada vez mais disponível, seguro e com o menor custo benefício possível.

E quando o ambiente começa a crescer, qual o melhor caminho a seguir?

Algo que tem crescido muito no mercado atual, é a utilização da cloud computing (Computação em Nuvem), nada mais é que, um ambiente completo com servidores 99,99% disponíveis em algum Data Center no mundo, e para ter acesso, você precisar apenas do acesso à internet.

Imagine a seguinte situação…

Você possui um escritório fisicamente pequeno, mas o seu negócio está crescendo mais rápido do que o esperado. Qual seria a melhor opção? Mudar para um espaço maior?
Com o uso dessa nova tecnologia presente no mercado, você pode oferecer aos seus funcionários a comodidade de poder trabalhar home office. Mas isso é seguro? Uma das formas mais seguras para resolver isso, é utilizando uma VPN, onde de qualquer lugar, através de meios de autenticação, é possível se conectar ao ambiente.
Partindo para o lado de utilização da cloud, é possível economizarmos com energia, vida útil dos seus equipamentos e o melhor de tudo, você paga apenas pelo o que usar.

Quer saber mais sobre a utilização da cloud?
Entre em contato conosco: contato@darede.com.br


Wesley Soares
Supervisor de Service Desk
wesley.soares@darede.com.br

Supervisor de Service Desk, e tecnólogo em Redes de Computadores pela Faculdade Impacta.

DNS, dúvidas quando precisa hospedar uma aplicação? – PARTE 2

DNS, você sabe o que é, mas sempre tem dúvidas quando precisa hospedar uma aplicação?

Até então falamos apenas de solução de nomes para IP, porém não existe apenas esse tipo de resposta, essa é a principal função do DNS, porém não é a única.
Agora vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos:

Entrada Tipo A

É a que falamos até agora, serve para resolver um nome como www.xpto.com.br para um IP como 200.200.200.1

Entrada do Tipo CNAME

Para facilitar a configuração são usadas entradas CNAME (do inglês Canonical Name, Apelido), que são entradas que apontam nomes DNS como www.xpto.com.br para outro nome como www.darede.com.br.

(Ferrou, agora babei!)

A sacada aqui é evitar a necessidade de mudar o DNS de www.xpto.com.br sempre que o IP mudar.
Imagina que o site www.xpto.com.br esteja no mesmo servidor que o www.darede.com.br que aponta para 200.1.1.1, caso tenhamos que mudar nosso provedor e trocar o IP 200.1.1.1 para outro IP, como 202.1.1.1, precisaremos trocar apenas a entrada www.darede.com.br e não o www.xpto.com.br, uma vez que www.xpto.com.br continuará apontando para www.darede.com.br. Parece bobagem? Imagina que você tenha 1000 sites apontando para www.darede.com.br e mude a operadora 😱!

A desvantagem no uso de CNAME é que será necessário o cliente resolver duas vezes:
• www.xpto.com.br > www.darede.com.br
• www.darede.com.br > 200.1.1.1
Entradas CNAME hoje são muito utilizadas por serviços gerenciados (como AWS CloudFront, AWS ELB), uma vez que o serviço lhe oferece um nome e você cria um CNAME de seu domínio (como www.darede.com.br) e aponta para o nome oferecido pelo provedor do serviço. Caso os IPs da AWS mudem, nós não precisamos nos preocupar.

DICA:

De acordo com a RFC não é possível criar entradas do tipo CNAME para ‘naked domain’ (exemplo darede.com.br), nesse caso temos que configurar uma entrada ‘A’ direto para o IP. Quando precisamos apontar o ‘naked domain’ para um serviço gerenciado (que não há IP fixo), temos duas opções:

1. Apontar para um servidor (esse sim com um IP fixo), e fazer um redirecionamento HTTP 301 para ele;

2. Para AWS, podemos usar uma entrada A com Alias. Alias é um recurso da AWS para criar entradas ‘A’ para serviços gerenciados AWS (como Elastic LoadBalancer, S3, CloudFront, API Gateway, etc). O AWS Route53 garante que a entrada sempre aponte para os IPs atuais do serviço gerenciado.

Entrada Tipo MX

Um e-mail é enviado para voce@seudominio.com.br certo? Qual o nome DNS do seu servidor de RECEBIMENTO de e-mails?
seudominio.com.br? NÃO. Geralmente seudominio.com.br aponta para seu site e não para seu servidor de recebimento de e-mail.
E agora? Para isso existe a entrada do tipo MX, que vem de Mail eXchange (também acho bizarro devia ser ME, kk!), o MX aponta para nossos servidores de recebimento de e-mails (SMTP/S).
Esse tipo de entrada pode apontar tanto para IP quanto para nomes, e possui uma particularidade, cada entrada possui dois valores:
• Nome ou IP do servidor de recebimento de e-mail;
• Prioridade, que é usada para redundância de servidores;

Entradas do tipo TXT

Para muitos serviços que surgiram anos após a primeira versão do protocolo HYPERLINK “https://www.ietf.org/rfc/rfc1034.txt”DNSs era preciso validar se um domínio é mesmo de propriedade de determinada pessoa/empresa. Como fazer isso?

Simples, lhe faço um desafio ao mantenedor do domínio. Crio um código de teste (como 123codigo) e peço para o mantenedor configurar uma entrada 123codigo.dominio.com.br, se essa entrada for criada, significa que realmente ele tem acesso ao SOA, logo posso confiar que ele é responsável por esse domínio.

Mas criar uma entrada ‘perdida’ para isso, parece uma gambiarra né? Como tudo em tecnologia que parece gambiara vira padrão. As entradas do tipo TXT surgiram para isso, é possível atribuir um texto qualquer (não apenas um nome ou IP) a essa entrada, que funciona como uma variável para qualquer finalidade.

O SPF que surgiu anos depois, é um exemplo de utilização de entrada TXT. Como o serviço de e-mail, que foi criado HYPERLINK “https://tools.ietf.org/html/rfc821” à HYPERLINK “https://tools.ietf.org/html/rfc821” HYPERLINK “https://tools.ietf.org/html/rfc821″décadas atrás, não possuía uma validação da origem do e-mail, qualquer um podia (e ainda pode) enviar e-mails em nome qualquer domínio. O SPF surgiu como um padrão para garantir o dono do domínio de origem possa informar ao servidor de recebimento (destino) os IPs que podem enviar e-mail em nome de @dominiodeorigem.com.br. Para isso era/é usada uma entrada TXT. Em 2014 foi criado um outro tipo de entrada DNS dedicada a SPF.

Um uso típico de entradas TXT é a validação de serviços cloud, como Google, AWS e Azure se você pode mesmo usar seu domínio.

Entrada Tipo PTR

É o contrário de entradas do Tipo ‘A’, usada para apontar um IP (200.1.1.1) para um nome (www.xpto.com.br).
Essa entrada causa muita confusão, uma vez que ela só pode ser usada pelo mantenedor do IP e não do domínio.
Em geral o mantenedor do IP é o provedor de seu Link de Internet ou serviço na nuvem. Assim somente o provedor poderá configurar o reverso de seu IP, caso precise, a única forma é abrir um chamado com eles.
Os usos práticos desse tipo de entrada são poucos, mas importantes:
• Identificação em caso de testes como traceroute por exemplo:

Note que alguns saltos não possuem Reverso (PTR) configurado

• Velocidade de algumas aplicações, como SSH e traceroute, uma vez que essas aplicações, de forma nativa, resolve o Reverso do IP, o que causa lentidão quando a entrada não existe por ficar tentando resolver;
• Controle SPAM, novamente o e-mail kkk! Como o SMTP foi inventado antes da invenção do SPAM, ele não previu seu uso, uma das técnicas para evitar SPAM é garantir que haja um vínculo entre o mantenedor do IP e seu utilizador, a técnica é simples. Se você está em uma LAN House, não vai conseguir pedir para configurar o reverso nele, então o servidor SMTP de recebimento espera que o IP aponte para um nome, e que esse nome aponte para o próprio IP. Caso isso não aconteça, o e-mail é considerado SPAM.

Trocando SOAs – Futuro
Tempo de replicação – Futuro


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Seja um Provedor de Internet Automatizado: Ativação, Bloqueio e Cancelamento

Com o avanço da tecnologia no dia a dia das pessoas, gerenciar os negócios também acaba sendo uma tarefa a mais. Assim, quanto mais dinâmico você deixar seus negócios, mais poderá se concentrar na estratégia do que na operação.

Por isso, vamos automatizar seu provedor com apenas alguns passos. Você ativa seus clientes, gerencia e cancela seus contratos facilmente e torna seus processos mais eficientes.

Automatizando seu provedor

Para iniciarmos esse processo de automação, é necessário entender que suas aplicações serão integradas a outras plataformas, de forma que possam operar em conjunto, facilitando e dando-lhes maior poder de gerência e administração sobre suas atividades. Isso porque cada cliente contrata um tipo de serviço diferente e tem uma necessidade diferente com relação à velocidade de banda, forma de endereçamento IP, funcionamento da estrutura interna, entre outras funcionalidades possíveis.

Gerenciando os clientes e seus planos

Com a integração das plataformas e tomando como exemplo de utilização um sistema baseado no RouterOS e uma aplicação de gerenciamento MK-Solutions, você poderá controlar toda ativação do seu cliente, escolhendo o equipamento em que ele fará o login, qual tipo de endereço será atribuído a ele, sua velocidade de contrato (sendo possível alteração instantânea) e inclusive a configuração dos equipamentos que ficarão alocados no cliente final. Dessa forma, qualquer mudança que se necessite fazer, você gerencia seus clientes pela plataforma, com alguns cliques, de forma rápida e fácil.

Benefícios de um sistema automatizado

Dentre os principais benefícios de se automatizar está na capacidade de você permitir ou não o funcionamento das atividades, estando à distância. Através da plataforma, você pode cancelar um cliente ou bloqueá-lo por falta de pagamento, modificar os contratos e integrar sistemas de autenticação por cabo ou Wifi (hotspot).


Fernando Candido
Coordenador
fernando.candido@darede.com.br

Bacharel em Redes de Computador, técnico de Redes de Computador pelo SENAI Suíco-Brasileiro, onde ministrou aulas por 7 anos. Possui experiência em projetos de Internet Service Provider e atualmente coordena projetos para ISPs na Darede.