NAT para dois servidores diferentes na mesma porta via hostname com o Mikrotik RB2011

Question

Eu tenho um roteador Mikrotik RB2011, rodando o RouterOS que se conecta à internet através de um IP estático. Na minha lan eu tenho dois servidores diferentes, um que está no IP 192.168.89.11 e outro em 192.168.89.12

Meu DNS (no cloudflare) resolve tanto o myfirstserver.com quanto o mysecondserver.com para o IP estático do meu roteador.

Agora, o que eu quero fazer é separar o tráfego de forma que todo o tráfego para myfirstserver.com vá para 192.168.89.11 e o tráfego para mysecondserver.com vá para 192.168.89.12 (e ambos na porta 80. Eu sei que poderia apenas altere as portas, mas se elas forem servidores publicamente disponíveis, nenhum usuário definirá uma porta diferente de 80)

O que eu tentei até agora é marcar os pacotes através do mangle e usar essa marca no NAT para fazer o forward dst-nat apropriado.

Eu tento marcar pacotes através do conteúdo ou regex do protocolo da Camada 7 (eles funcionam corretamente se a ação for log. Eu posso vê-los sendo registrados corretamente).

O problema é que depois de marcá-los, parece que o NAT apenas os ignora e encaminha a conexão para o servidor que aceita os pacotes não marcados.

Acho que confundi a ordem de filtragem e as cadeias de alguma forma.

Alguém poderia fornecer algumas dicas / ajuda sobre como fazer isso?

Obrigado!

EDIT: Minha pergunta é muito específica, sobre marcar pacotes no RouterOS em um roteador Mikrotik e verificar a marca no NAT. Não é sobre se eu preciso de um proxy reverso ou qualquer outra coisa. Obrigado

EDIT 2: @ Cha0s perguntou ao meu /ip firewall export então aqui está:

/ip firewall layer7-protocol
add name=haf1a regexp=haf1a

/ip firewall address-list
add address=192.168.89.0/24 list=local
add address=192.168.88.0/24 list=local
add address=www.xxx.yyy.zzz list=local
add address=192.168.87.0/24 list=local

/ip firewall filter
add chain=input comment="default configuration" protocol=icmp
add chain=input comment="default configuration" connection-state=established
add chain=input comment="default configuration" connection-state=related
add action=drop chain=virus comment="Drop 80 DoS attack" src-address-list=spammer
add action=add-src-to-address-list address-list=spammer address-list-timeout=1d chain=input connection-limit=10,32 dst-address-list=!local dst-port=53 protocol=udp
add action=drop chain=input dst-port=53 protocol=udp src-address-list=!local
add action=add-src-to-address-list address-list=spammer address-list-timeout=1d chain=input connection-limit=30,32 protocol=tcp
/ip firewall mangle
add action=change-mss chain=forward new-mss=1422 out-interface=all-ppp protocol=tcp tcp-flags=syn tcp-mss=1423-65535

/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" out-interface=ether1-gateway
add action=masquerade chain=srcnat out-interface=pppoe-out1
add action=dst-nat chain=dstnat comment="No HAF mark" dst-address=www.xxx.yyy.zzz dst-port=80 packet-mark=!haf1 port="" protocol=tcp src-port="" to-addresses=192.168.89.41 to-ports=80
add action=dst-nat chain=dstnat comment="HAF mark" dst-address=www.xxx.yyy.zzz dst-port=80 packet-mark=haf1 port="" protocol=tcp src-port="" to-addresses=192.168.89.31 to-ports=80

onde www.xxx.yyy.zzz é meu ip externo (estático) e 192.168.89.31 e 192.168.89.41 meus dois servidores dentro da minha rede local

Meu objetivo é redirecionar todas as conexões com haf1a nelas (por exemplo, haf1a.lala.com ) para o servidor relevante (192.168.89.31)

    

Answer 1

Obrigado pela exportação.

Acontece que esta configuração não é suportada pelo MikroTik ou existe um bug.

De acordo com o diagrama de fluxo de pacotes, se eu entendi corretamente, dst-nat deve ser capaz de detectar as marcas de pacote / conexão, pois mangle prerouting é antes de dst-nat . Mas depois de alguns testes meus, fiquei preso como você fez.

Enquantoomangle/filterpodecombinarospacotesmarcados(oumesmosemmarcar,masusandodiretamenteofiltroL7nasregras)nonatelesimplesmentenãocombinacomnenhumpacote.

ExistemtambémváriostópicosrelevantesnosfórunsdoMikroTik,quenenhumpareceterencontradoumasolução.

link

link

link

Um cara menciona uma solução usando o WebProxy do MikroTik, que eu pessoalmente não usaria, pois mudaria o endereço IP de origem para o IP do MikroTik e, assim, os servidores da Web registrariam todos os pedidos com o mesmo IP em vez do IPs dos visitantes reais.

Eu posso pensar em duas outras soluções, mas não são tão simples assim.

Solução 1: Se você estiver usando a versão 5.x do MikroTik, há uma imagem ISO que corrigirá o MikroTik e adicionará uma distribuição mínima do Debian no topo (ou abaixo) dele. Que então você pode usar para instalar o HAproxy ou qualquer outro proxy reverso que você gosta de realizar o que você precisa corretamente (HAproxy ou qualquer outro proxy reverso é a maneira correta de fazer isso, como outros já mencionaram)

Solução 2: Outra abordagem é criar um metarouter (se você executar o MikroTik em uma routerboard, você tem RAM livre suficiente e você não usa nstreme) e carregar uma imagem openwrt nela. Em que você pode então instalar um proxy reverso do seu gosto para realizar a tarefa.

O mais provável é que não seja uma solução: É claro que você também pode enviar um ticket de suporte ao MikroTik para confirmar ou (muito provavelmente) negar que existe um bug no NAT com a marcação de pacotes L7. Mas eu não esperaria muito do apoio deles. Na maioria das vezes não vai ajudar em nada. Sua estratégia padrão é que todo mundo é estúpido e o problema está sempre na configuração dos usuários e não no próprio MikroTik ...

Seria bom poder lidar com essa tarefa no próprio roteador. É adequado para ambientes restritos, em que colocar outra máquina para fazer o proxy reverso não é uma opção. Embora eu não usasse esse método (mesmo que funcionasse) em um ambiente de produção. O filtro da camada 7 é bastante lento e pesado para o roteador.

Atualização: Acabei de ver que você está usando o RB2011, então a solução ISO / debian não funcionará para você (é apenas para x86). Se você não está usando nstreme (eu acho que não), então sua única aposta é usando um metarouter com openwrt para fazer o material de proxy reverso para você.

    

Answer 2

Para HTTP, um proxy reverso pode manipular a separação do tráfego. Funciona porque os navegadores modernos enviam um cabeçalho de host especificando o site que desejam. Isso não funciona para a maioria dos outros protocolos - você só pode ver o endereço IP que eles pediram.

Se você quiser que outros protocolos acessem servidores separados, será necessário solicitar um segundo IP público do seu ISP.