Travessia de NAT
-A maioria dos dispositivos na internet ficam atras de um NAT (Network Address Translator). Seu roteador atribui ao seu dispositivo um endereco privado (como 192.168.1.100) e o traduz para um endereco publico quando voce conecta para fora. Isso funciona bem para navegar na web, mas cria um problema para redes P2P: dois dispositivos atras de NATs diferentes nao conseguem se conectar diretamente sem ajuda.
Tesseras resolve isso com uma abordagem em tres camadas, tentando a opcao mais barata primeiro:
--
-
- Conexao direta — se ambos os nos tem IPs publicos, eles conectam diretamente -
- UDP hole punching — um terceiro no apresenta os dois peers para que eles possam furar seus NATs -
- Relay — um no com IP publico encaminha pacotes entre os dois peers -
Descoberta do tipo de NAT
-Quando um no inicia, ele envia requisicoes STUN (Session Traversal Utilities for NAT) para multiplos servidores publicos. Comparando os enderecos externos que esses servidores reportam, o no classifica seu NAT:
-| Tipo de NAT | O que significa | Hole punching? |
|---|---|---|
| Public | Sem NAT — seu dispositivo tem IP publico | Nao necessario |
| Cone | NAT mapeia a mesma porta interna para a mesma porta externa independente do destino | Funciona bem (~80%) |
| Symmetric | NAT atribui uma porta externa diferente para cada destino | Nao confiavel |
| Unknown | Nao conseguiu alcancar servidores STUN | Relay necessario |
Seu no divulga seu tipo de NAT em mensagens Pong do DHT, para que outros nos saibam se hole punching vale a pena tentar.
-Hole punching
-Quando o no A (atras de um NAT Cone) quer conectar ao no B (tambem atras de um NAT Cone), nenhum consegue alcancar o outro diretamente. A solucao:
--
-
-
-
A envia uma mensagem PunchIntro ao no I (um introdutor — qualquer no com IP publico que ambos conhecam). A mensagem inclui o endereco externo de A (do STUN) e uma assinatura Ed25519 provando a identidade de A.
-
- -
-
I verifica a assinatura e encaminha um PunchRequest a B, incluindo o endereco de A e a assinatura original.
-
- -
-
B verifica a assinatura (provando que a requisicao realmente veio de A, nao de uma fonte falsificada). B entao envia um pacote UDP para o endereco externo de A — isso abre um pinhole no NAT de B. B tambem envia uma mensagem PunchReady de volta a A com o endereco externo de B.
-
- -
-
A envia um pacote UDP para o endereco externo de B. Ambos os NATs agora tem pinholes, e os dois nos podem se comunicar diretamente.
-
-
O processo inteiro leva 2-5 segundos. As assinaturas Ed25519 previnem ataques de reflexao, onde um atacante reproduz uma introducao antiga para redirecionar trafego.
-Fallback por relay
-Quando hole punching falha (NAT Symmetric, firewalls estritos ou redes corporativas), nos usam relay atraves de um no com IP publico:
--
-
- A envia um RelayRequest ao no R (um no com IP publico com relay habilitado). -
- R cria uma sessao e envia um RelayOffer a ambos A e B, contendo o endereco do relay e um token de sessao. -
- A e B enviam seus pacotes a R, prefixados com o token de sessao. R remove o token e encaminha o payload ao outro peer. -
Sessoes de relay tem limites de largura de banda:
--
-
- 256 KB/s para peers com boa reciprocidade (eles armazenam fragmentos para outros) -
- 64 KB/s para peers sem reciprocidade -
- Sessoes nao reciprocas sao limitadas a 10 minutos -
Isso incentiva nos a contribuir armazenamento — bons cidadaos da rede recebem melhor servico de relay.
-Migracao de endereco
-Quando um dispositivo movel troca de rede (Wi-Fi para celular), seu endereco IP muda. Ao inves de encerrar e reconstruir sessoes de relay, o no envia uma mensagem RelayMigrate assinada para atualizar seu endereco na sessao existente. Isso evita reestabelecer conexoes do zero.
-Configuracao
-A secao [nat] na configuracao do daemon controla a travessia de NAT:
[nat]
-# Servidores STUN para deteccao de tipo de NAT
-stun_servers = ["stun.l.google.com:19302", "stun.cloudflare.com:3478"]
-
-# Habilitar relay (encaminhar trafego para outros nos com NAT)
-relay_enabled = false
-
-# Maximo de sessoes de relay simultaneas
-relay_max_sessions = 50
-
-# Limite de largura de banda para peers reciprocos (KB/s)
-relay_reciprocal_kbps = 256
-
-# Limite de largura de banda para peers nao reciprocos (KB/s)
-relay_bootstrap_kbps = 64
-
-# Timeout de inatividade de sessao relay (segundos)
-relay_idle_timeout_secs = 60
-Para executar um no relay, defina relay_enabled = true. Seu no deve ter um IP publico (ou roteador com port forwarding) para servir como relay.
Reconexao mobile
-Quando o app Tesseras detecta uma mudanca de rede em um dispositivo movel, ele executa uma sequencia de reconexao em tres fases:
--
-
- Migracao QUIC (0-2s) — QUIC suporta migracao de conexao nativamente. O app tenta migrar todas as conexoes ativas para o novo endereco. -
- Re-STUN (2-5s) — descobre o novo endereco externo e re-anuncia ao DHT. -
- Reestabelecimento (5-10s) — reconecta peers que a migracao nao conseguiu salvar, em ordem de prioridade: nos bootstrap primeiro, depois nos que guardam seus fragmentos, depois nos cujos fragmentos voce guarda. -
O app mostra progresso de reconexao atraves do stream de eventos NetworkChanged.
Monitoramento
-A travessia de NAT expoe metricas Prometheus em /metrics:
-
-
tesseras_nat_type— tipo de NAT detectado atualmente
-tesseras_stun_requests_total/tesseras_stun_failures_total— confiabilidade STUN
-tesseras_punch_attempts_total{initiator_nat, target_nat}— taxa de sucesso de punch por par de NAT
-tesseras_relay_sessions_active— carga atual de relay
-tesseras_relay_bytes_forwarded— largura de banda total de relay
-tesseras_network_change_total— frequencia de mudanca de rede no mobile
-