The Rise of the VPN: From Dial-Up Tunnels to WireGuard and Zero Trust
2026-08-22 · 10 min
A VPN's core idea has not changed since the mid-1990s: wrap traffic in an encrypted tunnel so it can cross a network you do not trust - typically the public Internet - while behaving as if it were still on the private network at the other end. What has changed dramatically, generation after generation, is how that tunnel is built, how strong its encryption is, how fast it runs, and eventually, whether the whole concept of a single trusted 'inside' the tunnel still makes sense at all.
That evolution tracks almost exactly against the Internet's own growth from a curiosity to critical infrastructure: each new protocol generation exists because the previous one's weaknesses became too expensive, too slow, or too insecure to keep tolerating at the new scale.
1996
PPTP is developed
Microsoft and a consortium of vendors create the Point-to-Point Tunneling Protocol, the first widely deployed consumer/enterprise VPN protocol, built into Windows 95's OSR2 update.
1999
L2TP is standardized
Layer 2 Tunneling Protocol (RFC 2661) combines the best ideas of PPTP and Cisco's L2F, but has no built-in encryption of its own - it is almost always paired with IPsec.
1998-2005
IPsec matures
The IPsec suite (RFC 2401 and successors) becomes the enterprise standard for site-to-site VPNs, providing strong, standardized encryption and authentication at the network layer.
2001
OpenVPN is released
James Yonan releases OpenVPN, an open-source SSL/TLS-based VPN that runs over standard UDP or TCP - easy to firewall-traverse and free from any single vendor's control.
2002-2003
SSL VPNs go mainstream
SSL/TLS-based 'clientless' VPNs (accessible from a browser) emerge as a lighter alternative to IPsec for remote-access use cases, avoiding IPsec's notorious firewall/NAT traversal headaches.
2005
IKEv2 is published
RFC 4306 (later RFC 7296) modernizes IPsec's key exchange, adding fast reconnection after a dropped connection - the feature that made IPsec genuinely usable on mobile devices switching between WiFi and cellular.
2012
WireGuard development begins
Jason A. Donenfeld starts designing WireGuard around a radical goal: a fraction of the code size of IPsec or OpenVPN, using a small, fixed set of modern cryptographic primitives instead of dozens of negotiable, sometimes-outdated options.
2018
Linus Torvalds merges WireGuard into Linux
WireGuard enters the Linux kernel mainline, a strong technical endorsement, and rapidly becomes the reference implementation for a new generation of fast, minimal VPN protocols.
2020
Zero Trust goes mainstream
NIST publishes SP 800-207, formalizing the Zero Trust Architecture model: verify every request individually regardless of network location, rather than trusting anything already 'inside' a VPN tunnel.
2020-2024
SASE and ZTNA displace classic remote-access VPN
Secure Access Service Edge and Zero Trust Network Access platforms increasingly replace always-on, full-network VPN access with per-application, continuously verified access - the direct architectural response to VPN's long-standing 'once you're in, you're trusted everywhere' weakness.
Why VPNs exist at all
Before broadband and cloud services, reaching a corporate file server or mainframe from outside the office meant a direct dial-up modem connection into a bank of remote-access servers - reliable but expensive to scale and entirely dependent on phone infrastructure. As the public Internet became cheap and ubiquitous in the mid-1990s, the obvious next step was to reuse it as the transport, but that only works if the traffic crossing it is protected from the untrusted networks in between - which is exactly the problem PPTP was built to solve in 1996.
Every VPN protocol since has been solving some combination of the same three problems: how to build the tunnel, how to prove both ends are who they claim to be, and how to encrypt what flows through it - with each generation making different tradeoffs between security strength, connection speed, and how well it survives firewalls, NAT, and unreliable networks.
A VPN wraps a client's traffic in an encrypted tunnel across an untrusted network (typically the public Internet) to a gateway, which then forwards it onto the private network as if the client were directly attached.
The first generation: PPTP, L2TP, and IPsec
PPTP was fast and simple to set up - genuinely groundbreaking for 1996 - but its encryption (Microsoft's MS-CHAP-based scheme) was progressively broken by researchers over the following decade and is now considered insecure for anything sensitive. L2TP, standardized in 1999, fixed PPTP's tunneling design but deliberately left out encryption entirely, on the assumption it would always be paired with a separate encryption layer.
That layer was IPsec, and the combination of L2TP for tunneling plus IPsec for encryption became the de facto enterprise standard through the 2000s. IPsec's strength was operating at the network layer, meaning it could secure any IP traffic transparently without any application even being aware of it - but that same low-level design made it notoriously difficult to get through firewalls and NAT devices, a persistent operational headache for anyone deploying it at scale.
SSL VPNs and OpenVPN: solving the firewall problem
The mid-2000s answer to IPsec's traversal problems was to build VPNs on top of SSL/TLS instead - the same protocol securing HTTPS traffic, which every firewall on Earth already had to let through on port 443. 'Clientless' SSL VPNs, accessible straight from a browser, made remote access dramatically simpler to deploy for basic use cases, while OpenVPN (released in 2001, but reaching wide enterprise adoption through this period) offered the same SSL/TLS-based approach as a full, flexible, open-source tunnel that could run over either UDP or TCP.
OpenVPN's open-source nature mattered as much as its technical design: unlike IPsec's dozens of vendor implementations with inconsistent interoperability, or PPTP's Microsoft-controlled evolution, anyone could audit, extend, or embed OpenVPN, and it became the default choice for consumer VPN services and self-hosted deployments alike for the better part of two decades.
WireGuard and the move toward radical simplicity
By the 2010s, IPsec and OpenVPN both carried real technical debt: large codebases (tens of thousands of lines), dozens of negotiable cryptographic algorithms (several since deprecated as insecure), and correspondingly large attack surfaces. WireGuard's answer, starting in 2012, was almost the opposite design philosophy: roughly 4,000 lines of code, a single fixed, modern cryptographic suite with no negotiation, and a connectionless design built around the same principles as SSH's key-based authentication rather than certificate hierarchies.
The result measurably outperforms both predecessors on speed and battery life on mobile devices, while its small codebase is genuinely auditable in a way IPsec's implementations never realistically were - which is exactly why Linus Torvalds merged it directly into the Linux kernel in 2018, an endorsement almost no other VPN protocol has received.
The next shift: from VPN to Zero Trust
Every protocol generation up to this point solved how to build a better tunnel. The most recent shift questions the tunnel model itself: a classic VPN grants broad access to an entire private network once a user authenticates, which means a single compromised laptop or stolen credential can move laterally across everything that network reaches - a weakness behind a long list of major breaches.
NIST's 2020 Zero Trust Architecture framework (SP 800-207) reframes the problem: instead of one strong perimeter check followed by implicit trust, verify every single request independently, regardless of whether it originates 'inside' or 'outside' any tunnel. Zero Trust Network Access (ZTNA) and Secure Access Service Edge (SASE) platforms implement that model in practice, granting access per application rather than to the whole network - not a replacement for the encryption VPNs pioneered, but a fundamentally different answer to the access-control question a VPN alone was never actually designed to solve.
Em resumo
Encryption strength was never really the bottleneck in this history - AES has been considered sound for decades. What actually changed, generation after generation, was operational reality: making tunnels traverse real-world firewalls and NAT (SSL VPN, OpenVPN), making reconnection survivable on flaky mobile networks (IKEv2), making the whole implementation small enough to actually audit (WireGuard), and finally questioning whether 'inside the tunnel' should ever again mean 'implicitly trusted' (Zero Trust). Each generation is a direct answer to the previous one's most painful real-world limitation, not a purely academic improvement.
Seu endereço IP público e localização de rede, detectados automaticamente.
Carrega automaticamente ao abrir o NetChecks — não é necessário inserir nada. Use o botão Atualizar após trocar de rede ou reconectar a VPN.
Seu navegador
Verificação tudo-em-um
Executa todas as verificações relevantes em um IP ou nome de host em uma única passagem: DNS, whois, ping, traceroute, uma varredura de portas conhecidas (1-1024), cabeçalhos HTTP e o certificado SSL.
Insira um domínio ou endereço IP e execute para verificar DNS, whois, ping, traceroute, portas comuns, cabeçalhos HTTP e o certificado SSL de uma só vez.
A maioria das verificações é executada em paralelo - normalmente termina em cerca de 30 segundos, mais se o alvo for lento ou inacessível.
A etapa de varredura de portas só é executada quando a caixa de consentimento acima estiver marcada - todas as outras verificações são executadas de qualquer forma.
Ping
Envia solicitações ICMP echo a um host para verificar sua acessibilidade e latência.
Insira um nome de host ou endereço IP e clique em Ping para enviar solicitações ICMP echo e medir a latência de ida e volta.
Saiba mais sobre Ping
O que é
O Ping envia pacotes ICMP Echo Request a um host e mede quanto tempo demoram a voltar os pacotes ICMP Echo Reply. É o teste de conectividade de rede mais básico que existe: responde exatamente a uma pergunta, "esta máquina está acessível, e com que rapidez?". O protocolo ICMP (RFC 792) foi concebido em 1981 especificamente para transportar mensagens de controlo e diagnóstico em redes IP, à margem de qualquer tráfego de aplicação - o Ping é a sua implementação mais conhecida e universalmente disponível, presente praticamente em todos os sistemas operativos e dispositivos de rede desde as suas primeiras versões.
Como funciona
Cada pacote ICMP transporta um campo TTL (Time To Live) que é decrementado em um em cada router que atravessa; se chegar a zero antes de alcançar o destino, o pacote é descartado e um erro é enviado de volta ao remetente. O tempo de ida e volta (RTT), medido em milissegundos, reflete a latência de rede acumulada ao longo de todo o trajeto, não apenas a última etapa junto ao destino - um ponto muitas vezes mal interpretado, já que um resultado de ping lento pode ter a sua causa em qualquer ponto do trajeto, não necessariamente junto ao servidor testado. Um ping normalmente envia vários pacotes seguidos em vez de apenas um, o que permite distinguir um pico de latência pontual de um problema recorrente e calcular uma taxa de perda de pacotes sobre a amostra.
Interpretar os resultados
Um RTT baixo e estável - alguns milissegundos numa rede local, entre 10 e 50 ms para um destino dentro do mesmo país, e notavelmente mais para uma ligação intercontinental - indica uma ligação saudável. Mesmo uma pequena perda de pacotes (acima de 1-2%) é particularmente prejudicial para usos sensíveis à latência, como VoIP ou sessões remotas interativas, onde cada pacote perdido se manifesta como um corte ou uma falha audível. Uma latência muito variável de um pacote para o outro (jitter) é frequentemente, para estes mesmos usos, mais problemática do que uma latência elevada mas perfeitamente estável. "Tempo limite excedido" significa que não chegou nenhuma resposta dentro do prazo previsto - o host pode estar realmente em baixo, uma firewall pode estar a bloquear silenciosamente o ICMP, ou pode haver uma rota quebrada algures no trajeto; "Destino inacessível" é diferente e mais informativo: um router intermédio enviou explicitamente uma mensagem a dizer que não conseguiu reencaminhar o pacote, o que ajuda a delimitar onde está realmente o problema.
Erros comuns
O erro de interpretação mais comum é concluir que um host está "em baixo" assim que um ping falha, quando na verdade muitos servidores e dispositivos - especialmente atrás de uma firewall bem configurada, ou alojados em grandes fornecedores cloud - bloqueiam deliberadamente o ICMP de entrada por política, estando totalmente operacionais e acessíveis nos seus serviços reais (HTTP, uma base de dados, etc.). A ausência de resposta a um ping só é uma evidência significativa de indisponibilidade quando combinada com outros sinais, como a própria aplicação também não responder. Inversamente, um ping bem-sucedido não garante de forma alguma que o serviço de aplicação alojado nessa máquina esteja a funcionar corretamente - são duas camadas da pilha de rede totalmente independentes.
Quando usar
A primeira coisa a verificar antes de escalar um ticket: a máquina sequer responde, antes de investigar mais a fundo? Confirmar a conectividade após uma alteração de regra de firewall ou de tabela de encaminhamento, para garantir que a alteração não quebrou o acesso. Estabelecer uma medição de latência de referência antes de um lançamento de VoIP ou de um failover de ligação de operadora, para haver um ponto de comparação objetivo se surgirem queixas sobre a qualidade das chamadas mais tarde. Uma verificação de estado periódica e leve para um MSP que monitoriza vários sites de clientes em paralelo, sempre como complemento - nunca como substituto - de uma monitorização mais profunda ao nível da aplicação.
Traceroute
Rastreia o caminho de rede (salto a salto) até um host de destino.
Insira um nome de host ou endereço IP e execute para ver cada salto de rede entre este servidor e o destino, com a latência de cada salto.
Insira um domínio, escolha um tipo de registro (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV ou CAA) e faça a consulta.
Whois
Consulta as informações de registro de um domínio ou endereço IP.
Insira um domínio ou endereço IP para consultar seus dados de registro: registrador, organização proprietária e datas importantes.
Verificação de lista negra
Verifica se um endereço IP ou domínio está listado em listas negras públicas de spam/abuso (DNSBL).
Insira um endereço IPv4 ou domínio e execute para verificar 7 listas negras (DNSBL/RBL) públicas de uma vez - cada uma aparece como listada, não listada ou falha na verificação.
Varredura de portas TCP
Verifica se as portas TCP estão abertas em um host ou IP: portas comuns, uma lista personalizada, ou o intervalo completo 1-65535.
Insira um host ou IP, escolha portas comuns, uma lista personalizada ou o intervalo completo, e escaneie para ver quais portas TCP respondem.
Uma varredura completa pode levar até ~100 segundos. Varreduras grandes (mais de 100 portas, incluindo intervalos/listas personalizados) são limitadas a 1 por minuto por visitante.
Portas abertas (0)
Inspetor de cabeçalhos HTTP
Obtém o status da resposta HTTP e os cabeçalhos de uma URL.
Insira uma URL para obter seu código de status HTTP e todos os cabeçalhos de resposta enviados pelo servidor.
Verificador de certificado SSL / TLS
Inspeciona o certificado TLS de um host: emissor, datas de validade e dias restantes.
Insira um nome de host para inspecionar seu certificado TLS: emissor, datas de validade e dias restantes até expirar.
Geolocalização de IP
Consulta a localização geográfica e as informações de rede de um endereço IP. Deixe em branco para consultar seu próprio IP público.
Insira qualquer endereço IP, ou deixe em branco para consultar o seu, para ver sua localização aproximada e informações de rede/ISP.
Calculado inteiramente no seu navegador — nenhum dado é enviado ao servidor.
Insira um endereço IP e um prefixo CIDR (ex.: 192.168.1.0/24) para calcular instantaneamente o intervalo de rede, o endereço de broadcast e o número de hosts utilizáveis.
Teste de velocidade
Teste básico de velocidade de download/upload em relação a este servidor (a precisão depende da própria conexão do servidor).
Clique em Iniciar para medir a velocidade de download e upload em relação a este servidor. A precisão depende da própria conexão deste servidor.
Dicionário de códigos de país
Códigos de país ISO 3166-1 alfa-2 — pesquisa feita inteiramente no seu navegador.
Pesquise ou navegue pela lista de códigos de país ISO 3166-1 alfa-2, consultada inteiramente no seu navegador.
País
Código ISO
Dicionário de códigos telefônicos
Códigos de discagem internacional por país — pesquisa feita inteiramente no seu navegador.
Pesquise ou navegue pelos códigos telefônicos internacionais por país, consultados inteiramente no seu navegador.
País
Código
Relógio mundial
Escolha um fuso horário para ver a hora atual — arraste o globo para girá-lo.
Escolha um fuso horário na lista, ou arraste o globo, para ver a hora atual nesse local.
Sua hora
--:--:--
—
—
Hora selecionada
--:--:--
—
—UTC±00:00
Diferenca em relacao a voce—
—
Arraste para girar o globo.
Estado da rede móvel na França
Antenas móveis fora de serviço ou em manutenção na França, por operadora (Orange, Free, SFR, Bouygues Telecom), com base em dados públicos da Arcep. Instantâneo atualizado uma vez por dia - não é um fluxo em tempo real.
Consulte os dados de falhas de antenas móveis e fibra por operadora francesa — nenhuma entrada necessária, atualizado automaticamente a partir dos dados públicos da Arcep.
Fonte: Arcep, conjunto de dados «Sites indisponibles», publicado sob Licença Aberta / Etalab 2.0 - reutilização comercial explicitamente permitida, ao contrário dos dados IODA/CAIDA usados antes. O selo Normal/Vigilância/Alerta é uma estimativa própria (falhas de hoje vs. mediana dos dias anteriores), não uma classificação oficial da Arcep. Links de origem abaixo.
Departamentos mais afetados
Número de sites atualmente fora de serviço ou em manutenção, por departamento. Clique num operador acima para filtrar.
Qualidade da rede de fibra (FTTH) por operadora: taxa de falhas reportadas e taxa de falhas de ligação, com base em dados públicos da Arcep. Indicadores mensais, média móvel de 6 meses - não é um fluxo em tempo real como a secção móvel.
Fonte: Arcep, conjunto de dados «Qualité des réseaux en fibre optique», publicado sob Licença Aberta / Etalab 2.0 - reutilização comercial explicitamente permitida. Links de origem abaixo.
Por operadora (grupo controlador)
Médias dos últimos 6 meses disponíveis, por grupo controlador do operador de infraestrutura.
O NetChecks é fornecido apenas para fins de diagnóstico de rede legítimo e educacionais, em sistemas, domínios e endereços IP que você possui ou está explicitamente autorizado a testar.
Executar varreduras de portas, consultas DNS/whois, traceroutes ou outras verificações contra sistemas de terceiros sem autorização pode violar as leis de uso indevido de computadores da sua jurisdição (por exemplo, o Computer Fraud and Abuse Act nos EUA, a "Loi Godfrain" na França, ou legislação local equivalente). Você é o único responsável por garantir que tem o direito de testar qualquer alvo que inserir aqui.
Este site e seus resultados são fornecidos "como estão", sem garantia de qualquer tipo. O operador deste site não aceita nenhuma responsabilidade por quaisquer danos diretos, indiretos ou consequenciais, consequências legais ou uso indevido decorrentes do uso deste site.
As solicitações têm limite de frequência para evitar abusos. O operador desta instância pode ativar opcionalmente o registro de atividade de solicitações - nesse caso, cada solicitação de ferramenta (seu endereço IP, carimbo de data/hora, a ferramenta usada e o alvo/consulta inserido) pode ser registrada em um banco de dados para fins de segurança, prevenção de abusos e análise de uso; isso está desativado por padrão. Ao usar este site, você concorda com estes termos; se não concordar, não o utilize.
O uso programático (API) deste site está sujeito a estes mesmos termos, incluindo o requisito de autorização acima.
Enviar feedback
Relate um problema, deixe um comentário ou sugira um novo recurso.
Este site exibe anúncios e, se você aceitar, cookies de parceiros publicitários para ajudar a financiar a hospedagem. Você pode recusar e continuar usando todas as ferramentas sem anúncios.