¿Configurar la dirección DNSMasq / pares de IP internos por puerto?

Tengo una serie bastante compleja de servidores, todos conectados a un enrutador que ejecuta DD-WRT. Tiendo a mover toda la configuración con bastante frecuencia, así que intenté hacerlo "móvil". Hice esto configurando el enrutador DD-WRT en el que están mis servidores como un tipo de puente. Cuando me mudo, simplemente cambio la red inalámbrica que utiliza el enrutador para contactar a Internet y le doy al enrutador DD-WRT una IP estática, así como reenviar todos los puertos del nuevo enrutador al enrutador DD-WRT. El enrutador DD-WRT ya tiene su propia subred, asignaciones de IP estáticas para todos los servidores que quiero en mi red y todas las configuraciones correctas de reenvío de puertos.

El problema que tengo es que Hairpin-Routing no funcionará en esta configuración porque incluso si está habilitado en el enrutador DD-WRT, el nuevo enrutador generalmente es solo un módem / enrutador todo en uno estándar de Century Link o lo que sea. (IE no está destinado a ser configurado realmente por el usuario final, por lo que no puedo habilitar el enrutamiento de horquilla).

He "resuelto" este problema utilizando las reglas DNSMasq. Esto es lo que tengo actualmente ...

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

El problema que tengo ahora es que quiero que ciertos puertos example.comse envíen a diferentes servidores. Por ejemplo, me gustaría 587, 993y 25reenviar 10.0.0.101y me gustaría 80, 8080y 3000reenviar a 10.0.0.102.

¿Hay alguna manera de lograr esta configuración SIN configurar el enrutador genérico? (SOLO en el enrutador DD-WRT).

Eso no es algo que dnsmasq pueda hacer, porque no es algo que el DNS mismo pueda hacer. Los puertos TCP solo se involucran después de que se haya realizado la búsqueda de dirección. Por lo tanto, cualquiera de los hosts que example.comresuelva, debe ser capaz de manejar todas esas conexiones, posiblemente utilizando un proxy inverso HTTP cuando sea posible, o incluso otra capa de reenvío de puertos (iptables, redirección pf, etc.).

Sin embargo, algunas aplicaciones específicas tienen sus propios mecanismos. Para el puerto 25 (servidor-SMTP), cree un MXregistro que apunte a otro dominio. Si el servidor de correo remitente encuentra uno, solo usará los servidores enumerados en el registro MX. (Así es como casi todos los dominios redirigen su correo a un servidor de 'correo' dedicado o incluso a Google Mail).

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

Para IMAP y cliente-SMTP (143, 993, 587), puede tener suerte al crear registros SRV para cada servicio. Son similares en propósito pero pueden decirle a la aplicación qué host y qué puerto 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

O lo mismo en la sintaxis perversa de 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

Tenga en cuenta que solo algunos programas se preocupan por los registros SRV. Mientras que lo anterior _imap& c. los ejemplos son técnicamente estándar, todavía son muy raramente utilizados por las aplicaciones de correo reales. (Prácticamente los únicos usuarios de SRV generalizados son Kerberos, LDAP, SIP, XMPP y Minecraft).