É possível dois proxies inversos partilharem as portas 80 e 443 num único servidor doméstico?

Não no mesmo IP e protocolo ao mesmo tempo, a menos que um proxy seja a única porta de entrada e encaminhe o tráfego selecionado para o outro, ou que cada um esteja associado a um IP diferente.

Isto torna-se uma verdadeira questão de compatibilidade quando dois contentores proxy publicam simultaneamente as portas 80 e 443 do anfitrião para pilhas de aplicações separadas na mesma máquina. Comece por um caminho ou conta descartável, mantenha disponível o estado anterior funcional e avalie o design com base na carga de trabalho original, e não num teste de ligação único.

Identificar Quem é Responsável pelo Recurso Partilhado

A opção suportada é um listener por par IP-porta, com encaminhamento por trás dele. A opção concorrente consiste em dois listeners independentes a competir pelo mesmo socket. Registe as versões, identidades, endereços, caminhos de montagem, permissões e o estado observável atual antes de alterar qualquer uma das opções.

As regras de associação de sockets relevantes definem o primeiro limite de compatibilidade. Utilize-as para restringir a afirmação e, em seguida, verifique o mesmo comportamento neste servidor doméstico específico, em vez de tratar uma funcionalidade documentada como prova de que todo o design funciona.

Escreva a regra de decisão antes de testar: o sucesso deve resultar em que apenas o proxy frontal pretendido seja responsável por cada socket público e que cada nome de anfitrião alcance o upstream correto com o certificado esperado; a falha inclui o arranque indicar que o endereço está em uso, o tráfego chegar ao proxy errado ou o TLS terminar com o certificado de outro site. Isto evita interpretar uma ligação parcial ou a saída normal de um comando como compatibilidade de ponta a ponta.

Alterar um Listener ou Encaminhamento de Cada Vez

Utilize um único fator de distinção controlado: liste os listeners atuais, associe cada proxy a um IP de teste distinto ou coloque um atrás do outro e, em seguida, teste o encaminhamento de Host, SNI, WebSocket e certificados. Mantenha constantes o cliente, a carga de trabalho, o conjunto de ficheiros, a conta e o momento, para que o componente alterado seja a única explicação plausível.

Utilize o comportamento das portas publicadas para escolher a segunda observação relevante para este caminho. Registe ambos os lados da transação: resolvedor ou rota, protocolo negociado, identidade do processo, estado de saída, latência, bytes transferidos e qualquer evento de recuperação.

Repita o teste após o evento do ciclo de vida indicado no título - recriação, nova ligação, nova montagem, reinício, failover ou alteração do cliente. Um design que só funciona enquanto sockets, caches ou credenciais antigas permanecem ativos não foi aprovado.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

Utilizar Evidências Observáveis de Encaminhamento para Decidir

APROVADO: apenas o proxy frontal pretendido é responsável por cada socket público e cada nome de anfitrião alcança o upstream correto com o certificado esperado. Guarde as versões exatas e a topologia que produziram este estado, porque a conclusão se aplica a essas condições, e não a todas as implementações do protocolo.

FALHA: o arranque indica que o endereço está em uso, o tráfego chega ao proxy errado ou o TLS termina com o certificado de outro site. Verifique dependências partilhadas, como DNS, MTU, identidade, estado da firewall, latência do armazenamento e sessões em cache, antes de declarar que uma das opções principais é responsável.

EXCEÇÃO: pare a segunda associação pública, restaure o último listener funcional e escolha uma única porta de entrada ou endereços de anfitrião separados. Não amplie privilégios, elimine dados de origem, enfraqueça a segurança do transporte nem substitua o armazenamento funcional até que uma observação repetível identifique qual foi o limite que falhou.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verificar Novamente o Isolamento Antes de o Tráfego de Produção Regressar

Aplique apenas a ação correspondente à opção observada e, em seguida, execute novamente a carga de trabalho original. Mantenha o design apenas quando apenas o proxy frontal pretendido for responsável por cada socket público e cada nome de anfitrião alcançar o upstream correto com o certificado esperado ao longo de dois ciclos de vida relevantes e sob a carga concorrente prevista.

Utilize as redes dedicadas de proxy para verificar o fluxo de trabalho dependente mais próximo. O respetivo acesso, comportamento temporal e recuperação devem permanecer inalterados enquanto o novo design estiver ativo.

Pare e regresse ao estado guardado se o arranque indicar que o endereço está em uso, o tráfego chegar ao proxy errado ou o TLS terminar com o certificado de outro site. Escale com marcas temporais, versões exatas, evidências de rotas ou montagens e a reprodução mínima, em vez de adicionar outra solução temporária.

Compare o resultado com as substituições de DNS para proxies inversos, para que o risco não seja simplesmente transferido para outra camada de rede, identidade, cópia de segurança ou armazenamento.

Para a atribuição de portas a dois proxies inversos, a resposta qualificada é, portanto, o juízo inicial - não um sim incondicional. O estado observável de aprovação é a linha de aceitação; o estado de falha é a linha de reversão.

Perguntas frequentes

O SO_REUSEPORT pode permitir que proxies não relacionados partilhem a porta 443?

Não é um design seguro de encaminhamento por nome de anfitrião para proxies independentes; utilize uma única porta de entrada TLS ou IPs separados.

Um proxy pode encaminhar o TLS para o segundo?

Sim, quando o encaminhamento se baseia em SNI e o proxy a jusante é responsável pela terminação do certificado desse nome de anfitrião.

Os listeners IPv4 e IPv6 entram em conflito?

Podem entrar, dependendo do comportamento dos sockets de pilha dupla e dos endereços associados; inspecione explicitamente ambas as famílias de protocolos.