Como funciona o modo transparente do SSLH?

Question

Eu tenho um servidor que precisa aceitar conexões TCP na porta 443, descobrir se uma conexão é um cliente OpenVPN ou um cliente HTTPS e encaminhá-lo para meu servidor web ou meu servidor OpenVPN.

O SSLH foi desenvolvido especificamente por esse motivo e parece funcionar muito bem. O único problema é que, ao configurá-lo em modo não transparente, funciona bem para mim, usar o modo transparente está me causando problemas.

Alguém pode explicar a teoria por trás de como o modo transparente deve funcionar?

O guia SSLH diz que, para usar o SSLH de forma transparente , você precisa:

• Defina sslh.cfg como transparent: true;
  • eu fiz isso
• sslh precisa de direitos estendidos (CAP_NET_ADMIN)
  • Eu instalei o sslh dos repositórios do meu CentOS 7, que vieram com sslh.service para systemd. Esse arquivo de serviço contém a linha CapabilityBoundingSet=... CAP_NET_ADMIN ... , então presumo que isso já seja feito por SystemD
• Configurar regras de iptables que marcam pacotes e algum tipo de rota local
  • Isso é o que eu não entendo. Estes são configurados no servidor SSLH? Ou eles configuram os servidores OpenVPN e HTTPS?

Eu entendo que no exemplo, iptables é dito para marcar qualquer pacote com uma porta de origem de 22 ou 4443 com uma marcação 0x1, uma regra é criada para que qualquer pacote marcado com 0x1 use tabela de roteamento 100 e tabela de roteamento 100 é criado que configura algum tipo de rota local que faz alguma coisa.

Por que essas regras do iptables e a rota são necessárias? Qual é a rota realmente fazendo? Eu acho que a rota deve estar no servidor web e no servidor OpenVPN, e apontar para o ip SSLH, mas isso também não parece funcionar para mim.

===

Atualização: Ocorreu-me apenas que é provavelmente uma rota que aponta para o localhost porque, no exemplo, os servidores estão todos na mesma máquina e querem que os pacotes de resposta provenientes dos servidores reais passem pelo SSLH antes eles saem da máquina. Isso soa certo? Se sim, o que eu faria no meu caso se meus servidores estivessem em máquinas diferentes? Configurar marcação de tráfego e uma rota de volta ao servidor SSLH nessas máquinas?

Atualização 2: basta configurar rapidamente o servidor HTTPS na mesma caixa que o SSLH, e o modo transparente parece funcionar exatamente da mesma maneira que no exemplo da documentação do SSLH. Eu preciso que funcione quando eles estão em servidores diferentes.

    

Answer 1

No modo não transparente, o cliente se conecta com client_ip:client_port ao proxy sslh na porta 443 . Em seguida, o proxy sslh abre uma conexão com sslh_ip:sslh_port para o servidor interno na porta 4443 . O servidor da Web interno responderá de web_ip:4443 ao proxy_ip:proxy_port . E finalmente, o proxy sslh reescreve a fonte do pacote de resposta para sshl_ip:443 e envia para o cliente.

No modo transparente para a conexão entre o proxy sslh e o servidor interno, a origem dos pacotes é definida como a% original client_ip:client_port . Portanto, o servidor da web interno responde diretamente a client_ip:client_port com web_ip:4443 como origem. Mas o cliente aguarda na forma de pacotes proxy_ip:443 .

Para gerenciar a reescrita dos pacotes de resposta do servidor interno, esses pacotes devem ser roteados através do daemon sslh . Eu acho que o daemon está procurando pacotes de resposta para o cliente na interface de loopback. Na documentação, apenas o caso com proxy sslh e servidor interno da Web na mesma máquina é prescrito.

Com a tentativa e erro, encontrei a seguinte solução: (no proxy sslh )

ip route add local default dev lo table 100
ip rule add fwmark 0x1 lookup 100
iptables -t mangle -N SSLH
iptables -t mangle -A SSLH -j MARK --set-mark 0x1
iptables -t mangle -A SSLH -j ACCEPT

(para pegar os pacotes de resposta do servidor interno)

iptables -t mangle -A PREROUTING -p tcp -s **web_ip** --sport 4443 -j SSLH

... (regras semelhantes para os outros serviços, por exemplo, ssh, openvpn) ...

Isso funciona somente quando a rota padrão do servidor da Web interno passa pelo servidor proxy sshl para a Internet.

    

Answer 2

Obrigado Norbert - você explicou bem a idéia geral. Então, para colocar tudo isso junto, até onde eu sei, é isso que está acontecendo especificamente com todos os comandos que estamos executando:

Servidor SSLH:

$ sudo iptables -t mangle -N SSLH
$ sudo iptables -t mangle -A PREROUTING -p tcp -m socket --transparent -j SSLH
$ sudo iptables -t mangle -A SSLH -j MARK --set-mark 0x1 
$ sudo iptables -t mangle -A SSLH -j ACCEPT
$ sudo ip rule add fwmark 0x1 lookup 100 
$ sudo ip route add local 0.0.0.0/0 dev lo table 100

Servidor da Web interno:

$ sudo iptables -t mangle -N SSLH
$ sudo iptables -t mangle -A OUTPUT -o eth0 -p tcp -m tcp --sport 4443 -j SSLH
$ sudo iptables -t mangle -A SSLH -j MARK --set-mark 0x1 
$ sudo iptables -t mangle -A SSLH -j ACCEPT
$ sudo ip rule add fwmark 0x1 lookup 100 
$ sudo ip route add default via [SSLH_IP] table 100 

No servidor da web interno:

• um servidor web (como o apache ou nginx) está escutando na porta 4443
• qualquer coisa saindo da eth0 com uma porta de origem de 4443 é enviada para a cadeia SSLH
• qualquer coisa na cadeia SSLH recebe uma marca de 0x1 definida
• é criada uma regra de roteamento que diz que qualquer coisa marcada como 0x1 deve usar a tabela de roteamento 100, em vez da tabela de roteamento principal
• tabela de roteamento 100 tem uma entrada que diz para enviar tráfego para o servidor SSLH, em vez do gateway padrão

Esta sequência de eventos basicamente força o tráfego do processo do servidor web (nginx / apache / whatever) para ser roteado para o servidor SSLH, em vez do padrão gateway como o resto do tráfego do sistema.

No servidor SSLH:

• qualquer coisa proveniente do servidor da web (porta de origem 4443) é enviada para a cadeia SSLH
• qualquer coisa na cadeia SSLH recebe uma marca de 0x1 definida
• é criada uma regra de roteamento que diz que qualquer coisa marcada como 0x1 deve usar a tabela de roteamento 100, em vez da tabela de roteamento principal
• tabela de roteamento 100 tem uma entrada que diz para forçar todo o tráfego usando este tabela de roteamento para ser redirecionado para a interface de loopback

Esta sequência de eventos basicamente força o tráfego do servidor web interno a ser redirecionado para a interface de loopback no servidor SSLH, onde o processo SSLH irá reescrever seu IP e porta de origem e enviá-lo para fora.

Perguntas que ainda tenho:

• isso soa bem?
• o que faz iptables -t mangle -A SSLH -j ACCEPT ? Isso é necessário? Esta não é a tabela FILTER - por que estamos aceitando tráfego aqui?
• no meu caso, a regra de pré-layout do iptables no host SSLH que funciona parece diferente do que o de Norbert. Como isso funciona? Como se sabe se algo é --transparent ou não?