Configurando o endereço DNSMasq / IP interno pares por porta?

Question

Eu tenho uma série bastante complexa de servidores, todos conectados a um roteador que executa o DD-WRT. Eu costumo mover toda a configuração com bastante frequência, então tentei torná-la "móvel". Eu fiz isso configurando o roteador DD-WRT em que meus servidores estão como um tipo de bridge. Quando me mudo, simplesmente mudo a rede sem fio que o roteador usa para entrar em contato com a Internet, e forneço ao roteador DD-WRT um IP estático, assim como redireciono todas as portas do novo roteador para o roteador DD-WRT. O roteador DD-WRT já tem sua própria sub-rede, alocações IP estáticas para todos os servidores que eu quero na minha rede e todas as configurações corretas de encaminhamento de porta.

O problema que estou tendo é que o Hairpin-Routing não funcionará nesta configuração porque, mesmo se ele estiver habilitado no roteador DD-WRT, o novo roteador é normalmente apenas um modem / roteador tudo-em-um padrão. da Century Link ou qualquer outra coisa. (I.E. não é para ser realmente configurado pelo usuário final, então eu não posso habilitar o roteamento hairpin.)

Eu "resolvi" esse problema usando as regras do DNSMasq. Isto é o que eu tenho atualmente ...

address=/odroid.example.com/10.0.0.101
address=/example.com/10.0.0.102

O problema que estou tendo agora é que eu quero que certas portas em example.com sejam encaminhadas para servidores diferentes. Por exemplo, gostaria que 587 , 993 e 25 enviassem para 10.0.0.101 e gostaria que 80 , 8080 e 3000 enviassem para 10.0.0.102 .

Existe uma maneira de obter essa configuração SEM configurar o roteador genérico? (SOMENTE no roteador DD-WRT).

    

Answer 1

Isso não é algo que o dnsmasq pode fazer, porque não é algo que o próprio DNS pode fazer. Portas TCP só se envolvem após a busca de endereço foi feita. Portanto, qualquer um dos seus hosts example.com resolve, deve ser capaz de lidar com todas dessas conexões - possivelmente usando um proxy reverso HTTP quando possível, ou ainda outra camada de encaminhamento de porta (iptables, pf redirecionar, & c.).

Alguns aplicativos específicos têm seus próprios mecanismos, no entanto. Para a porta 25 (servidor-SMTP), crie um registro MX que aponte para outro domínio. Se o servidor de envio de correio encontrar um, ele usará apenas os servidores listados no registro MX. (É assim que quase todos os domínios redirecionam seus e-mails para um servidor de "e-mail" dedicado ou até mesmo para o Gmail.

example.com.         MX 10 smtp-in.example.com.
smtp-in.example.com. A  10.0.0.25

Para IMAP e SMTP do cliente (143, 993, 587), você pode ter sorte com a criação de registros SRV para cada serviço. Eles são semelhantes em propósito, mas podem informar ao aplicativo qual host e qual porta usar:

_imap._tcp.example.com.       SRV 10 0 143 mail.example.com.
_imaps._tcp.example.com.      SRV 10 0 993 mail.example.com.
_submission._tcp.example.com. SRV 10 0 587 mail.example.com.
mail.example.com.             A   10.0.0.143

Ou o mesmo na sintaxe perversa do dnsmasq:

mx-host=example.com,smtp-in.example.com,10
address=/smtp-in.example.com/10.0.0.25

srv-host=_imap._tcp.example.com,mail.example.com,143
srv-host=_imaps._tcp.example.com,mail.example.com,143
srv-host=_submission._tcp.example.com,mail.example.com,587
address=/mail.example.com/10.0.0.143

Note que apenas alguns programas se importam com registros SRV. Enquanto o acima _imap & c. exemplos são tecnicamente padrão, eles ainda são muito raramente usados por aplicativos de email reais. (Praticamente os únicos usuários SRV generalizados são Kerberos, LDAP, SIP, XMPP e Minecraft).