Redigir um registo de VPN sem perder as pistas que importam

Colas um registo num fio de suporte, uma resposta aponta que contém a tua chave privada, e a colagem é permanente. A falha mais silenciosa aparece mais tarde, quando cada endereço se tornou X e o ficheiro já não prova que o cliente e o servidor eram anfitriões diferentes. Uma passagem de redação remove o que concede acesso ou nomeia uma pessoa, e mantém o que explica a falha. É uma transformação com regras, não uma eliminação com uma caixa de pesquisa.

A redação é uma transformação, não uma eliminação

Um registo transporta estrutura além de valores: este endereço falou com aquele, a esta hora, e o handshake parou neste passo. Os valores são o que torna o ficheiro perigoso de publicar. A estrutura é o que o torna digno de publicação.

Eliminar linhas inteiras remove ambas as coisas de uma vez, e é por isso que um registo cortado muitas vezes não responde a nada. Reduzir cada valor a um único token falha de outra maneira, porque dois pares distintos passam a ser um único ator. Ambas as passagens podem parecer arrumadas e ainda assim destruir a prova. O teste é saber se um leitor que nunca viu a tua rede consegue seguir a sequência e chegar à conclusão a que chegaste.

Primeiro o extrato, depois a limpeza

Corta a secção em torno da falha antes de editar seja o que for. Um extrato mais pequeno é mais fácil de inspecionar, e é menos provável que transporte algo que tinhas esquecido estar no ficheiro. Guarda o original intacto em armazenamento protegido até o caso ser encerrado. A redação é com perdas, e o ficheiro em bruto é a única forma de responder à pergunta seguinte.

Lê o extrato como texto simples antes de confiar que um comando de exportação removeu as partes privadas, porque os exportadores resumem e rodam campos em vez de os sanear. Os modos de depuração e detalhado são o local mais provável para um bloco de chave ou uma credencial incorporada. Abre o ficheiro num editor que mostre linhas completas, não num visualizador que quebra e esconde a cauda.

O que tem de sair, e por que ordem

Começa pelo material que concede acesso, porque uma falha aí encerra o exercício: blocos de chave privada, palavras-passe, chaves pré-partilhadas, tokens de API, códigos de recuperação. Não são apenas identificadores; são utilizáveis por quem ler o fio. Uma passagem que remova tudo o resto e deixe um deles falhou.

Depois a camada de identidade: nomes de utilizador, sujeitos e números de série de certificados, identificadores de conta e qualquer caminho que contenha o nome de uma pessoa. Nada disso é utilizável sozinho, mas em conjunto nomeia uma pessoa, e essa é a parte de que um fio público não precisa.

Depois a camada de topologia, e é aí que entra o julgamento. Os endereços públicos, os intervalos internos e os nomes de anfitrião podem todos ser substituídos quando a sua divulgação não serve nenhum propósito de diagnóstico, e etiquetas estáveis valem mais do que espaços em branco. A ordem importa porque as camadas anteriores são absolutas e a última é uma decisão. Trabalhar nessa ordem também te impede de passar uma hora com nomes de anfitrião enquanto um bloco de chave está na linha quarenta.

Não destruas as relações

Dá a cada valor real um único marcador e reutiliza-o sempre que esse valor aparecer. Se dois endereços eram diferentes, têm de continuar diferentes depois da passagem, senão o leitor concluirá que o cliente se ligou a si mesmo. A consistência é todo o mecanismo: o leitor aprende a correspondência ao ver uma etiqueta a repetir-se. Um único token reutilizado para dois atores é a forma mais rápida de tornar um registo ilegível.

A ordem e o tempo fazem parte da mesma estrutura. Mantém a sequência intacta, e se deslocares marcas temporais, desloca todas na mesma quantidade e di-lo numa linha. Misturar horas alteradas e reais é pior do que removê-las, porque então os intervalos parecem prova de algo que nunca aconteceu.

As portas, o protocolo e o sentido ficam como estão. Um marcador no endereço não exige um marcador na porta.

Mantém a pergunta a que o registo tem de responder

Anota os campos de que quem ajuda precisa antes de começares a editar: o texto exato do erro que não é secreto, as versões de cliente e servidor, o transporte e que lado iniciou a tentativa. São eles que permitem a um estranho reconhecer a falha. Ter a lista ao lado transforma a passagem numa verificação em vez de uma esperança.

Quando enviares o ficheiro, acrescenta uma linha a dizer o que foi substituído, para que ninguém passe uma hora a diagnosticar um nome de anfitrião de preenchimento. A documentação sobre registos de diagnóstico da OpenVPN lista os campos que os seus registos transportam, e é a lista que estás prestes a alterar. Pergunta antes de enviares um despejo de memória ou uma captura de pacotes, e usa o canal de suporte que consigas verificar. Esses artefactos contêm muito mais do que o registo de texto, e parte disso não é teu para publicar.

Lê o extrato terminado uma vez da primeira à última linha, incluindo o início e o fim. As capturas de ecrã merecem mais desconfiança do que o texto, porque transportam outras janelas, nomes de conta e itens de menu.