Executar uma VPN e um site num único host sem colisões

Compartilhar um host entre um site público e uma VPN faz com que você herde duas perguntas, não uma: o que escuta onde e quem autentica quem. Responda às duas antes de tocar num arquivo de configuração, porque os valores predefinidos estão errados de formas que só aparecem sob carga. Uma página que carrega por HTTPS prova que o ouvinte web responde e nada sobre o ouvinte de pares. O que se segue é uma ordem de decisões que impede que os dois se devorem.

Decida o que escuta em qual endereço e transporte

Escreva uma tabela com três colunas, endereço, transporte e porta, e uma linha por serviço, incluindo a interface administrativa. TCP 443 para o site e UDP 443 para a VPN não são um conflito mesmo quando os números coincidem, porque o transporte é diferente. Dois serviços no mesmo endereço, transporte e porta precisam de um arranjo que a implementação documente, não de um que você invente durante uma queda. Essa tabela é também o artefato que torna a próxima mudança verificável.

Endereços separados ou uma segunda porta tornam a propriedade visível numa captura de pacotes, e isso vale mais do que elegância. Algumas implementações de VPN suportam compartilhar uma porta com um servidor web, mas o mecanismo é específico: o daemon inspeciona os primeiros bytes e encaminha o tráfego que não é o seu próprio protocolo. Um proxy reverso HTTP genérico não faz isso, e reescrever cabeçalhos não o fará entender um aperto de mão de túnel cifrado. Leia as notas de implantação do protocolo, como a documentação do ouvinte do OpenVPN, e siga o arranjo que ela descreve.

Decida qual identidade pertence a qual serviço

Um certificado de navegador e uma credencial de par de VPN são objetos diferentes com modelos de confiança diferentes. O certificado web é validado por uma autoridade pública e nomeia um nome de host, enquanto a credencial de par autentica um dispositivo ou um usuário perante o concentrador e pode ser autoassinada ou emitida internamente. Reutilizar um como o outro funciona em casos estreitos e raramente vale o acoplamento. Desativar a verificação para que um certificado compartilhado se ajuste não é um plano de separação; remove a verificação que dava sentido à credencial.

Mantenha os dois armazéns independentes e anote qual autoridade emite cada um. Quando um é rotacionado, o outro não deveria precisar de mudança, e se precisar, o acoplamento é o que há a corrigir.

Decida onde vive a administração

A interface administrativa da VPN pertence a um caminho de gestão, nunca ao ouvinte público, mesmo quando o host já serve a internet. Um servidor web na 443 não implica que o console de pares deva ser alcançável de qualquer lugar, e o console é habitualmente o alvo de maior valor. Ligue-a a um endereço de loopback ou de gestão, restrinja-a por origem e mantenha um caminho de recuperação que não dependa de o túnel estar de pé. O caminho de recuperação importa porque a falha comum é ficar trancado fora enquanto se corrige o bloqueio.

Escreva regras de firewall estreitas, uma por ouvinte, nomeando a interface ou a conta de serviço onde a plataforma o permitir. As regras amplas que abrem o host porque o site precisa da 443 são a forma como as interfaces administrativas acabam nos índices dos scanners.

Reveja essas regras contra a tabela de ouvintes sempre que um serviço é adicionado. A revisão é barata e apanha a regra que alguém acrescentou às duas da manhã.

Decida o que fazer quando os dois competem

Compartilhar um host significa compartilhar CPU, memória, descritores de arquivo e largura de banda, e o recurso disputado nem sempre é o óbvio. Um site ocupado pode encher a tabela de conexões, esgotar as vagas de trabalho ou empurrar a fila de disco o suficiente para o registro da VPN parar. Olhe para o uso por serviço em vez dos totais do host, porque uma média esconde qual processo está passando fome. Se uma carga de trabalho perturba repetidamente a outra, isole-as em vez de ajustar em torno do sintoma.

O isolamento pode ser um contêiner, um limite de cgroup, uma fila separada ou um segundo host, e a escolha correta depende de qual recurso compete. Uma mudança de porta não corrige nada aqui, e uma instância maior não corrige nada se o limite for uma fila saturada. Decida com uma medição: nomeie o recurso, carregue-o e depois escolha o menor isolamento que elimina a competição.

Verifique de fora e depois novamente após uma reinicialização

Teste de um dispositivo que não esteja na rede do próprio host: carregue o site, levante o túnel e alcance um recurso que o exija. Depois reinicie cada serviço por conta própria e repita o outro teste, porque uma reinicialização é o momento em que um arranjo de ouvinte compartilhado perde a sua ordem. Se a VPN arrancar antes do servidor web que possui a porta compartilhada, o mecanismo de compartilhamento pode nunca se ligar, e o sintoma é um túnel que funcionava ontem. Torne a dependência explícita na ordem das unidades.

Depois confirme os limites: o site responde na sua porta, a VPN responde na sua própria, e a interface administrativa responde apenas pelo caminho de gestão. Anote o resultado ao lado da tabela de ouvintes com a data. Um host que passa os três testes após uma reinicialização é um host que você pode entregar a outra pessoa sem uma sessão de esclarecimento.