diff options
Diffstat (limited to 'pt-br/news/phase4-nat-traversal')
| -rw-r--r-- | pt-br/news/phase4-nat-traversal/index.html | 238 | ||||
| -rw-r--r-- | pt-br/news/phase4-nat-traversal/index.html.gz | bin | 5590 -> 0 bytes |
2 files changed, 0 insertions, 238 deletions
diff --git a/pt-br/news/phase4-nat-traversal/index.html b/pt-br/news/phase4-nat-traversal/index.html deleted file mode 100644 index 6b43a65..0000000 --- a/pt-br/news/phase4-nat-traversal/index.html +++ /dev/null @@ -1,238 +0,0 @@ -<!DOCTYPE html> -<html lang="pt-br"> -<head> - <meta charset="utf-8"> - <meta name="viewport" content="width=device-width, initial-scale=1"> - <title>Fase 4: Furando NATs — Tesseras</title> - <meta name="description" content="Os nos Tesseras agora podem descobrir seu tipo de NAT via STUN, coordenar UDP hole punching atraves de introdutores e usar relay transparente quando a conectividade direta falha."> - <!-- Open Graph --> - <meta property="og:type" content="article"> - <meta property="og:title" content="Fase 4: Furando NATs"> - <meta property="og:description" content="Os nos Tesseras agora podem descobrir seu tipo de NAT via STUN, coordenar UDP hole punching atraves de introdutores e usar relay transparente quando a conectividade direta falha."> - <meta property="og:image" content="https://tesseras.net/images/social.jpg"> - <meta property="og:image:width" content="1200"> - <meta property="og:image:height" content="630"> - <meta property="og:site_name" content="Tesseras"> - <!-- Twitter Card --> - <meta name="twitter:card" content="summary_large_image"> - <meta name="twitter:title" content="Fase 4: Furando NATs"> - <meta name="twitter:description" content="Os nos Tesseras agora podem descobrir seu tipo de NAT via STUN, coordenar UDP hole punching atraves de introdutores e usar relay transparente quando a conectividade direta falha."> - <meta name="twitter:image" content="https://tesseras.net/images/social.jpg"> - <link rel="stylesheet" href="https://tesseras.net/style.css?h=21f0f32121928ee5c690"> - - - <link rel="alternate" type="application/atom+xml" title="Tesseras" href="https://tesseras.net/atom.xml"> - - - <link rel="icon" type="image/png" sizes="32x32" href="https://tesseras.net/images/favicon.png?h=be4e123a23393b1a027d"> - -</head> -<body> - <header> - <h1> - <a href="https://tesseras.net/pt-br/"> - <img src="https://tesseras.net/images/logo-64.png?h=c1b8d0c4c5f93b49d40b" alt="Tesseras" width="40" height="40" class="logo"> - Tesseras - </a> - </h1> - <nav> - - <a href="https://tesseras.net/pt-br/about/">Sobre</a> - <a href="https://tesseras.net/pt-br/news/">Notícias</a> - <a href="https://tesseras.net/pt-br/releases/">Lançamentos</a> - <a href="https://tesseras.net/pt-br/faq/">FAQ</a> - <a href="https://tesseras.net/pt-br/subscriptions/">Inscrições</a> - <a href="https://tesseras.net/pt-br/contact/">Contato</a> - - </nav> - <nav class="lang-switch"> - - <a href="https://tesseras.net/news/phase4-nat-traversal/">English</a> | <strong>Português</strong> - - </nav> - </header> - - <main> - -<article> - <h2>Fase 4: Furando NATs</h2> - <p class="news-date">2026-02-15</p> - <p>A maioria dos dispositivos das pessoas ficam atras de um NAT — um tradutor de -enderecos de rede que permite acessar a internet mas impede conexoes de entrada. -Para uma rede P2P, isso e um problema existencial: se dois nos atras de NATs nao -conseguem se comunicar, a rede se fragmenta. A Fase 4 continua com uma pilha -completa de travessia de NAT: descoberta via STUN, hole punching coordenado e -fallback por relay.</p> -<p>A abordagem segue o mesmo padrao da maioria dos sistemas P2P consolidados -(WebRTC, BitTorrent, IPFS): tente a opcao mais barata primeiro, escale apenas -quando necessario. Conectividade direta nao custa nada. Hole punching custa -alguns pacotes coordenados. Relay custa largura de banda sustentada de um -terceiro. Tesseras tenta nessa ordem.</p> -<h2 id="o-que-foi-construido">O que foi construido</h2> -<p><strong>Classificacao NatType</strong> (<code>tesseras-core/src/network.rs</code>) — Um novo enum -<code>NatType</code> (Public, Cone, Symmetric, Unknown) adicionado a camada de dominio -core. Esse tipo e compartilhado por toda a pilha: o cliente STUN o escreve, o -DHT o divulga em mensagens Pong, e o coordenador de punch o le para decidir se -hole punching vale a pena tentar (Cone-para-Cone funciona ~80% das vezes; -Symmetric-para-Symmetric quase nunca funciona).</p> -<p><strong>Cliente STUN</strong> (<code>tesseras-net/src/stun.rs</code>) — Uma implementacao STUN minima -(RFC 5389 Binding Request/Response) que descobre o endereco externo de um no. O -codec codifica requisicoes de 20 bytes com um ID de transacao aleatorio e -decodifica respostas XOR-MAPPED-ADDRESS. A funcao <code>discover_nat()</code> consulta -multiplos servidores STUN em paralelo (Google, Cloudflare por padrao), compara -os enderecos mapeados e classifica o tipo de NAT:</p> -<ul> -<li>Mesmo IP e porta de todos os servidores → <strong>Public</strong> (sem NAT)</li> -<li>Mesmo endereco mapeado de todos os servidores → <strong>Cone</strong> (hole punching -funciona)</li> -<li>Enderecos mapeados diferentes → <strong>Symmetric</strong> (hole punching nao confiavel)</li> -<li>Sem respostas → <strong>Unknown</strong></li> -</ul> -<p>Retentativas com backoff exponencial e timeouts configuraveis. 12 testes -cobrindo roundtrips de codec, todos os caminhos de classificacao e consultas -async em loopback.</p> -<p><strong>Coordenacao de punch assinada</strong> (<code>tesseras-net/src/punch.rs</code>) — Assinatura e -verificacao Ed25519 para mensagens <code>PunchIntro</code>, <code>RelayRequest</code> e -<code>RelayMigrate</code>. Cada introducao e assinada pelo iniciador com uma janela de -timestamp de 30 segundos, prevenindo ataques de reflexao (onde um atacante -reproduz uma introducao antiga para redirecionar trafego). O formato do payload -e <code>target || external_addr || timestamp</code> — alterar qualquer campo invalida a -assinatura. 6 testes unitarios mais 3 testes baseados em propriedades com -proptest (IDs de no, portas e tokens de sessao arbitrarios).</p> -<p><strong>Gerenciador de sessoes de relay</strong> (<code>tesseras-net/src/relay.rs</code>) — Gerencia -sessoes de relay UDP transparente entre nos com NAT. Cada sessao tem um token -aleatorio de 16 bytes; os nos prefixam seus pacotes com o token, o relay remove -e encaminha. Funcionalidades:</p> -<ul> -<li>Encaminhamento bidirecional (A→R→B e B→R→A)</li> -<li>Limite de taxa: 256 KB/s para nos reciprocos, 64 KB/s para nao reciprocos</li> -<li>Duracao maxima de 10 minutos para sessoes bootstrap (nao reciprocas)</li> -<li>Migracao de endereco: quando o IP de um no muda (Wi-Fi para celular), um -<code>RelayMigrate</code> assinado atualiza a sessao sem derruba-la</li> -<li>Limpeza por inatividade com timeout configuravel</li> -<li>8 testes unitarios mais 2 testes baseados em propriedades</li> -</ul> -<p><strong>Extensoes de mensagens DHT</strong> (<code>tesseras-dht/src/message.rs</code>) — Sete novas -variantes de mensagem adicionadas ao protocolo DHT:</p> -<table><thead><tr><th>Mensagem</th><th>Proposito</th></tr></thead><tbody> -<tr><td><code>PunchIntro</code></td><td>"Quero conectar ao no X, aqui esta meu endereco externo assinado"</td></tr> -<tr><td><code>PunchRequest</code></td><td>O introdutor encaminha a requisicao ao destino</td></tr> -<tr><td><code>PunchReady</code></td><td>O destino confirma prontidao, envia seu endereco externo</td></tr> -<tr><td><code>RelayRequest</code></td><td>"Crie uma sessao de relay para o no X"</td></tr> -<tr><td><code>RelayOffer</code></td><td>O relay responde com seu endereco e token de sessao</td></tr> -<tr><td><code>RelayClose</code></td><td>Encerrar uma sessao de relay</td></tr> -<tr><td><code>RelayMigrate</code></td><td>Atualizar sessao apos mudanca de rede</td></tr> -</tbody></table> -<p>A mensagem <code>Pong</code> foi estendida com metadados NAT: <code>nat_type</code>, -<code>relay_slots_available</code> e <code>relay_bandwidth_used_kbps</code>. Todos os novos campos -usam <code>#[serde(default)]</code> para compatibilidade retroativa — nos antigos ignoram o -que nao reconhecem, nos novos usam defaults. 9 novos testes de roundtrip de -serializacao.</p> -<p><strong>Trait NatHandler e dispatch</strong> (<code>tesseras-dht/src/engine.rs</code>) — Uma nova trait -async <code>NatHandler</code> (5 metodos) injetada no engine DHT, seguindo o mesmo padrao -de injecao de dependencia do <code>ReplicationHandler</code> existente. O loop de dispatch -de mensagens do engine agora roteia todas as mensagens punch/relay para o -handler. Isso mantem o engine DHT agnóstico ao protocolo enquanto permite que a -logica de travessia de NAT viva em <code>tesseras-net</code>.</p> -<p><strong>Tipos de reconexao mobile</strong> (<code>tesseras-embedded/src/reconnect.rs</code>) — Uma -maquina de estados de reconexao em tres fases para dispositivos moveis:</p> -<ol> -<li><strong>QuicMigration</strong> (0-2s) — tenta migracao de conexao QUIC para todos os peers -ativos</li> -<li><strong>ReStun</strong> (2-5s) — redescobre endereco externo via STUN</li> -<li><strong>ReEstablish</strong> (5-10s) — reconecta peers que a migracao nao conseguiu salvar</li> -</ol> -<p>Peers sao reconectados em ordem de prioridade: nos bootstrap primeiro, depois -nos que guardam nossos fragmentos, depois nos cujos fragmentos guardamos, depois -vizinhos DHT gerais. Uma nova variante de evento <code>NetworkChanged</code> foi adicionada -ao stream de eventos FFI para que o app Flutter possa mostrar progresso de -reconexao.</p> -<p><strong>Configuracao NAT do daemon</strong> (<code>tesd/src/config.rs</code>) — Uma nova secao <code>[nat]</code> -na configuracao TOML com lista de servidores STUN, toggle de relay, maximo de -sessoes relay, limites de largura de banda (reciproco vs bootstrap) e timeout de -inatividade. Todos os campos tem defaults sensiveis; relay e desabilitado por -padrao.</p> -<p><strong>Metricas Prometheus</strong> (<code>tesseras-net/src/metrics.rs</code>) — 16 metricas em quatro -subsistemas:</p> -<ul> -<li><strong>STUN</strong>: requisicoes, falhas, histograma de latencia</li> -<li><strong>Punch</strong>: tentativas/sucessos/falhas (por par de tipo NAT), histograma de -latencia</li> -<li><strong>Relay</strong>: sessoes ativas, sessoes totais, bytes encaminhados, timeouts por -inatividade, hits de rate limit</li> -<li><strong>Reconexao</strong>: mudancas de rede, tentativas/sucessos por fase, histograma de -duracao</li> -</ul> -<p>6 testes verificando registro, incremento, cardinalidade de labels e deteccao de -registro duplo.</p> -<p><strong>Testes de integracao</strong> — Dois testes end-to-end usando <code>MemTransport</code> (rede -simulada em memoria):</p> -<ul> -<li><code>punch_integration.rs</code> — Fluxo completo de hole-punch com 3 nos: A envia -<code>PunchIntro</code> assinado ao introdutor I, I verifica e encaminha <code>PunchRequest</code> a -B, B verifica a assinatura original e envia <code>PunchReady</code> de volta, A e B -trocam mensagens diretamente. Tambem testa que uma assinatura invalida e -corretamente rejeitada.</li> -<li><code>relay_integration.rs</code> — Fluxo completo de relay com 3 nos: A solicita relay -de R, R cria sessao e envia <code>RelayOffer</code> a ambos os peers, A e B trocam -pacotes prefixados com token atraves de R, A migra para um novo endereco no -meio da sessao, A fecha a sessao, e o teste verifica que a sessao e encerrada -e encaminhamento posterior falha.</li> -</ul> -<p><strong>Testes de propriedade</strong> — 7 testes baseados em proptest cobrindo: roundtrips -de assinatura para todos os tres tipos de mensagem assinada (IDs de no, portas e -tokens arbitrarios), determinismo de classificacao NAT (mesmas entradas sempre -produzem mesma saida), validade de binding request STUN, unicidade de tokens de -sessao, e rejeicao de pacotes curtos pelo relay.</p> -<p><strong>Alvos Justfile</strong> — <code>just test-nat</code> executa todos os testes de travessia NAT em -<code>tesseras-net</code> e <code>tesseras-dht</code>. <code>just test-chaos</code> e um placeholder para futuros -testes de caos com Docker Compose e <code>tc netem</code>.</p> -<h2 id="decisoes-de-arquitetura">Decisoes de arquitetura</h2> -<ul> -<li><strong>STUN ao inves de TURN</strong>: implementamos STUN (descoberta) e relay customizado -ao inves de TURN completo. TURN requer alocacao autenticada e foi projetado -para relay de midia; nosso relay e mais simples — encaminhamento UDP com -prefixo de token e limites de taxa. Isso mantem o protocolo minimo e evita -depender de servidores TURN externos.</li> -<li><strong>Assinaturas em introducoes</strong>: cada <code>PunchIntro</code> e assinado pelo iniciador. -Sem isso, um atacante poderia enviar introducoes forjadas para redirecionar as -tentativas de hole-punch de um no para um endereco controlado pelo atacante -(ataque de reflexao). A janela de timestamp de 30 segundos limita replay.</li> -<li><strong>Tiers reciprocos de largura de banda</strong>: nos relay dao 4x mais largura de -banda (256 vs 64 KB/s) para peers com boas pontuacoes de reciprocidade. Isso -incentiva nos a armazenar fragmentos para outros — se voce contribui, recebe -melhor servico de relay quando precisa.</li> -<li><strong>Extensao Pong retrocompativel</strong>: novos campos NAT em <code>Pong</code> usam -<code>#[serde(default)]</code> e <code>Option<T></code>. Nos antigos que nao entendem esses campos -simplesmente os pulam durante deserializacao. Nenhum bump de versao de -protocolo necessario.</li> -<li><strong>NatHandler como trait async</strong>: a logica de travessia NAT e injetada no -engine DHT via trait, assim como <code>ReplicationHandler</code>. Isso mantem o engine -DHT focado em roteamento e gerenciamento de peers, e permite que a -implementacao NAT seja trocada ou desabilitada sem tocar no codigo core do -DHT.</li> -</ul> -<h2 id="o-que-vem-a-seguir">O que vem a seguir</h2> -<ul> -<li><strong>Fase 4 continuacao</strong> — tuning de performance (pooling de conexoes, cache de -fragmentos, SQLite WAL), auditorias de seguranca, onboarding de nos -institucionais, empacotamento para OS</li> -<li><strong>Fase 5: Exploracao e Cultura</strong> — navegador publico de tesseras por -era/localizacao/tema/idioma, curadoria institucional, integracao genealogica, -exportacao para midia fisica (M-DISC, microfilme, papel livre de acido com QR)</li> -</ul> -<p>Com travessia de NAT, Tesseras pode conectar nos independentemente de sua -topologia de rede. Nos publicos conversam diretamente. Nos com NAT Cone furam -com ajuda de um introdutor. Nos com NAT Symmetric ou firewalled usam relay -atraves de peers voluntarios. A rede se adapta ao mundo real, onde a maioria dos -dispositivos esta atras de um NAT e as condicoes de rede mudam constantemente.</p> - -</article> - - </main> - - <footer> - <p>© 2026 Tesseras Project. <a href="/atom.xml">News Feed</a> · <a href="https://git.sr.ht/~ijanc/tesseras">Source</a></p> - </footer> -</body> -</html> diff --git a/pt-br/news/phase4-nat-traversal/index.html.gz b/pt-br/news/phase4-nat-traversal/index.html.gz Binary files differdeleted file mode 100644 index 6aa4bc7..0000000 --- a/pt-br/news/phase4-nat-traversal/index.html.gz +++ /dev/null |