Resumo

  • A RFC 4084 separa conectividade Web, somente cliente, com firewall e completa sem transformar a classificação em aprovação ou censura; o objetivo é tornar funções e restrições legíveis.
  • O recibo de capacidades mantém separados anúncio, contrato, configuração do provedor e observação controlada. Um relay que salva a aplicação não prova suporte a serviço de entrada nem obrigação de continuidade.

A primeira luz verde mede pouco

Na ativação, o técnico abre uma página, mede taxa e latência e encerra a ordem. Meses depois, uma filial descobre que o túnel cai após inatividade. Um equipamento de monitoramento não recebe conexão externa. Uma aplicação P2P alterna entre caminho direto e relay. O servidor de e-mail do cliente não consegue operar como planejado.

O produto nunca deixou de se chamar “acesso à Internet”. Foi a aceitação que confundiu conectividade de saída com liberdade operacional.

A RFC 4084, publicada em 2005 como BCP 104, propõe termos para diferentes arranjos: Web; cliente sem endereço público; cliente com endereço público; conectividade com firewall; conectividade completa. O documento não diz que o serviço mais amplo é sempre melhor. Os nomes são não pejorativos e a presença de um modelo não é endosso. O dever central é informar o usuário.

Para compras, isso muda a pergunta. Em vez de discutir se o serviço é “Internet de verdade”, a organização registra as operações necessárias e verifica cada uma.

Três fatos onde costuma haver apenas um campo

Endereço público, alcance de entrada e permissão contratual são fatos independentes. A RFC 4084 admite conectividade somente cliente com endereço público: VPNs podem funcionar, enquanto servidores são proibidos por cláusula ou filtro de entrada. Sem endereço público, NAT normalmente limita servidores e parte do P2P. Na categoria completa, NAT, proxies e restrições impostas pelo provedor sobre portas e tráfego são incompatíveis com o termo.

O inventário precisa indicar IPv4 e IPv6, exclusividade, estabilidade, classificação dinâmica, DNS reverso, ponto de tradução e capacidade de entrada. Também identifica o controlador. Um firewall gerenciado solicitado pelo cliente não é a mesma coisa que um limite padrão da oferta.

A RFC 4787 ajuda a interpretar os testes. Mapeamento e filtragem de NAT não são a mesma propriedade. Estado expira; tráfego de saída pode renová-lo; o par remoto e o comportamento de filtragem alteram o resultado. “Funcionou” precisa de hora, origem, destino, portas, direção, intervalo ocioso e repetição.

Um contorno pode ser tecnicamente excelente. ICE, relay ou túnel de aplicação podem manter o serviço. Mas o sucesso do contorno não muda o contrato, não comprova que o provedor admite servidor e não garante a mesma operação depois de uma mudança de rede.

O recibo conserva quatro verdades

Na coluna anunciado, ficam nome, versão, declaração pública e data. Na coluna contratado, ficam servidores, P2P, estabilidade, VPN, e-mail, filtros, segurança escolhida pelo cliente e obrigações de suporte.

Na coluna configurado, entram NAT, filtros de entrada e saída, proxy, interceptação, DNS, ICMP, túneis, desvio de e-mail e controles solicitados pelo cliente. Toda entrada exige identidade de mudança.

Na coluna observado, ficam pontos interno e externo, endereços vistos, protocolo, porta, direção, tempo, repetições, sucessos, falhas e incerteza. A observação não substitui a promessa e não adivinha intenção.

Três marcadores completam a prova: solicitado pelo cliente, dependente de contorno e gatilho de reteste. Eles permitem distinguir uma política corporativa de uma restrição de acesso e mostram quando a disponibilidade depende de terceiro.

E-mail é uma bateria de testes, não uma caixa de seleção

A RFC 4084 descreve provedores que exigem servidor próprio de submissão, bloqueiam portas para sistemas externos, desviam tráfego, limitam POP3/IMAP4 ou anunciam endereços como dinâmicos. Webmail funcionando não demonstra nenhum desses caminhos.

O recibo separa submissão autenticada, SMTP externo, recuperação remota, domínio de remetente, DNS reverso, reputação e desvio. Para VPN, registra tecnologia, direção, ociosidade, mudança de endereço e fallback. Para DNS, indica liberdade de resolver. Para ICMP, especifica diagnóstico. Para serviços de entrada, diferencia proibido, filtrado, interceptado e não testado.

Quem pediu e quem executou

A RFC 7754 mostra que o autor da política e o executor podem ser partes diferentes. Uma falha de conexão não prova sozinha motivo, autoridade ou legalidade. O recibo liga a restrição ao responsável conhecido e ao ponto técnico observado.

Isso produz uma alegação útil: “TCP de entrada falhou a partir de duas redes; o firewall do cliente não contém a regra; a cláusula do provedor cobre ou não cobre a porta”. A frase estreita ajuda suporte, compras e auditoria. Uma acusação ampla não faz esse trabalho.

Fontes